Guida alla risoluzione dei problemi del processore di messaggi

In questo argomento vengono illustrati i passaggi che puoi svolgere per risolvere i problemi relativi all' elaboratore di messaggi. Il messaggio fa parte di apigee-runtime. Vedi anche Panoramica della configurazione del servizio di runtime.

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

Sintomo

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

Messaggio di errore

Quando usi kubectl per descrivere un pod apigee-runtime non riuscito, vedrai l'errore:

Readiness probe failed: HTTP probe failed with statuscode: 500

Ad esempio:

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 significa che non è disponibile nessun contratto attivo per la gestione del processore di messaggi per via del traffico. In questo stato, il processore di messaggi non può definirsi "ready".

Causa	Descrizione
Problema di connessione del sincronizzatore al piano di gestione	Il sincronizzatore non è in grado di connettersi al piano di gestione. Questo problema solitamente riguarda causato nei casi in cui esegui l'override dell'URL contractProvider e associ il con un account di servizio errato. Ad esempio, se configuri un account di servizio per un deployment gestione temporanea con un URL contractProvider che indirizza al server di produzione.
Problema di connessione tra il processore di messaggi e la sincronizzazione	Se il nuovo MP viene visualizzato nell'ambito di una scalabilità automatica o di un riavvio del pod, potresti visualizzare questo errore. In genere questo problema si verifica quando la sincronizzazione non è attiva e il file MP non è riuscito a caricare il relativo contratto.

Diagnosi: da sincronizzare per la gestione problema di connessione al piano

Per diagnosticare un problema di connessione del sincronizzazione con il piano di gestione:

1. Elenca i pod presenti 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

   Ad esempio:

   kubectl exec -it -n apigee apigee-synchronizer-apigee-gcp-prod1-test-blue-cnj5x bash

3. Vai alla directory seguente:

   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. Controlla la versione attiva in version.properties. Ad esempio:

   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 numero. Nell'esempio precedente (mostrato anche di seguito), il nome della cartella è 750; pertanto non corrispondenza:

   dr-xr-sr-x 4 apigee apigee  4096 Sep 12 16:52 750

6. Esci dalla shell del pod.

Risoluzione

Se version.properties non è presente o se è presente un'errata corrispondenza di versione, come spiegato in alto, controlla i log del sincronizzazione per provare a determinare perché la maggior parte dei contratti attuali non vengono scaricati. Ad esempio:

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

Per informazioni sull'interpretazione dei log del sincronizzatore, consulta Log del sincronizzatore. Se il sincronizzatore non è attivo, prova a riavviarlo utilizzando apigeectl. Ad esempio:

$APIGEECTL_HOME/apigeectl apply -f overrides/overrides.yaml -c synchronizer

Diagnosi: problema di connessione tra processore di messaggi e sincronizzazione

Per diagnosticare un problema di connessione tra processore di messaggi e connessione della sincronizzazione:

1. Elenca i pod presenti nel cluster:

   kubectl get pods -n namespace

2. Controlla i log di runtime per cercare di capire perché i contratti non possono essere scaricati:

   kubectl logs -f -n namespace pod-name

   Ad esempio:

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

   Se il nuovo MP viene visualizzato come parte di una scalabilità automatica o di un riavvio del pod, MP potrebbe non caricare i contratti. In genere, il problema si verifica quando il sincronizzatore non è attivo, impedendo al responsabile di caricare i contratti. Ad esempio:

   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. Ad esempio:

$APIGEECTL_HOME/apigeectl apply -f overrides/overrides.yaml -c synchronizer

Il probe di idoneità non riesce a causa di una chiave di crittografia non valida

Sintomo

I pod apigee-runtime non sono in stato Pronto.

Diagnosi

Quando usi kubectl per descrivere un pod apigee-runtime non riuscito, vedrai questo errore: Readiness probe failed: Probe hybrid-encryption-key-validation-probe failed. Ad esempio:

$ 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, 24 o 32 byte e il valore della chiave deve essere con codifica Base64. Per ulteriori informazioni sulla creazione di una chiave formattata correttamente, consulta Crittografia dei dati.

Visualizzazione dei log del processore di messaggi

Per maggiori dettagli sulla visualizzazione e sull'interpretazione dei log del processore di messaggi, consulta Log di runtime.

Chiama un proxy API dal pod di runtime

In alcune situazioni, per contribuire a isolare un problema, è consigliabile verificare se è possibile effettuare una chiamata proxy API direttamente all'interno del pod apigee-runtime, bypassando il gateway in entrata.

1. Esegui questo comando per eseguire l'inoltro alla porta 8843. Questo ti permette di chiamare l'API nel pod:

   kubectl port-forward -n namespace apigee-runtime-pod-name 8843:8843

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
   

Controlla 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 tuo cluster:

   kubectl get pods -n namespace

2. Utilizzare il port forwarding per accedere al pod apigee-runtime. La sintassi per il port forwarding è la seguente:

   kubectl port-forward -n namespace podname 8843:8843

   Ad esempio:

   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 informazioni sui proxy di cui è stato eseguito il deployment "test" questo ambiente:

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

Utilizzo della modalità DEBUG

Per facilitare la risoluzione dei problemi, puoi attivare la modalità DEBUG in modo da includere informazioni più dettagliate in apigee-runtime log dei pod.

1. Elenca i pod nel tuo spazio dei nomi:

   kubectl get pods -n namespace

2. Seleziona uno dei pod apigee-runtime elencati di cui eseguire il debug.
3. Esegui il comando di port forwarding per quel pod. Ad esempio:

   kubectl port-forward -n hybrid apigee-runtime-hybrid-prod-blue-fcpdd 8843

4. Apri un altro terminale e chiama la seguente API per attivare il debug:

   curl "https://0:8843/v1/logsessions?sessions=debug" -X POST -v -k

5. Esegui il comando kubectl logs per verificare il log in modalità DEBUG. Per esempio:

   kubectl logs -f -n hybrid apigee-runtime-hybrid-prod-blue-fcpdd
   

6. Una volta terminato di esaminare il log DEBUG, reimposta il livello di log su INFO (valore predefinito). Ad esempio:

   curl "https://0:8843/v1/logsessions?sessions=info" -X POST -v -k

7. Esegui il comando kubectl logs per assicurarti che il log sia di nuovo in modalità INFO.