500 Interner Serverfehler – Back-End-Server

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

Videos

Video Beschreibung
500 Interner Serverfehler – verursacht durch Back-End Zeigt einen Echtzeit-500 Internal Server Error, der vom Back-End-Server verursacht wird, sowie Schritte zur Fehlerbehebung.

Symptom

Die Clientanwendung erhält den HTTP-Statuscode 500 mit der Nachricht Internal Server Error als Antwort auf API-Aufrufe.

Der HTTP-Statuscode 500 ist eine allgemeine Fehlerantwort. Dies bedeutet, dass auf dem Server eine unerwartete Bedingung aufgetreten ist, die die Ausführung der Anfrage verhindert hat. Dieser Fehler wird normalerweise vom Server zurückgegeben, wenn kein anderer Fehlercode geeignet ist.

Fehlermeldungen

Die Clientanwendung ruft den folgenden Antwortcode ab: 

HTTP/1.1 500 Internal Server Error

Außerdem wird möglicherweise eine Fehlermeldung wie die folgende angezeigt:

Beispiel 1

Beispiel für Back-End-Serverantwort Nr. 1

{"errorMessage":"Sorry either your e-mail or password didn't match.",
"errorParameters":"{}",
"errorCode":"500",
"errorKey":"INVALID_EMAILPASSWORD"}

Beispiel 2

Beispiel für eine Back-End-Serverantwort Nr. 2

<Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
   <Body>
      <Error>
         <code>500</code>
         <message xml:lang="en-US">Not Authorised(e4138fa0-ec57).</message>
      </Error>
   </Body>
</Envelope>

Mögliche Ursachen

500 Internal Server Error kann aus verschiedenen Gründen vom Back-End-Server zurückgegeben werden. In diesem Playbook wird erläutert, wie sich dieser Fehler unabhängig von seiner Ursache beheben lässt.

Mögliche Ursachen:

Ursache Beschreibung Anleitungen zur Fehlerbehebung gelten für
Fehler im Back-End-Server Der Back-End-Server kann aus irgendeinem Grund ausfallen. Nutzer von Edge Private und Public Cloud

Allgemeine Diagnoseschritte

Verwenden Sie eines der folgenden Tools oder Methoden, um diesen Fehler zu diagnostizieren:

API-Monitoring

Prozedur 1: API-Monitoring verwenden

So diagnostizieren Sie den Fehler mithilfe von API-Monitoring:

  1. Melden Sie sich in der Apigee Edge-UI als Nutzer mit einer entsprechenden Rolle an.

  2. Wechseln Sie zu der Organisation, in der Sie das Problem untersuchen möchten.

  3. Rufen Sie die Seite Analysieren > API-Überwachung > Untersuchen auf.
  4. Wählen Sie den Zeitraum aus, in dem Sie die Fehler beobachtet haben.

  5. Stellen Sie den Fehlercode der Zeit gegenüber.

  6. Wählen Sie eine Zelle mit dem Fehlercode messaging.adaptors.http.flow.ErrorResponseCode aus, wie unten dargestellt:

    ( größeres Bild ansehen)

  7. Informationen zum Fehlercode messaging.adaptors.http.flow.ErrorResponseCode werden wie unten dargestellt angezeigt:

    ( größeres Bild ansehen)

  8. Klicken Sie auf Logs ansehen und maximieren Sie die Zeile für die fehlgeschlagene Anfrage.

    ( größeres Bild ansehen)

  9. Notieren Sie sich im Fenster Logs die folgenden Details:
    • Nachrichten-ID der Anfrage
    • Statuscode: 500
    • Fehlerquelle: target
    • Fehlercode: messaging.adaptors.http.flow.ErrorResponseCode

Trace

Verfahren 2: Trace-Tool verwenden

So diagnostizieren Sie den Fehler mit dem Trace-Tool:

  1. Aktivieren Sie die Trace-Sitzung und entweder
    • Warten Sie, bis der Fehler 500 Internal Server Error mit dem Fehlercode messaging.adaptors.http.flow.ErrorResponseCode auftritt, oder
    • Wenn Sie das Problem reproduzieren können, führen Sie den API-Aufruf aus, um das Problem zu reproduzieren. 500 Internal Server Error

  2. Achten Sie darauf, dass Show all FlowInfos aktiviert ist:

  3. Wählen Sie eine der fehlgeschlagenen Anfragen aus und prüfen Sie den Trace.
  4. Gehen Sie die verschiedenen Phasen des Trace durch und ermitteln Sie, wo der Fehler aufgetreten ist.

  5. Der Fehler tritt normalerweise in einem Ablauf nach der Phase Antwort vom Zielserver erhalten auf, wie unten dargestellt:

    ( größeres Bild ansehen)

  6. Gehen Sie im Trace zur Phase AX (Analytics Data Recorded) und klicken Sie darauf.

  7. Scrollen Sie nach unten zum Abschnitt Phase Details Response Headers (Phasendetails-Antwortheader) und bestimmen Sie die Werte für X-Apigee-Fehler-Code, X-Apigee-Fehler-Quelle und X-Apigee-Message-ID wie unten dargestellt:

    ( größeres Bild ansehen)

  8. Beachten Sie die Werte von X-Apigee-fault-code, X-Apigee-fault-code und X-Apigee-fault-code:
    9. Antwortheader Wert
    X-Apigee-fault-code messaging.adaptors.http.flow.ErrorResponseCode
    X-Apigee-fault-source target
    X-Apigee-Message-ID MESSAGE_ID

