Guida alla risoluzione dei problemi del processore di messaggi

Questo argomento illustra i passaggi da seguire per individuare e risolvere i problemi relativi al processore di messaggistica. Il processore di messaggi fa parte del componente apigee-runtime. Vedi anche Panoramica della configurazione del servizio di runtime.

il probe di idoneità ha esito negativo con codice di stato HTTP 500

Sintomo

Uno o più pod apigee-runtime non sono in stato Pronto.

Messaggio di errore

Quando utilizzi kubectl per descrivere un pod apigee-runtime non riuscito, viene visualizzato l'errore:

Readiness probe failed: HTTP probe failed with statuscode: 500

Ecco alcuni esempi:

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

Cause possibili

L'errore indica che non è disponibile alcun contratto attivo per consentire al processore dei messaggi di gestire il traffico. In questo stato, il processore di messaggi non può definirsi "pronto".

Causa Descrizione
Problema di sincronizzazione con il piano di gestione Il sincronizzatore non è in grado di connettersi al piano di gestione. Questo problema di solito si verifica nei casi in cui esegui l'override dell'URL contractProvider e vi associate l'account di servizio errato. Ad esempio, se configuri un account di servizio per un deployment gestione temporanea con un URL contractProvider che rimanda al server di produzione.
Problema di connessione da processore di messaggi a sincronizzatore Potresti visualizzare questo errore se il nuovo MP è incluso nell'ambito di una scalabilità automatica o del riavvio del pod. In genere, questo problema si verifica quando il dispositivo di sincronizzazione non è attivo e l'MP non è riuscito a caricare il relativo contratto.

Diagnosi: problema di sincronizzazione con il piano di connessione del piano di gestione

Per diagnosticare un problema di sincronizzazione con il piano di gestione, segui questi passaggi:

  1. Elenca i pod nel cluster: 
    kubectl get pods -n namespace
  2. Apri una shell in un pod apigee-synchronizer: 
    kubectl exec -it -n namespace synchronizer-pod-name bash

    Ecco alcuni esempi:

    kubectl exec -it -n apigee apigee-synchronizer-apigee-gcp-prod1-test-blue-cnj5x bash
  3. Vai alla directory seguente: 
    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. Controlla la versione attiva in version.properties. Ecco alcuni esempi: 
    cat versions.properties

  #active repository version
  #Sat Dec 14 19:45:00 GMT 2019
  active.version=749
  5. Assicurati che il valore di active.version corrisponda al nome della cartella del contratto. Nell'esempio riportato sopra (anche in basso), il nome della cartella è 750; pertanto, non corrisponde a: 
    dr-xr-sr-x 4 apigee apigee  4096 Sep 12 16:52 750
  6. Esci dalla shell dei pod.

Risoluzione

Se version.properties non è presente o se è presente una corrispondenza errata della versione come spiegato in precedenza, controlla i log di sincronizzazione per provare a determinare il motivo per cui non vengono scaricati i contratti più recenti. Ecco alcuni esempi:

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

Per informazioni sull'interpretazione dei log di sincronizzazione, vedi Log di sincronizzazione. Se il sincronizzatore non è attivo, prova a riavviarlo usando apigeectl. Ecco alcuni esempi: 

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

Diagnosi: problema di connessione da processore di messaggi a Syncr

Per diagnosticare un problema di connessione del processore dei messaggi al Sync Sync:

  1. Elenca i pod nel cluster: 
    kubectl get pods -n namespace
  2. Controlla i log di runtime per provare a capire perché i contratti non vengono scaricati: 
    kubectl logs -f -n namespace pod-name

    Ecco alcuni esempi:

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

    È possibile che il nuovo MP venga fornito nell'ambito di una scalabilità automatica o di un riavvio del pod che non carica i contratti. In genere, il problema si verifica quando il sincronizzatore non è attivo, impedendo al file MP di caricare i contratti. Ecco alcuni esempi: 

    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)

Risoluzione

Prova a riavviare il sincronizzatore. Ecco alcuni esempi: 

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

il probe di idoneità non funziona per una chiave di crittografia non valida

Sintomo

I pod apigee-runtime non sono in stato Pronto.

Diagnosi

