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 test di idoneità non va a buon fine con il codice di stato HTTP 500
Sintomo
Uno o più pod apigee-runtime
non sono nello 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
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 indica che non è disponibile alcun contratto attivo per il gestore dei messaggi per pubblicare il 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 si verifica in genere quando sostituisci l'URL contractProvider e associ l'account di servizio sbagliato. 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: problema di connessione del sincronizzatore al piano di gestione
Per diagnosticare un problema di connessione del sincronizzazione con il piano di gestione:
- Elenca i pod nel cluster:
kubectl get pods -n namespace
- 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
- 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 - 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
- Assicurati che il valore di
active.version
corrisponda al nome della cartella del contratto numero. Nell'esempio riportato sopra (mostrato anche di seguito), il nome della cartella è750
; pertanto, non corrisponde:dr-xr-sr-x 4 apigee apigee 4096 Sep 12 16:52 750
- 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, vedi Log del sincronizzatore.
Se il sincronizzatore non è attivo, prova a riavviarlo utilizzando apigeectl
. Ad esempio:
$APIGEECTL_HOME/apigeectl apply -f overrides/overrides.yaml --org --env env-name
Diagnosi: problema di connessione del processore di messaggi al sincronizzatore
Per diagnosticare un problema di connessione tra processore di messaggi e connessione della sincronizzazione:
- Elenca i pod presenti nel cluster:
kubectl get pods -n namespace
- 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
È possibile che il nuovo MP venga visualizzato nell'ambito di un riavvio di autoscale o pod e che non carichi i contratti. In genere, il problema si verifica quando il sincronizzatore è inattivo, impedendo al proprietario del marketplace 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 --org --env env-name
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 utilizzi kubectl
per descrivere un pod apigee-runtime
non riuscito, viene visualizzato 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
La lunghezza delle chiavi di crittografia supportate è di 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 informazioni dettagliate sulla visualizzazione e sull'interpretazione dei log del processore dei 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 così il gateway in entrata.
- Esegui questo comando per eseguire l'inoltro alla porta 8443. Questo ti permette di chiamare l'API nel pod:
kubectl port-forward -n namespace apigee-runtime-pod-name 8443:8443
- 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.
- Ottieni i nomi dei pod nel tuo cluster:
kubectl get pods -n namespace
- Utilizza 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
- Poi, in un'altra finestra del terminale, utilizza un'utilità come
curl
per inviare una richiesta all'APIclassification/tree
, come mostrato 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" } } } ]
Utilizzare 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 dettagliato dei log per i pod apigee-runtime
.
Crea una sessione di log
Per creare una sessione di log per un pod di runtime:
- Elenca i pod di runtime. Per impostazione predefinita, si trovano nello spazio dei nomi
apigee
. Se hai scelto uno spazio dei nomi diverso, utilizza quello:kubectl get pods -n apigee
- Scegli uno dei
apigee-runtime
pod elencati di cui eseguire il debug. - 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
Ad esempio:
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 di log. Ad esempio:
9f831a7d-e533-4ead-8e58-12ec1059a622
- Stampa i log:
kubectl logs -f -n apigee RUNTIME_POD_NAME
Elenco sessioni di log
Per ottenere un elenco di tutte le sessioni di log attive per un pod runtime:
kubectl exec -it RUNTIME_POD_NAME -n apigee \ -- curl "https://0:8843/v1/logsessions" -k -v
Ottieni una sessione di log
Per visualizzare 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 visualizzare. I valori possibili includonoCONTRACT_REPLICATION
,DEBUG.SESSION
oALL
level
: specifica il livello di output del log. I valori possibili includonoFINEST
,FINER
,FINE
,INFO
,SEVERE
,ALL
.timeout
: specifica per quanto tempo la sessione di log funzionerà per la a livello di log specificato. Dopo il timeout, il livello del log torna aINFO
.
Se l'operazione riesce, l'API restituisce un ID sessione per la sessione del log.