API-Anfragen werden nicht in der Edge-Benutzeroberfläche erfasst

Sie sehen die Dokumentation zu Apigee Edge.
Zur Apigee X-Dokumentation weitere Informationen

Symptom

Die folgende Abbildung zeigt, dass API-Anfragen nicht in der Edge-Benutzeroberfläche erfasst werden, wenn eine Trace-Sitzung gestartet wird:

Fehlermeldung

Wenn dieses Problem auftritt, werden in der Edge-Benutzeroberfläche keine Fehlermeldungen angezeigt.

Mögliche Ursachen

Die folgende Tabelle zeigt mögliche Ursachen für Fehler beim Erfassen von API-Anfragen in Edge-UI-Trace:

Ursache: Anfragen werden nicht vom Message Processor verarbeitet

Diagnose

Um eine API-Anfrage in einer Trace-Sitzung zu erfassen, muss die API-Anfrage vom Message Processor der Edge-Komponente verarbeitet werden. Es gibt mehrere Gründe, warum eine API-Anfrage möglicherweise nicht in einer Trace-Transaktion erfasst wird.

Wenn beispielsweise eine API-Anfrage Apigee Edge nicht erreicht, schlägt sie am Einstiegspunkt zu Edge fehl (d.h. Router) oder ausfällt, bevor sie vom Message Processor verarbeitet wird, kann die Trace nicht erfasst werden. Diese Szenarien werden nachfolgend genauer beschrieben.

Szenario 1: Anfragen erreichen Apigee Edge nicht

• Ursache

  In diesem Szenario wird der Fehler möglicherweise durch ein Problem mit der DNS-Auflösung oder der Netzwerkverbindung verursacht. In diesem Fall wird beim Ausführen dieses Befehls möglicherweise der folgende Fehler angezeigt:

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

  curl: (6) Could not resolve host: hostName
  

• Auflösung

  Sie können die DNS-Konfiguration mit dem folgenden Befehl prüfen:

  dig hostName

  Sie können die Netzwerkverbindung mit dem folgenden Befehl prüfen:

  telnet hostName port

Szenario 2: Anfragen schlagen am Apigee Edge-Router fehl

• Ursache

  In diesem Szenario wird der Fehler möglicherweise durch einen Fehler beim TLS/SSL-Handshake verursacht. In diesem Fall wird Ihnen möglicherweise einer der folgenden Fehler angezeigt:

  Received fatal alert: handshake_failure
  

  HTTP/1.1 400 Bad Request
  

  Möglicherweise wird auch ein Fehler beim SSL-Zertifikat angezeigt.

• Auflösung

  Informationen zur Behebung dieser Probleme finden Sie in den folgenden Playbooks:

  TLS/SSL-Handshakefehler

  400 Ungültige Anfrage – SSL-Zertifikatfehler

Szenario 3: Anfragen können nicht vom Message Processor verarbeitet werden

• Ursache

  In diesem Szenario kann der Apigee Message Processor den API-Proxy für den angegebenen virtuellen Host und Pfad nicht finden. Daher wird möglicherweise einer der folgenden Fehler angezeigt:

  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"
      }
    }
  }
  
  

• Auflösung

  Informationen zur Fehlerbehebung und Lösung dieses Problems finden Sie in diesem Playbook: 404 Proxy für Host konnte nicht identifiziert werden.

Ursache: API-Proxy wurde in der Klassifizierungsstruktur nicht gefunden

Diagnose

Wenn ein Message Processor einen API-Proxy in seiner Klassifizierungsstruktur nicht finden kann, werden API-Anfragen an diesen bestimmten Proxy nicht in Trace-Sitzungen in der Edge-Benutzeroberfläche angezeigt.

Führen Sie die folgenden Schritte aus, um festzustellen, ob dies der Fall ist:

1. Melden Sie sich bei jedem der Message Processor an und prüfen Sie mit dem folgenden Befehl, ob die spezifische Version der angeforderten API in der entsprechenden Umgebung des Message Processor bereitgestellt wurde:

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

   Beispielausgabe:

   Mit dem obigen Befehl wird eine Liste der bereitgestellten Überarbeitungen ausgegeben. Wenn beispielsweise Überarbeitung 12 bereitgestellt ist, sehen Sie die folgende Ausgabe:

   [ "12" ]
   

   Sofern keine vorübergehenden HTTP 404-Fehler auftreten, ist es wahrscheinlich, dass die spezifische Überarbeitung bereitgestellt wurde.

2. Lesen Sie die Klassifizierungsstruktur und prüfen Sie mit dem folgenden Befehl, ob der API-Proxy-Name vorhanden ist:

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

3. Wiederholen Sie die Schritte 1 und 2 für jeden Message Processor. Wenn der angegebene API-Proxy-Name in der Klassifizierungsstruktur eines der Message Processor fehlt, folgen Sie der unten angegebenen Lösung.

Lösung

Gehen Sie wie unten beschrieben vor, um das Problem zu beheben. Treffen Sie die notwendigen Vorsichtsmaßnahmen, um Produktionsausfälle zu vermeiden, die durch den Neustart von Message Processorn bei einer hohen Anfragelast entstehen können.

1. Melden Sie sich bei allen Message Processor-Hosts an, bei denen der spezifische API-Proxy in der Klassifizierungsstruktur fehlt, und verwenden Sie den folgenden Befehl, um den Message Processor neu zu starten:

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

2. Warten Sie nach dem Neustart mit dem folgenden Befehl, bis er aktiv wird:

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

3. Sobald der Message Processor bereit ist, überprüfen Sie die Verfügbarkeit des API-Proxys mit dem folgenden Befehl:

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

   Beispielausgabe:

   Mit dem obigen Befehl wird eine Liste der bereitgestellten Überarbeitungen ausgegeben. Wenn beispielsweise Überarbeitung 12 bereitgestellt ist, sehen Sie die folgende Ausgabe:

   [ "12" ]
   

   Sofern keine vorübergehenden HTTP 404-Fehler auftreten, ist es wahrscheinlich, dass die spezifische Überarbeitung bereitgestellt wurde.

4. Lesen Sie die Klassifizierungsstruktur und prüfen Sie mit dem folgenden Befehl, ob der API-Proxy-Name vorhanden ist:

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

   Wenn das Problem weiterhin besteht, lesen Sie den Artikel Diagnoseinformationen müssen erfasst werden.

Diagnoseinformationen müssen erfasst werden

Wenn das Problem nach Ausführung der obigen Anleitung weiterhin besteht, stellen Sie die folgenden Diagnoseinformationen zusammen und leiten Sie sie an den Apigee Edge-Support weiter:

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