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 /application/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"
    }
  }
} ]

Usar a geração de registros para depurar problemas no pod do ambiente de execução

Para ajudar na solução de problemas, crie uma sessão de registro para produzir uma saída de registro detalhada para os pods apigee-runtime.

Criar uma sessão de registro

Para criar uma sessão de registro para um pod de ambiente de execução:

  1. Liste os pods do ambiente de execução. Por padrão, elas estão no namespace apigee. Se você escolher um namespace diferente, use-o: 
    kubectl get pods -n apigee
  2. Escolha um dos pods apigee-runtime listados para depurar.
  3. Crie uma sessão de registro no pod de ambiente de execução que você quer resolver usando a API /logsessions. Para detalhes sobre a API, consulte Sobre a API logsessions: 
    kubectl exec -it RUNTIME_POD_NAME -n apigee \
  -- curl "https://0:8843/v1/logsessions?loggerNames=ALL&level=FINE&timeout=60000" -k -X POST -v

    Exemplo:

    kubectl exec -it apigee-runtime-hybrid-18-01232-dev-d27ca57-190rc6-3klyg-lc7h5 -n apigee \
  -- curl "https://0:8843/v1/logsessions?loggerNames=ALL&level=FINE&timeout=60000" -k -X POST -v

    A resposta é um código de sessão de registro. Por exemplo: 9f831a7d-e533-4ead-8e58-12ec1059a622

  4. Imprima os registros: 
    kubectl logs -f -n apigee RUNTIME_POD_NAME

Listar sessões de registro

Para ver uma lista de todas as sessões de registro ativas para um pod de ambiente de execução:

kubectl exec -it RUNTIME_POD_NAME -n apigee \
  -- curl "https://0:8843/v1/logsessions" -k -v

Acessar uma sessão de registro

Para ver detalhes da sessão de registro:

kubectl exec -it RUNTIME_POD_NAME -n apigee \
  -- curl "https://0:8843/v1/logsessions/LOG_SESSION_ID" -k -v

Encerrar uma sessão de registro

Para encerrar uma sessão de registro:

kubectl exec -it RUNTIME_POD_NAME -n apigee \
    -- curl "https://0:8843/v1/logsessions/LOG_SESSION_ID" -k -X DELETE -v

Sobre a API logsessions

Esta seção descreve os parâmetros de consulta da API logsessions:

  • loggerNames: especifica o tipo de saída do registro a ser exibido. Os valores possíveis incluem CONTRACT_REPLICATION, DEBUG.SESSION ou ALL.
  • level: especifica o nível de saída do registro. Os valores possíveis incluem FINEST, FINER, FINE, INFO, SEVERE, ALL.
  • timeout: especifica a quantidade de tempo que a sessão do registro operará para o nível de registro especificado. Após o tempo limite, o nível de registro é revertido para INFO.

Depois disso, a API retornará um ID de sessão para a sessão de registro.