Esta página foi traduzida pela API Cloud Translation.

Guia de resolução de problemas do processador de mensagens

Este tópico aborda os passos que pode seguir para resolver problemas com o processador de mensagens. O processador de mensagens faz parte do componente apigee-runtime. Consulte também a vista geral da configuração do serviço de tempo de execução.

A Readiness probe falha com o código de estado HTTP 500

Sintoma

Um ou mais pods do apigee-runtime não estão no estado Ready.

Mensagem de erro

Quando usa kubectl para descrever um pod apigee-runtime com falhas, vê o seguinte erro:

Readiness probe failed: HTTP probe failed with statuscode: 500

Por exemplo:

kubectl describe pod -n hybrid \
apigee-runtime-apigee-gcp-prod1-test-blue-67db4f457b-9c7c7

...
apigee-runtime-apigee-gcp-prod1-test-blue-67db4f457b-9c7c7  Readiness probe failed: HTTP probe
failed with statuscode: 500
...

Causas possíveis

O erro significa que não está disponível nenhum contrato ativo para o processador de mensagens publicar o tráfego. Neste estado, o processador de mensagens não pode considerar-se "pronto".

Causa	Descrição
Problema de ligação do sincronizador ao plano de gestão	O sincronizador não consegue estabelecer ligação ao plano de gestão. Normalmente, este problema é causado nos casos em que substitui o URL `contractProvider` e associa a conta de serviço errada ao mesmo. Por exemplo, se configurar uma conta de serviço para uma implementação de teste com um `contractProvider` URL que aponta para o servidor de produção.
Problema de ligação do processador de mensagens ao sincronizador	Se o novo MP aparecer como parte de um ajuste de escala automático ou de um reinício do pod, pode ver este erro. Geralmente, este problema ocorre quando o sincronizador está inativo e o MP não conseguiu carregar o respetivo contrato.

Diagnóstico: problema de ligação do sincronizador ao plano de gestão

Para diagnosticar um problema de ligação do sincronizador ao plano de gestão, faça o seguinte:

Liste os pods no cluster:
```
kubectl get pods -n namespace
```

Abra uma shell num pod do apigee-synchronizer:

kubectl exec -it -n namespace synchronizer-pod-name bash

Por exemplo:

kubectl exec -it -n apigee apigee-synchronizer-apigee-gcp-prod1-test-blue-cnj5x bash

Aceda ao seguinte diretório:

cd /opt/apigee/var/log/apigee-synchronizer
ls

  dr-xr-sr-x 4 apigee apigee  4096 Sep 12 16:52 750
  drwxr-sr-x 2 apigee apigee  4096 Sep 12 16:52 cachedFiles
  -rw-r--r-- 1 apigee apigee 22295 Sep 12 16:52 config.log
  -rw-r--r-- 1 apigee apigee    76 Sep 12 16:52 versions.properties

Verifique a versão ativa em version.properties. Por exemplo:

cat versions.properties

  #active repository version
  #Sat Dec 14 19:45:00 GMT 2019
  active.version=749

Certifique-se de que o valor de active.version corresponde ao número da pasta de contrato. No exemplo acima (também apresentado abaixo), o nome da pasta é 750; por conseguinte, não corresponde:
```
dr-xr-sr-x 4 apigee apigee  4096 Sep 12 16:52 750
```
Saia da caixa do pod.

Resolução

Se version.properties estiver em falta ou se existir uma incompatibilidade de versões, conforme explicado acima, verifique os registos do sincronizador para tentar determinar o motivo pelo qual os contratos mais recentes não estão a ser transferidos. Por exemplo:

kubectl logs -f -n namespace synchronizer-pod-name

Para obter informações sobre a interpretação dos registos do sincronizador, consulte o artigo Registos do sincronizador. Se o sincronizador estiver inativo, experimente reiniciá-lo através de apigeectl. Por exemplo:

