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

Esta é a documentação da Apigee e da Apigee híbrida.
Não há documentação equivalente do Apigee Edge para esse tópico.

Causa	Descrição
Problema de sincronização com o plano de gerenciamento do plano	O sincronizador não consegue se conectar ao plano de gerenciamento. Esse problema geralmente é causado quando você modifica o URL `contractProvider` e associa a conta de serviço errada a ele. Por exemplo, se você configurar uma conta de serviço para uma implantação de preparo com um URL `contractProvider` que aponte para o servidor de produção.
Problema de conexão entre o processador de mensagens e o sincronizador	Se o novo MP aparecer como parte de um escalonamento automático ou reinicialização do pod, talvez você veja esse erro. Geralmente, esse problema ocorre quando o sincronizador está inativo e o MP não pode carregar o contrato.

Observação: este documento é destinado apenas a usuários da Apigee.

Neste tópico, você verá as etapas para solucionar problemas com o processador de mensagens. O processador de mensagens faz parte do componente apigee-runtime. Consulte também Visão geral da configuração do serviço de ambiente de execução.

Falha na sondagem de prontidão com o código de status HTTP 500

Sintoma

Um ou mais pods apigee-runtime não estão no estado "Pronto".

Mensagem de erro

Ao usar kubectl para descrever um pod apigee-runtime com falha, você verá o 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 nenhum contrato ativo está disponível para que o processador de mensagens processe o tráfego. Nesse estado, o processador de mensagens não pode se considerar "pronto".

Causa Descrição

Problema de sincronização com o plano de gerenciamento do plano O sincronizador não consegue se conectar ao plano de gerenciamento. Esse problema geralmente é causado quando você modifica o URL contractProvider e associa a conta de serviço errada a ele. Por exemplo, se você configurar uma conta de serviço para uma implantação de preparo com um URL contractProvider que aponte para o servidor de produção.

Problema de conexão entre o processador de mensagens e o sincronizador Se o novo MP aparecer como parte de um escalonamento automático ou reinicialização do pod, talvez você veja esse erro. Geralmente, esse problema ocorre quando o sincronizador está inativo e o MP não pode carregar o contrato.

Diagnóstico: problema de conexão entre o sincronizador e o plano de gerenciamento

Para diagnosticar um problema de conexão do sincronizador com o plano de gerenciamento, faça o seguinte:

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

Abra um shell em um pod 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

Acesse o 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 corresponda ao nome do número da pasta de contrato. No exemplo acima, também mostrado abaixo, o nome da pasta é 750. Portanto, eles não correspondem:
dr-xr-sr-x 4 apigee apigee 4096 Sep 12 16:52 750

Saia do shell do pod.

Resolução

Se version.properties estiver ausente ou se houver uma incompatibilidade de versão conforme explicado acima, verifique os registros do sincronizador para determinar o motivo pelo qual os contratos mais atuais não estão sendo salvos. Exemplo:

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

Para informações sobre como interpretar os registros do sincronizador, consulte Registros do sincronizador. Se o sincronizador estiver inativo, tente reiniciá-lo usando apigeectl. Por exemplo:

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

Diagnóstico: problema de conexão entre o processador de mensagens e o sincronizador

Para diagnosticar um problema de conexão entre o processador de mensagens e o sincronizador, siga estas etapas:

Liste os pods no cluster.
kubectl get pods -n namespace

Verifique os registros do ambiente de execução para tentar descobrir por que os contratos não estão sendo salvos:
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 o novo MP apareça como parte de uma reinicialização de escalonamento automático ou de pod, que o MP pode não carregar os contratos. Geralmente, o problema ocorre quando o sincronizador está inativo, impedindo que o MP carregue os contratos. 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

Tente reiniciar o sincronizado. Por exemplo:

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

A sondagem de prontidão falha com uma chave de criptografia inválida

Sintoma

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

Diagnóstico

Quando você usa kubectl para descrever um pod apigee-runtime com falha, este erro é exibido: 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 da chave de criptografia compatíveis são de 16, 24 ou 32 bytes, e o valor da chave precisa ser codificado em base64. Para mais informações sobre como criar uma chave formatada corretamente, consulte Criptografia de dados.

Como ver registros do processador de mensagens

Para detalhes sobre como ver e interpretar os registros do processador de mensagens, consulte Registros do ambiente de execução.

Chamar um proxy de API do pod de ambiente de execução

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

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

Chame um proxy de API implantado. Por exemplo, em que 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

Verificar a API de gerenciamento

É possível usar a API descrita abaixo para verificar se a API de gerenciamento está funcionando corretamente.

Consiga os nomes dos pods no cluster:
kubectl get pods -n namespace

Use o encaminhamento de porta para ter acesso ao pod apigee-runtime. A sintaxe do encaminhamento de portas é 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 outra janela de terminal, use um utilitário como curl para enviar uma solicitação à API classification/tree, como mostra o exemplo a seguir:
curl -k https://0:8843/v1/classification/tree

Veja um exemplo de resposta, que lista informações sobre os proxies implantados no ambiente de "teste":

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

Como usar o modo DEBUG

Para ajudar na solução de problemas, é possível ativar o modo DEBUG para incluir informações mais detalhadas nos registros do pod apigee-runtime.

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

Escolha um dos pods apigee-runtime listados para depurar.

Execute o comando de encaminhamento de portas para esse pod. 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 registro que está no modo DEBUG. Por exemplo:
kubectl logs -f -n hybrid apigee-runtime-hybrid-prod-blue-fcpdd

Quando terminar de examinar o registro DEBUG, redefina o nível de registro como INFO (padrão). Exemplo:
curl "https://0:8843/v1/logsessions?sessions=info" -X POST -v -k

Execute o comando kubectl logs para verificar se o registro está no modo INFO.