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:

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

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

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

  1. Obtenha os nomes dos pods no seu cluster: 
    kubectl get pods -n namespace
  2. 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
  3. 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"
    }
  }
} ]

Use o registo para depurar problemas de pods de tempo de execução

Para ajudar na resolução de problemas, pode criar uma sessão de registo para produzir resultados de registo detalhados para os pods apigee-runtime.

Crie uma sessão de registo

Para criar uma sessão de registo para um pod de tempo de execução:

  1. Liste os agrupamentos do tempo de execução. Por predefinição, estão no espaço de nomes apigee. Se escolheu um espaço de nomes diferente, use-o em alternativa: 
    kubectl get pods -n apigee
  2. Escolha um dos pods apigee-runtime listados para depurar.
  3. Crie uma sessão de registo no pod de tempo de execução para o qual quer resolver problemas através da API /logsessions. Para ver detalhes sobre a API, consulte o artigo Acerca da 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

    Por 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 ID da sessão de registo. Por exemplo: 9f831a7d-e533-4ead-8e58-12ec1059a622

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

Indicar sessões de registo

Para obter uma lista de todas as sessões de registo ativas para um pod de tempo de execução:

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

Obtenha uma sessão de registo

Para obter detalhes da sessão de registo:

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

Termine uma sessão de registo

Para terminar uma sessão de registo:

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

Acerca da API logsessions

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

  • loggerNames: especifica o tipo de saída do registo a apresentar. Os valores possíveis incluem CONTRACT_REPLICATION, DEBUG.SESSION ou ALL
  • level: especifica o nível de saída de registo. Os valores possíveis incluem: FINEST, FINER, FINE, INFO, SEVERE, ALL.
  • timeout: especifica o período durante o qual a sessão de registo vai funcionar para o nível de registo especificado. Após o tempo limite, o nível de registo reverte para INFO.

Em caso de êxito, a API devolve um ID da sessão para a sessão de registo.