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

Vous consultez la documentation d'Apigee Edge.
Consultez la documentation Apigee X. en savoir plus

Problème constaté

L'image suivante montre que les requêtes API ne sont pas capturées dans l'interface utilisateur Edge lorsqu'une session de suivi 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 indique 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 de trace, la requête API doit être traitée par le composant de traitement des messages Edge 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 ne parvient pas à atteindre Apigee Edge, elle échoue au niveau du point d'entrée d'Edge (par exemple, 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 n'atteignent pas Apigee Edge

• Cause

  Dans ce scénario, l'erreur peut être due à une résolution DNS ou à un problème de connectivité réseau. Dans ce 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
  

• Ré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 au niveau du routeur Apigee Edge

• Cause

  Dans ce scénario, l'erreur peut être due à un échec du handshake TLS/SSL. Dans ce 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.

• Résolution

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

  Échecs de 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"
      }
    }
  }
  
  

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

Suivez les étapes ci-dessous pour déterminer si c'est le cas:

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 approprié 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, 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 de l'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é est absent de l'arborescence de classification de l'un des processeurs de messages, suivez la résolution ci-dessous.

Solution

Pour résoudre ce problème, procédez comme suit : Veillez à prendre les précautions nécessaires pour éviter toute interruption de production pouvant survenir en raison du redémarrage des processeurs de messages lorsque le chargement des requêtes est important.

1. Connectez-vous à chacun des hôtes de traitement de messages qui ne comportent pas de 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 que vous l'avez redémarré, exécutez la commande ci-dessous pour attendre qu'elle soit active:

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

3. Une fois que 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 génère une 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 de l'API à l'aide de la commande suivante:

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

   Si le problème persiste, consultez Obtention des informations de diagnostic requis.

Obtention d'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 communiquer à 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