Guida alla risoluzione dei problemi del processore di messaggi

Questo argomento descrive i passaggi che puoi seguire per risolvere i problemi relativi al processore di messaggi. Il processore dei messaggi fa parte del componente apigee-runtime. Vedi anche Panoramica configurazione del servizio di runtime.

Il probe di preparazione non riesce 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 processore di messaggi per gestire il traffico. In questo stato, il processore di messaggi non può definirsi "pronto".

Causa	Descrizione
Problema di connessione del sincronizzatore al management plane	Il sincronizzatore non è in grado di connettersi al management plane. Questo problema in genere si verifica quando esegui l'override dell'URL `contractProvider` e associ l'account di servizio errato. Ad esempio, se configuri un account di servizio per un deployment di staging con un URL `contractProvider` che punta al server di produzione.
Problema di connessione tra il processore di messaggi e il sincronizzatore	Se il nuovo MP viene visualizzato nell'ambito di un riavvio del pod o dello scalabilità automatica, potresti visualizzare questo errore. In genere, questo problema si verifica quando il sincronizzatore non funziona e il MP non è riuscito a caricare il proprio contratto.

Diagnosi: problema di connessione dal sincronizzatore al control plane

Per diagnosticare un problema di connessione del sincronizzatore al management plane:

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 seguente directory:

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

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 numero della cartella del contratto. Nell'esempio riportato sopra (e mostrato anche di seguito), il nome della cartella è 750; pertanto, non corrispondono:
```
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 si verifica una mancata corrispondenza della versione come spiegato sopra, controlla i log del sincronizzatore per cercare di determinare perché i contratti più recenti 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 funziona, prova a riavviarlo utilizzando apigeectl. Ad esempio:

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

Diagnosi: problema di connessione tra il processore di messaggi e il sincronizzatore

Per diagnosticare un problema di connessione tra il processore di messaggi e il sincronizzatore:

Elenca i pod nel cluster:
```
kubectl get pods -n namespace
```

Controlla i log di runtime per cercare di capire perché i contratti non vengono 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 nell'ambito di un riavvio del pod o della scalabilità automatica, è possibile che non carichi i contratti. In genere, il problema si verifica quando il sincronizzatore non è attivo, impedendo al MP 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 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

Le lunghezze delle chiavi di crittografia supportate sono 16, 24 o 32 byte e il valore della chiave deve essere codificato in base64. Per saperne di più su come creare una chiave formattata correttamente, vedi Crittografia dei dati.

Visualizzazione dei log del processore di messaggi

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

Chiamare un proxy API dal pod di runtime

In alcune situazioni, per isolare un problema, potresti voler verificare se puoi effettuare una chiamata proxy API direttamente dall'interno del pod apigee-runtime, bypassando così il gateway di ingresso.

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

Chiama un proxy API di cui è stato eseguito il deployment. Ad esempio, se il percorso 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 Management

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

Recupera 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'API classification/tree, come mostrato 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"
    }
  }
} ]

Utilizzo della modalità DEBUG

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

Elenca i pod nel tuo spazio dei nomi:
```
kubectl get pods -n namespace
```
Scegli uno dei pod apigee-runtime elencati per il debug.

Esegui il comando di port forwarding per il pod. Ad esempio:

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

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
```
Esegui il comando kubectl logs per controllare il log in modalità DEBUG. Ad esempio:
```
kubectl logs -f -n hybrid apigee-runtime-hybrid-prod-blue-fcpdd
```
Al termine dell'esame del log DEBUG, reimposta il livello di log su INFO (il valore predefinito). Ad esempio:
```
curl "https://0:8843/v1/logsessions?sessions=info" -X POST -v -k
```
Esegui il comando kubectl logs per assicurarti che il log sia di nuovo in modalità INFO.

Guida alla risoluzione dei problemi del processore di messaggi Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Il probe di preparazione non riesce con il codice di stato HTTP 500

Sintomo

Messaggio di errore

Cause possibili

Diagnosi: problema di connessione dal sincronizzatore al control plane

Risoluzione

Diagnosi: problema di connessione tra il processore di messaggi e il sincronizzatore

Risoluzione

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

Sintomo

Diagnosi

Risoluzione

Visualizzazione dei log del processore di messaggi

Chiamare un proxy API dal pod di runtime

Controlla l'API Management

Utilizzo della modalità DEBUG

Guida alla risoluzione dei problemi del processore di messaggi