NGINX

Verfahren 3: NGINX-Zugriffslogs verwenden

So diagnostizieren Sie den Fehler mithilfe von NGINX-Zugriffslogs:

  1. Wenn Sie ein Private Cloud-Nutzer sind, können Sie mithilfe von NGINX-Zugriffslogs die wichtigsten Informationen zu HTTP-500 Internal Server Error ermitteln.

  2. Prüfen Sie die NGINX-Zugriffslogs:

    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

  3. Prüfen Sie, ob während eines bestimmten Zeitraums (wenn das Problem in der Vergangenheit aufgetreten ist) 500-Fehler mit dem Fehlercode messaging.adaptors.http.flow.ErrorResponseCode aufgetreten sind oder ob es immer noch Anfragen mit 500 gibt, die fehlschlagen.

  4. Wenn Sie 500-Fehler mit dem X-Apigee-fault-code finden, der mit dem Wert von X-Apigee-fault-code übereinstimmt, bestimmen Sie den Wert von X-Apigee-fault-code .

    Beispiel für einen 500-Fehler aus dem NGINX-Zugriffslog:

    ( größeres Bild ansehen)

    Der obige Beispieleintrag aus dem NGINX-Zugriffslog enthält die folgenden Werte für X-Apigee-fault-code und X-Apigee-fault-code :

    Header Wert
    X-Apigee-fault-code messaging.adaptors.http.flow.ErrorResponseCode
    X-Apigee-fault-source target

Ursache: Fehler im Back-End-Server

Diagnose

Das vom Back-End-Server zurückgegebene 500 Internal Server Error kann verschiedene Ursachen haben. Sie müssen jede Situation einzeln diagnostizieren.

  1. Bestimmen Sie den Fehlercode, die Fehlerquelle für den mithilfe von API-Monitoring, dem Trace-Tool oder NGINX-Zugriffslogs beobachteten Fehler, wie unter Allgemeine Diagnoseschritte erläutert.
  2. Wenn die Fehlerquelle target und der Fehlercode messaging.adaptors.http.flow.ErrorResponseCode ist, bedeutet dies, dass der Fehler vom Back-End-Server zurückgegeben wird.
  3. Sie können mit einem der folgenden Schritte die Ursache des Problems ermitteln:

    Trace

    Trace verwenden:

    Wenn für den Fehler eine Trace-Sitzung vorhanden ist, führen Sie die folgenden Schritte aus:

    1. Wählen Sie in Trace die API-Anfrage aus, die mit 500 Internal Server Error fehlgeschlagen ist.

    2. Wählen Sie die Phase Antwort vom Zielserver erhalten aus der fehlgeschlagenen API-Anfrage aus, wie in der folgenden Abbildung dargestellt:

      ( größeres Bild ansehen)

    3. Scrollen Sie nach unten zum Abschnitt Phasendetails und prüfen Sie den Antwortinhalt,der die Antwort des Back-End-Servers enthält.

      Beispiel für Antwortinhalt:

      <Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
   <Body>
      <Error>
         <code>500</code>
         <message xml:lang="en-US">Not Authorised(e4138fa0-ec57).</message>
      </Error>
   </Body>
