Guide de dépannage du processeur de messages

Cet article explique comment diagnostiquer et résoudre les problèmes liés au processeur de messages. Le processeur de messages fait partie du composant apigee-runtime. Consultez également la Présentation de la configuration des services d'exécution.

La vérification d'aptitude échoue et un code d'état HTTP 500 s'affiche

Symptôme

Un ou plusieurs pods apigee-runtime ne sont pas à l'état "Ready" (Prêt)

Message d'erreur

Lorsque vous utilisez kubectl pour décrire un pod apigee-runtime ayant échoué, l'erreur suivante s'affiche :

Readiness probe failed: HTTP probe failed with statuscode: 500

Exemple :

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

Causes possibles

L'erreur signifie qu'aucun contrat actif n'est disponible pour le processeur de messages afin de diffuser le trafic. Dans cet état, le processeur de messages ne peut pas se considérer en état "ready".

Cause	Description
Problème de connexion du synchronisateur au plan de gestion	Le synchronisateur ne parvient pas à se connecter au plan de gestion. Ce problème est généralement causé par un remplacement de l'URL `contractProvider` et l'association d'un compte de service inapproprié. Par exemple, si vous configurez un compte de service pour un déploiement intermédiaire avec une URL `contractProvider` qui pointe vers le serveur de production.
Problème de connexion du processeur de messages au synchronisateur	Si le nouveau processeur de messages apparaît dans le cadre d'un autoscaling ou du redémarrage d'un pod, cette erreur peut s'afficher. En règle générale, ce problème se produit lorsque le synchronisateur est indisponible et que le processeur de messages n'a pas pu charger son contrat.

Diagnostic : problème de connexion du synchronisateur au plan de gestion

Pour diagnostiquer un problème de connexion du synchronisateur au plan de gestion, procédez comme suit :

Affichez la liste des pods du cluster :
```
kubectl get pods -n namespace
```

Ouvrez une interface système dans un pod apigee-synchronizer :

kubectl exec -it -n namespace synchronizer-pod-name bash

Exemple :

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

Accédez au répertoire suivant :

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

Vérifiez la version active dans version.properties. Exemple :

cat versions.properties

  #active repository version
  #Sat Dec 14 19:45:00 GMT 2019
  active.version=749

Assurez-vous que la valeur de active.version correspond au nom du numéro de dossier du contrat. Dans l'exemple ci-dessus (également présenté ci-dessous), le nom du dossier est 750. Par conséquent, ils ne correspondent pas :
```
dr-xr-sr-x 4 apigee apigee  4096 Sep 12 16:52 750
```
Quittez l'interface système du pod.

Solution

Si la valeur version.properties est manquante ou si une version ne correspond pas, comme décrit ci-dessus, consultez les journaux du synchronisateur pour essayer de déterminer pourquoi les contrats les plus récents ne sont pas téléchargés. Exemple :

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

Pour en savoir plus sur l'interprétation des journaux du synchronisateur, consultez la page Journaux du synchroniseur. Si le synchronisateur est indisponible, essayez de le redémarrer à l'aide de apigeectl. Exemple :

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

Diagnostic : problème de connexion du processeur de messages au synchronisateur

Pour diagnostiquer un problème de connexion du processeur de messages au synchronisateur, procédez comme suit :

Affichez la liste des pods du cluster :
```
kubectl get pods -n namespace
```

Consultez les journaux d'exécution pour essayer de comprendre pourquoi les contrats ne sont pas téléchargés :

kubectl logs -f -n namespace pod-name

Exemple :

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

Il est possible que le nouveau processeur de messages fasse partie d'un autoscaling ou d'un redémarrage de pod, ce qui pourrait empêcher le chargement des contrats. En règle générale, le problème se produit lorsque le synchronisateur est indisponible, ce qui empêche le processeur de messages de charger les contrats. Exemple :

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)

Solution

Essayez de redémarrer le synchronisateur. Exemple :

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

La vérification d'aptitude échoue en raison d'une clé de chiffrement non valide

Symptôme

Les pods apigee-runtime ne sont pas à l'état "Ready" (Prêt)

Diagnostic

Lorsque vous utilisez kubectl pour décrire un pod apigee-runtime défaillant, vous obtenez l'erreur suivante : Readiness probe failed: Probe hybrid-encryption-key-validation-probe failed. Exemple :

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

Solution

Les longueurs de clé de chiffrement compatibles sont 16, 24 ou 32 octets, et la valeur de la clé doit être encodée en base64. Pour en savoir plus sur la création d'une clé correctement formatée, consultez la page Chiffrement des données.

Afficher les journaux du processeur de messages

Pour en savoir plus sur l'affichage et l'interprétation des journaux du processeur de messages, consultez la page Journaux d'exécution.

Appeler un proxy d'API à partir du pod d'exécution

Dans certains cas, pour vous aider à isoler un problème, vous pouvez vérifier si vous pouvez effectuer un appel de proxy d'API directement à partir du pod apigee-runtime et contourner ainsi la passerelle d'entrée.

Exécutez la commande suivante pour effectuer un transfert sur le port 8443. Cela vous permet d'appeler l'API dans le pod :
```
kubectl port-forward -n namespace apigee-runtime-pod-name 8843:8843
```

Appelez un proxy d'API déployé. Par exemple, si le chemin de base du proxy est 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

Vérifier l'API de gestion

Vous pouvez utiliser l'API décrite ci-dessous pour vérifier si l'API de gestion fonctionne correctement.

Récupérez les noms des pods de votre cluster :
```
kubectl get pods -n namespace
```

Utilisez le transfert de port pour accéder au pod apigee-runtime. La syntaxe de transfert de port est la suivante :

kubectl port-forward -n namespace podname 8843:8843

Exemple :

kubectl port-forward -n apigee \
    apigee-runtime-my-organization-test-blue-57965b7789-6j4bp 8843:8843

Ensuite, dans une autre fenêtre de terminal, utilisez un utilitaire tel que curl pour envoyer une requête à l'API classification/tree, comme le montre l'exemple suivant :

curl -k https://0:8843/v1/classification/tree

Voici un exemple de réponse qui répertorie les informations sur les proxys déployés dans l'environnement de test :

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

Utiliser le mode DEBUG

Pour faciliter le dépannage, vous pouvez activer le mode DEBUG pour inclure des informations plus détaillées dans les journaux des pods apigee-runtime.

Répertoriez les pods dans votre espace de noms :
```
kubectl get pods -n namespace
```
Choisissez l'un des pods apigee-runtime répertoriés pour effectuer le débogage.

Exécutez la commande de transfert de port pour ce pod. Exemple :

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

Ouvrez un autre terminal et appelez l'API suivante pour activer le débogage :
```
curl "https://0:8843/v1/logsessions?sessions=debug" -X POST -v -k
```
Exécutez la commande kubectl logs pour vérifier le journal en mode DEBUG. Exemple :
```
kubectl logs -f -n hybrid apigee-runtime-hybrid-prod-blue-fcpdd
```
Lorsque vous avez terminé d'examiner le journal DEBUG, réinitialisez le niveau de journalisation sur INFO (valeur par défaut). Exemple :
```
curl "https://0:8843/v1/logsessions?sessions=info" -X POST -v -k
```
Exécutez la commande kubectl logs pour vous assurer que le journal est à nouveau en mode INFO.