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 redémarrage automatique ou 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 :

  1. Affichez la liste des pods du cluster :
    kubectl get pods -n namespace
  2. 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
  3. Accédez au répertoire suivant :
    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. 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
  5. 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
  6. 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 --org --env env-name

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 :

  1. Affichez la liste des pods du cluster : 
    kubectl get pods -n namespace
  2. Consultez les journaux d'exécution pour déterminer 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 --org --env env-name

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.

  1. 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 8443:8443
  2. 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.

  1. Récupérez les noms des pods de votre cluster :
    kubectl get pods -n namespace
  2. 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
  3. 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 la journalisation pour déboguer les problèmes de pod d'exécution

Pour vous aider à résoudre les problèmes, vous pouvez créer une session de journal afin de produire une sortie de journal détaillée pour les pods apigee-runtime.

Créer une session de journal

Procédez comme suit pour créer une session de journal pour un pod d'exécution :

  1. Listez les pods d'exécution. Ils se situent par défaut dans l'espace de noms apigee. Si vous avez choisi un autre espace de noms, utilisez-le à la place : 
    kubectl get pods -n apigee
  2. Choisissez l'un des pods apigee-runtime listés pour procéder au débogage.
  3. Créez une session de journal dans le pod d'exécution que vous souhaitez dépanner à l'aide de l'API /logsessions. Pour en savoir plus sur l'API, consultez la section À propos de l'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

    Exemple :

    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 réponse est un ID de session de journal. Par exemple : 9f831a7d-e533-4ead-8e58-12ec1059a622

  4. Imprimez les journaux : 
    kubectl logs -f -n apigee RUNTIME_POD_NAME

Lister les sessions de journal

Pour obtenir la liste de toutes les sessions de journal actives pour un pod d'exécution :

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

Obtenir une session de journal

Pour obtenir les détails d'une session de journal :

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

Mettre fin à une session de journal

Pour mettre fin à une session de journal :

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

À propos de l'API logsessions

Cette section décrit les paramètres de requête de l'API logsessions :

  • loggerNames : spécifie le type de sortie de journal à afficher. Les valeurs possibles incluent CONTRACT_REPLICATION, DEBUG.SESSION ou ALL.
  • level : spécifie le niveau de sortie du journal. Les valeurs possibles sont les suivantes : FINEST, FINER, FINE, INFO, SEVERE, ALL.
  • timeout : spécifie la durée de la session de journal pour le niveau de journalisation spécifié. Après expiration du délai, le niveau de journalisation revient à INFO.

En cas de réussite, l'API renvoie un ID de session pour la session de journalisation.