Quando utilizzi kubectl per descrivere un pod apigee-runtime non riuscito, viene visualizzato questo errore: Readiness probe failed: Probe hybrid-encryption-key-validation-probe failed. Ecco alcuni esempi: 

$ 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 = []}
...

Risoluzione

Le lunghezze delle chiavi di crittografia supportate sono 16 o 24 o 32 byte e il valore della chiave deve essere codificato in base64. Per maggiori informazioni sulla creazione di una chiave formattata correttamente, consulta Crittografia dei dati.

Visualizzazione dei log dell'elaboratore dei messaggi

Per informazioni dettagliate sulla visualizzazione e sull'interpretazione dei log del processore di messaggi, vedi Log di runtime.

Chiama un proxy API dal pod di runtime

In alcuni casi, per isolare un problema, ti consigliamo di verificare se puoi effettuare una chiamata proxy API direttamente dall'interno del pod apigee-runtime, ignorando quindi il gateway in entrata.

  1. Esegui questo comando per inoltrare alla porta 8443. In questo modo puoi chiamare l'API nel pod: 
    kubectl port-forward -n namespace apigee-runtime-pod-name 8443:8443
  2. Chiama un proxy API di cui è stato eseguito il deployment. Ad esempio, dove il percorso di base del 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

Controllare l'API di gestione

Puoi utilizzare l'API descritta di seguito per verificare se l'API di gestione funziona correttamente.

  1. Ottieni i nomi dei pod nel cluster: 
    kubectl get pods -n namespace
  2. Utilizza il port-forwarding per ottenere l'accesso al pod apigee-runtime. La sintassi per il port forwarding è la seguente: 
    kubectl port-forward -n namespace podname 8843:8843

    Ecco alcuni esempi:

    kubectl port-forward -n apigee \
    apigee-runtime-my-organization-test-blue-57965b7789-6j4bp 8843:8843
  3. Quindi, in un'altra finestra del terminale, utilizza un'utilità come curl per inviare una richiesta all'API classification/tree, come illustrato nell'esempio seguente: 
    curl -k https://0:8843/v1/classification/tree

    Ecco un esempio di risposta, che elenca le informazioni sui proxy di cui è stato eseguito il deployment nell'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"
    }
  }
} ]

Usa il logging per eseguire il debug dei problemi dei pod di runtime

Per facilitare la risoluzione dei problemi, puoi creare una sessione di log per produrre un output di log dettagliato per i pod apigee-runtime.

Crea una sessione di log

Per creare una sessione di log per un pod di runtime:

  1. Elenca i pod di runtime. Per impostazione predefinita, si trovano nello spazio dei nomi apigee. Se hai scelto uno spazio dei nomi diverso, utilizzalo: 
    kubectl get pods -n apigee
  2. Scegli uno dei apigee-runtime pod elencati per il debug.
  3. Crea una sessione di log nel pod di runtime di cui vuoi risolvere i problemi utilizzando l'API /logsessions. Per maggiori dettagli sull'API, vedi Informazioni sull'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

    Ecco alcuni esempi:

    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

    La risposta è un ID sessione log. Ad esempio: 9f831a7d-e533-4ead-8e58-12ec1059a622

  4. Stampa i log: 
    kubectl logs -f -n apigee RUNTIME_POD_NAME

Elenca sessioni di log

Per ottenere un elenco di tutte le sessioni di log attive per un pod di runtime:

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

Crea una sessione di log

Per ottenere i dettagli della sessione di log:

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

Terminare una sessione di log

Per terminare una sessione di log:

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

Informazioni sull'API logsessions

Questa sezione descrive i parametri di ricerca dell'API logsessions:

  • loggerNames: specifica il tipo di output di log da mostrare. I valori possibili includono CONTRACT_REPLICATION, DEBUG.SESSION o ALL
  • level: specifica il livello di output del log. I valori possibili includono FINEST, FINER, FINE, INFO, SEVERE, ALL.
  • timeout: specifica per quanto tempo la sessione di log funzionerà per il livello di log specificato. Dopo il timeout, il livello di log torna a INFO.

Se l'operazione riesce, l'API restituisce un ID sessione per la sessione di log.