$APIGEECTL_HOME/apigeectl apply -f overrides/overrides.yaml --org --env env-name

Diagnóstico: problema de ligação do processador de mensagens ao sincronizador

Para diagnosticar um problema de ligação do processador de mensagens ao sincronizador, faça o seguinte:

Liste os pods no cluster:
```
kubectl get pods -n namespace
```

Verifique os registos de tempo de execução para tentar descobrir por que motivo os contratos não estão a ser transferidos:

kubectl logs -f -n namespace pod-name

Por exemplo:

kubectl logs -f -n apigee apigee-runtime-apigee-gcp-prod1-test-blue-67db4f457b-9c7c7

É possível que, se o novo MP aparecer como parte de uma escalabilidade automática ou de um reinício do pod, o MP não carregue os contratos. Geralmente, o problema ocorre quando o sincronizador está inativo, o que impede o carregamento dos contratos por parte do MP. Por exemplo:

2019-09-13 16:59:24,331 podName:N/A ipAddress:N/A dpColor:N/A
HttpClient@331886186-301 DEBUG o.e.j.c.AbstractConnectionPool - AbstractConnectionPool$1.failed() :
Connection 1/64 creation failed
java.net.UnknownHostException: apigee-synchronizer-apigee-gcp-prod1-test.hybrid.svc.cluster.local
at java.net.InetAddress.getAllByName0(InetAddress.java:1281)
at java.net.InetAddress.getAllByName(InetAddress.java:1193)
at java.net.InetAddress.getAllByName(InetAddress.java:1127)
at org.eclipse.jetty.util.SocketAddressResolver$Async.lambda$resolve$1(SocketAddressResolver.java:167)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:672)
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:590)
at java.lang.Thread.run(Thread.java:748)
	at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:590)
	at java.lang.Thread.run(Thread.java:748)

Resolução

Experimente reiniciar o sincronizador. Por exemplo:

$APIGEECTL_HOME/apigeectl apply -f overrides/overrides.yaml --org --env env-name

A sondagem de disponibilidade falha devido a uma chave de encriptação inválida

Sintoma

Os pods apigee-runtime não estão no estado Ready.

Diagnóstico

Quando usa kubectl para descrever um pod apigee-runtime com falha, vê este erro: Readiness probe failed: Probe hybrid-encryption-key-validation-probe failed. Por exemplo:

$ kubectl describe pod -n namespace apigee-runtime-pod-name

...
Readiness probe failed: Probe hybrid-encryption-key-validation-probe failed due to
com.apigee.probe.model.ProbeFailedException{ code = hybrid.encryption.key.InvalidEncryptionKey,
message = Invalid encryption key. Please check the length of the encryption key, associated
contexts = []}
...

Resolução

Os comprimentos de chaves de encriptação suportados são de 16, 24 ou 32 bytes, e o valor da chave tem de estar codificado em base64. Para mais informações sobre como criar uma chave formatada corretamente, consulte o artigo Encriptação de dados.

Visualizar registos do processador de mensagens

Para ver detalhes sobre a visualização e a interpretação dos registos do processador de mensagens, consulte o artigo Registos do tempo de execução.

Chame um proxy de API a partir do pod de tempo de execução

Em algumas situações, para ajudar a isolar um problema, é recomendável verificar se consegue fazer uma chamada de proxy de API diretamente a partir do pod apigee-runtime e, assim, ignorar o gateway de entrada.

Execute o seguinte comando para encaminhar para a porta 8443. Isto permite-lhe chamar a API no pod:
```
kubectl port-forward -n namespace apigee-runtime-pod-name 8443:8443
```

Chame um proxy de API implementado. Por exemplo, quando o caminho base do proxy é ilove-apis:

