Requêtes API non capturées dans l'interface utilisateur Edge

Vous consultez la documentation Apigee Edge.
Accédez à la documentation Apigee X.

Problème constaté

L'image suivante montre que les requêtes d'API ne sont pas capturées dans l'UI Edge lorsqu'une session de trace est démarrée :

Message d'erreur

Aucun message d'erreur ne s'affiche dans l'interface utilisateur Edge lorsque ce problème se produit.

Causes possibles :

Le tableau suivant présente les causes possibles d'un échec de capture des requêtes API dans la trace de l'UI Edge :

Cause : Requêtes non traitées par le processeur de messages

Diagnostic

Pour capturer une requête API dans une session Trace, la requête API doit être traitée par le composant Processeur de messages d'Edge. Plusieurs raisons peuvent expliquer qu'une requête API ne soit pas capturée dans une transaction Trace.

Par exemple, si une requête API n'atteint pas Apigee Edge ou échoue au point d'entrée d'Edge (c'est-à-dire routeur) ou échoue avant d'être traitée par le processeur de messages, la trace ne peut pas être capturée. Chacun de ces scénarios est décrit plus en détail ci-dessous.

Scénario 1 : Les requêtes n'atteignent pas Apigee Edge

• Cause

  Dans ce cas, l'erreur peut être due à un problème de résolution DNS ou de connectivité réseau. Si c'est le cas, l'erreur suivante peut s'afficher lorsque vous exécutez cette commande :

  curl https://hostName:port/apiProxyBasePath/requestPath
  

  curl: (6) Could not resolve host: hostName
  

• Solution

  Vous pouvez vérifier la configuration DNS à l'aide de la commande suivante :

  dig hostName

  Vous pouvez vérifier la connectivité réseau à l'aide de la commande suivante :

  telnet hostName port

Scénario 2 : Échec des requêtes au niveau du routeur Apigee Edge

• Cause

  Dans ce scénario, l'erreur peut être due à un échec du handshake TLS/SSL. Si c'est le cas, l'une des erreurs suivantes peut s'afficher :

  Received fatal alert: handshake_failure
  

  HTTP/1.1 400 Bad Request
  

  Une erreur de certificat SSL peut également s'afficher.

• Solution

  Consultez les playbooks suivants pour résoudre ces problèmes :

  Échecs du handshake TLS/SSL

  400 Requête incorrecte – Erreur de certificat SSL

Scénario 3 : les requêtes ne peuvent pas être traitées par le processeur de messages

• Cause

  Dans ce scénario, le processeur de messages Apigee ne trouve pas le proxy d'API pour l'hôte virtuel et le chemin d'accès spécifiés. Par conséquent, l'une des erreurs suivantes peut s'afficher :

  HTTP/1.1 404 Not Found
  

  {
    "fault":{
      "faultstring":"Unable to identify proxy for host: default and url: \/apiProxyBasePath/requestPath",
      "detail":{
        "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
      }
    }
  }

• Solution

  Consultez ce playbook pour résoudre ce problème : 404 Impossible d'identifier le proxy pour l'hôte.

Cause : Proxy d'API introuvable dans l'arborescence de classification

Diagnostic

Si un processeur de messages ne trouve pas de proxy d'API dans son arbre de classification, les requêtes API adressées à ce proxy spécifique ne s'afficheront pas dans les sessions de trace de l'interface utilisateur Edge.

Pour le savoir, suivez les étapes ci-dessous :

1. Connectez-vous à chacun des processeurs de messages et vérifiez si la révision spécifique de l'API demandée est déployée dans l'environnement concerné du processeur de messages à l'aide de la commande suivante :

   curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions
   

   Exemple de résultat :

   La commande ci-dessus génère une liste des révisions déployées. Par exemple, si la révision 12 est déployée, vous verrez le résultat suivant :

   [ "12" ]
   

   Sauf si vous rencontrez des erreurs HTTP 404 intermittentes, vous verrez probablement que la révision spécifique est déployée.

2. Lisez l'arborescence de classification et vérifiez l'existence du nom du proxy d'API à l'aide de la commande suivante :

   curl -i http://localhost:8082/v1/classification/tree | grep apiName
   

3. Répétez les étapes 1 et 2 pour chaque processeur de messages. Si le nom de proxy d'API indiqué est absent de l'arbre de classification de l'un des processeurs de messages, suivez la procédure de résolution ci-dessous.

Solution

Pour résoudre ce problème, veuillez suivre les étapes ci-dessous. Veillez à prendre toutes les précautions nécessaires pour éviter les interruptions de production qui peuvent survenir lors du redémarrage des processeurs de messages en cas de forte charge de requêtes.

1. Connectez-vous à chacun des hôtes du processeur de messages où le proxy d'API spécifique est manquant dans l'arborescence de classification, puis utilisez la commande ci-dessous pour redémarrer le processeur de messages :

   /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
   

2. Une fois redémarré, utilisez la commande ci-dessous pour attendre qu'il devienne actif :

   /opt/apigee/apigee-service/bin/apigee-service edge-message-processor wait_for_ready
   

3. Une fois le processeur de messages prêt, vérifiez la disponibilité du proxy d'API à l'aide de la commande suivante :

   curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions
   

   Exemple de résultat :

   La commande ci-dessus génère une liste des révisions déployées. Par exemple, si la révision 12 est déployée, vous verrez le résultat suivant :

   [ "12" ]
   

   Sauf si vous rencontrez des erreurs HTTP 404 intermittentes, vous verrez probablement que la révision spécifique est déployée.

4. Lisez l'arborescence de classification et vérifiez l'existence du nom du proxy d'API à l'aide de la commande suivante :

   curl -i http://localhost:8082/v1/classification/tree | grep apiName
   

   Si le problème persiste, consultez la page Vous devez collecter des informations de diagnostic.

Vous devez collecter des informations de diagnostic

Si le problème persiste après avoir suivi les instructions ci-dessus, veuillez rassembler les informations de diagnostic suivantes et les partager avec l'assistance Apigee Edge :

curl -v management-server-host:8080/v1/runtime/organizations/orgName/environments/envName/apis/apiProxyName/revisions/revisionNumber/debugsessions -u user

/opt/apigee/var/log/edge-management-server/logs/system.log

/opt/apigee/var/log/edge-message-processor/logs/system.log

telnet MessageProcessor_IP 8082

nc -vz MessageProcessor_IP 8082

netstat -an > netstat.txt

curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions

curl -i http://localhost:8082/v1/classification/tree