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

<ph type="x-smartling-placeholder"></ph> Vous consultez la documentation Apigee Edge.
Accédez à la page Documentation sur Apigee X. En savoir plus

Symptôme

L'image suivante montre que les requêtes API ne sont pas capturées dans l'interface utilisateur Edge au démarrage d'une session de trace:

Message d'erreur

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

Causes possibles :

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

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 processeur de messages du composant 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 ne parvient pas à atteindre Apigee Edge, elle échoue au niveau du point d'entrée vers Edge (c'est-à-dire, routeur) ou échoue avant qu'elle ne soit 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 ne parviennent pas à atteindre Apigee Edge

• Cause

  Dans ce scénario, l'erreur peut être due à une résolution DNS ou à un problème de connectivité réseau. Si tel 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: les requêtes échouent sur le routeur Apigee Edge

• Cause

  Dans ce scénario, l'erreur peut être due à l'é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

  Reportez-vous aux playbooks suivants pour résoudre ces problèmes:

  Échecs de handshake TLS/SSL

  400 Bad Request - 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 parvient pas à trouver le proxy d'API pour l'hôte virtuel et le chemin d'accès spécifiés. Il se peut donc que l'un des les erreurs suivantes:

  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

  Reportez-vous à 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 parvient pas à trouver un proxy d'API dans son arborescence de classification, les requêtes API adressées à ce proxy spécifique ne seront pas affichées dans les sessions Trace dans l'interface utilisateur Edge.

Pour déterminer si tel est le cas, procédez comme suit:

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 correspondant 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 affiche la liste des révisions déployées. Par exemple, si la révision 12 est déployée, le résultat suivant s'affiche:

   [ "12" ]
   

   À moins que vous ne rencontriez des erreurs HTTP 404 intermittentes, vous constaterez 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 donné ne figure pas dans l'arborescence de classification de l'un des processeurs de messages, suivez la résolution ci-dessous.

Solution

Veuillez suivre les étapes ci-dessous pour résoudre ce problème. Veillez à prendre les précautions nécessaires pour éviter les pannes de production pouvant survenir en cas de redémarrage des processeurs de messages alors que les charges de requêtes sont élevées.

1. Connectez-vous à chacun des hôtes du processeur de messages pour lesquels il manque le proxy d'API spécifique dans l'arborescence de classification et 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é, exécutez la commande ci-dessous pour attendre qu'il devienne actif:

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

3. Lorsque le processeur de messages est 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 affiche la liste des révisions déployées. Par exemple, si la révision 12 est déployée, le résultat suivant s'affiche:

   [ "12" ]
   

   À moins que vous ne rencontriez des erreurs HTTP 404 intermittentes, vous constaterez 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 Collecter des informations de diagnostic.

Obligation de recueillir 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