curl -k -v https://0:8443//ilove-apis

    < HTTP/1.1 200 OK
    < X-Powered-By: Apigee
    < Access-Control-Allow-Origin: *
    < X-Frame-Options: ALLOW-FROM RESOURCE-URL
    < X-XSS-Protection: 1
    < X-Content-Type-Options: nosniff
    < Content-Type: text/html; charset=utf-8
    < Content-Length: 18
    < ETag: W/"12-Jb9QP1bUxNSmZkxQGt5KLQ"
    < Date: Fri, 13 Sep 2019 18:33:46 GMT
    < Via: 1.1 google
    < X-Apigee.Message-ID: 016f5f7f-c59e-404c-86e8-7b0737833f982
    < X-Apigee.dp.color: blue
    < X-Apigee.proxy: /organizations/my-org/environments/test/apiproxies/i-loveapis/revisions/1
    < X-Apigee.proxy.basepath: /ilove-apis
    < X-Apigee.target-latency: 9
    <
    * Connection #0 to host 0 left intact
    <H2>I <3 APIs

Verifique a API de gestão

Pode usar a API descrita abaixo para verificar se a API Management está a funcionar corretamente.

Obtenha os nomes dos pods no seu cluster:
```
kubectl get pods -n namespace
```

Use o encaminhamento de portas para aceder ao pod apigee-runtime. A sintaxe para o encaminhamento de porta é a seguinte:

kubectl port-forward -n namespace podname 8843:8843

Por exemplo:

kubectl port-forward -n apigee \
    apigee-runtime-my-organization-test-blue-57965b7789-6j4bp 8843:8843

Em seguida, noutra janela do terminal, use uma utilidade como curl para enviar um pedido para a API classification/tree, conforme mostra o exemplo seguinte:

curl -k https://0:8843/v1/classification/tree

Segue-se um exemplo de resposta que apresenta informações sobre os proxies implementados no ambiente "test":

[ {
  "condition" : "(always matches)",
  "virtualHost" : {
    "env" : "test",
    "name" : "default",
    "org" : "my-organization",
    "tree" : {
      "elements" : [ {
        "application" : "myproxy",
        "basePath" : "/myproxy",
        "name" : "default",
        "revision" : "1"
      } ],
      "name" : "IdentificationTree"
    }
  }
} ]

Usar o modo DEBUG

Para ajudar na resolução de problemas, pode ativar o modo DEBUG para incluir informações mais detalhadas nos registos do pod.apigee-runtime

Liste os pods no seu espaço de nomes:
```
kubectl get pods -n namespace
```
Escolha um dos pods apigee-runtime listados para depurar.

Execute o comando de encaminhamento de portas para esse pod. Por exemplo:

kubectl port-forward -n hybrid apigee-runtime-hybrid-prod-blue-fcpdd 8843

Abra outro terminal e chame a seguinte API para ativar a depuração:
```
curl "https://0:8843/v1/logsessions?sessions=debug" -X POST -v -k
```
Execute o comando kubectl logs para verificar o registo que está no modo DEBUG. Por exemplo:
```
kubectl logs -f -n hybrid apigee-runtime-hybrid-prod-blue-fcpdd
```
Quando terminar de examinar o registo DEBUG, reponha o nível de registo para INFO (o predefinido). Por exemplo:
```
curl "https://0:8843/v1/logsessions?sessions=info" -X POST -v -k
```
Execute o comando kubectl logs para se certificar de que o registo está novamente no modo INFO.

Guia de resolução de problemas do processador de mensagens Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

A Readiness probe falha com o código de estado HTTP 500

Sintoma

Mensagem de erro

Causas possíveis

Diagnóstico: problema de ligação do sincronizador ao plano de gestão

Resolução

Diagnóstico: problema de ligação do processador de mensagens ao sincronizador

Resolução

A sondagem de disponibilidade falha devido a uma chave de encriptação inválida

Sintoma

Diagnóstico

Resolução

Visualizar registos do processador de mensagens

Chame um proxy de API a partir do pod de tempo de execução

Verifique a API de gestão

Usar o modo DEBUG

Guia de resolução de problemas do processador de mensagens