</Envelope>

      Beachten Sie in der obigen Antwort, dass die Fehlermeldung vom Back-End-Server Nicht autorisiert lautet. Dies weist darauf hin, dass der Nutzer möglicherweise ungültige Anmeldedaten weitergegeben hat. Aus diesem Grund wird dieser Fehler angezeigt.

    Back-End-Server aufrufen

    Direkte Aufrufe an den Back-End-Server:

    Sie können einen direkten Aufruf an den Back-End-Server senden und Folgendes tun:

    • Prüfen Sie, ob Sie die gleiche 500 Internal Server Error-Antwort erhalten wie bei der Anfrage über Apigee Edge.
    • Prüfen Sie die vom Back-End-Server erhaltene Fehlermeldung (Antwort)

    Führen Sie die folgenden Schritte aus, um den direkten Aufruf an den Back-End-Server zu senden:

    1. Prüfen Sie, ob alle erforderlichen Header, Abfrageparameter und alle Anmeldedaten vorhanden sind, die im Rahmen der Anfrage an den Back-End-Server übergeben werden müssen.
    2. Wenn der Back-End-Dienst öffentlich zugänglich ist, können Sie den Befehl curl, Postman oder einen anderen REST-Client verwenden und die Back-End-Server-API direkt aufrufen.

    3. Wenn der Back-End-Server nur von den Message Processorn aus zugänglich ist, können Sie den Befehl curl, Postman oder einen anderen REST-Client verwenden und die Back-End-Server-API direkt über den Message Processor aufrufen.

    4. Prüfen Sie, ob der Back-End-Dienst tatsächlich 500 Internal Server Error zurückgibt, und prüfen Sie die vom Back-End-Server zurückgegebene Fehlermeldung (Antwort) und ermitteln Sie die Ursache für diesen Fehler.

    Back-End-Serverlogs

    Back-End-Serverprotokolle verwenden

    1. Prüfen Sie die Back-End-Serverlogs und versuchen Sie, weitere Details zum Fehler und seiner Ursache zu erhalten.
    2. Aktivieren Sie nach Möglichkeit den Fehlerbehebungsmodus auf dem Back-End-Server, um weitere Details zum Fehler und zur Ursache zu erhalten.

  4. Prüfen Sie, ob Sie für den spezifischen Zielendpunkt des fehlerhaften API-Proxys Proxy-Verkettung verwenden, d. h., wenn der Zielserver/Zielendpunkt einen anderen Proxy in Apigee Edge aufruft. So ermitteln Sie dies:

    1. Wenn Sie den Trace für die fehlgeschlagene Anfrage haben, gehen Sie zur Phase Anfrage an Zielserver gesendet und klicken Sie auf Curl anzeigen.

    2. Das Fenster Curl for Request Sent to Target Server (Curl für an Zielserver gesendete Anfrage) wird geöffnet, in dem Sie den Alias des Zielserver-Hosts bestimmen können.
    3. Prüfen Sie den Zielendpunkt Ihres API-Proxys und prüfen Sie, ob die Back-End-Server-URL oder der Hostname auf dem Zielserver auf einen anderen Proxy oder Ihren eigenen Back-End-Server verweist.
    4. Wenn der Alias des Zielserver-Hosts auf einen virtuellen Hostalias verweist, handelt es sich um eine Proxyverkettung. In diesem Fall müssen Sie alle oben genannten Schritte für den verketteten Proxy wiederholen, bis Sie festgestellt haben, was den 500 Internal Server Error tatsächlich verursacht. In diesen Fällen kann 500 Internal Server Error auch in anderen verketteten Proxys in anderen Phasen auftreten, die mithilfe der Anweisungen in diesem Playbook oder im Playbook zu 500 Interner Serverfehler diagnostiziert und behoben werden können.
    5. Wenn der Hostalias des Zielservers auf Ihren Back-End-Server verweist, wechseln Sie zu Lösung.

Auflösung

Wenn festgestellt wird, dass der Fehler 500 vom Back-End-Server stammt, arbeiten Sie mit Ihrem Back-End-Serverteam zusammen, um das Problem entsprechend zu beheben.

Im oben beschriebenen Beispiel müssen Sie möglicherweise die Nutzer zur Weitergabe gültiger Anmeldedaten auffordern, um dieses Problem zu beheben.

Wichtige Hinweise

  1. Die tatsächliche Fehlermeldung, die vom Back-End-Server für 500 Internal Server Error zurückgegeben wird, kann nur angezeigt werden, wenn Sie die Trace-Sitzung für die fehlgeschlagenen Anfragen erfasst haben.
  2. Die Antwort des Back-End-Servers wird aus Sicherheitsgründen nicht in API-Monitoring-, NGINX-Zugriffslogs oder Message Processor-Logs protokolliert.
  3. Sie können die Back-End-Serverlogs prüfen oder den Fehlerbehebungsmodus auf dem Back-End aktivieren, um weitere Details zum 500 Internal Server Error zu erhalten und/oder die vom Back-End-Server zurückgegebene Fehlermeldung anzusehen.

Erfassen von Diagnoseinformationen erforderlich

Wenn das Problem auch nach Befolgen der obigen Anleitung weiterhin besteht, stellen Sie die folgenden Diagnoseinformationen zusammen und wenden Sie sich an den Apigee Edge-Support.

Wenn Sie ein Public Cloud-Nutzer sind, geben Sie die folgenden Informationen an:

  • Name der Organisation
  • Name der Umgebung
  • API-Proxy-Name
  • Führen Sie den Befehl curl aus, um den Fehler 500 zu reproduzieren.
  • Trace-Datei, die die Anfragen mit 500 Internal Server Error enthält
  • Wenn die 500-Fehler derzeit nicht auftreten, geben Sie den Zeitraum mit den Zeitzoneninformationen an, für die in der Vergangenheit 500-Fehler aufgetreten sind.

Wenn Sie ein Private Cloud-Nutzer sind, geben Sie die folgenden Informationen an:

  • Vollständige Fehlermeldung bei fehlgeschlagenen Anfragen
  • Organisation, Umgebungsname und API-Proxy-Name, für die Sie 500-Fehler beobachten
  • API-Proxy-Bundle
  • Trace-Datei, die die Anfragen mit 500 Internal Server Error enthält
  • NGINX-Zugriffslogs /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

    Hierbei gilt: ORG, ENV und PORT# werden durch tatsächliche Werte ersetzt.

  • Systemprotokolle von Message Processor /opt/apigee/var/log/edge-message-processor/logs/system.log
  • Der Zeitraum mit den Zeitzoneninformationen, in dem die 500-Fehler aufgetreten sind.