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

<ph type="x-smartling-placeholder"></ph> Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie zur Apigee X-Dokumentation. Weitere Informationen

Symptom

Das folgende Bild zeigt, dass API-Anfragen in der Edge-Benutzeroberfläche nicht erfasst werden, wenn eine Ablaufverfolgungssitzung 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 einen Fehler beim Erfassen von API-Anforderungen in Edge-UI-Trace:

Ursache: Anfragen, die vom Message Processor nicht verarbeitet wurden

Diagnose

Um eine API-Anfrage in einer Ablaufverfolgungssitzung 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 am Einstiegspunkt zu Edge fehl (d.h. Router) oder fehlschlägt, bevor er vom Message Processor verarbeitet wird, kann der Trace nicht erfasst werden. Diese Szenarien werden unten näher 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. Ist dies der 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

  Mit dem folgenden Befehl können Sie die Netzwerkverbindung 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 möglicherweise einer der folgenden Fehler angezeigt:

  Received fatal alert: handshake_failure
  

  HTTP/1.1 400 Bad Request
  

  Möglicherweise wird auch ein SSL-Zertifikatfehler angezeigt.

• Auflösung

  In den folgenden Playbooks erfahren Sie, wie Sie diese Probleme beheben:

  TLS/SSL-Handshake-Fehler

  400 Ungültige Anfrage – Fehler beim SSL-Zertifikat

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

• Ursache

  In diesem Szenario kann der Apigee-Nachrichtenprozessor den API-Proxy für nicht finden. den angegebenen virtuellen Host und Pfad. Daher sehen Sie möglicherweise eines der folgende Fehler:

  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 finden Sie in diesem Playbook: 404 Proxy for Host kann nicht identifiziert werden.

Ursache: API-Proxy in Klassifizierungsstruktur nicht gefunden

Diagnose

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

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

1. Melden Sie sich bei jedem Message Processor an und prüfen Sie mit dem folgenden Befehl, ob die jeweilige 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 Versionen ausgegeben. Wenn beispielsweise Version 12 bereitgestellt ist, wird die folgende Ausgabe angezeigt:

   [ "12" ]
   

   Sofern nicht zeitweise HTTP-404-Fehler auftreten, wird wahrscheinlich die jeweilige Version bereitgestellt.

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 Processors fehlt, gehen Sie wie unten beschrieben vor.

Lösung

Führen Sie die folgenden Schritte aus, um dieses Problem zu beheben. Treffen Sie alle notwendigen Vorkehrungen, um Produktionsausfälle zu vermeiden, die durch den Neustart von Message Processor bei hoher Anfragelast entstehen können.

1. Melden Sie sich bei jedem Message Processor-Host an, bei dem 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 Versionen ausgegeben. Wenn beispielsweise Version 12 bereitgestellt ist, wird die folgende Ausgabe angezeigt:

   [ "12" ]
   

   Sofern nicht zeitweise HTTP-404-Fehler auftreten, wird wahrscheinlich die jeweilige Version bereitgestellt.

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, gehen Sie zu Diagnoseinformationen müssen erfasst werden.

Diagnoseinformationen erforderlich

Wenn das Problem trotz Befolgung 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