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

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

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:

  1. Liste os pods no cluster: 
    kubectl get pods -n namespace
  2. Abra um shell em um pod apigee-synchronizer: 
    kubectl exec -it -n namespace synchronizer-pod-name bash

    Exemplo:

    kubectl exec -it -n apigee apigee-synchronizer-apigee-gcp-prod1-test-blue-cnj5x bash
  3. 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
  4. Verifique a versão ativa em version.properties. Exemplo: 
    cat versions.properties

  #active repository version
  #Sat Dec 14 19:45:00 GMT 2019
  active.version=749
  5. 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
  6. 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. 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:

  1. Liste os pods no cluster: 
    kubectl get pods -n namespace
  2. 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

    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. 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. 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. 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.

  1. 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
  2. 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.

  1. Consiga os nomes dos pods no cluster: 
    kubectl get pods -n namespace
  2. 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

    Exemplo:

    kubectl port-forward -n apigee \
    apigee-runtime-my-organization-test-blue-57965b7789-6j4bp 8843:8843
  3. 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.

  1. Liste os pods no namespace: 
    kubectl get pods -n namespace
  2. Escolha um dos pods apigee-runtime listados para depurar.
  3. Execute o comando de encaminhamento de portas para esse pod. Exemplo: 
    kubectl port-forward -n hybrid apigee-runtime-hybrid-prod-blue-fcpdd 8843
  4. 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
  5. 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
  6. 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
  7. Execute o comando kubectl logs para verificar se o registro está no modo INFO.