503 Dienst nicht verfügbar – Vorzeitiges Schließen durch Back-End-Server

Sie lesen gerade die Dokumentation zu Apigee Edge.
Zur Dokumentation zu Apigee X. info

Symptom

Die Clientanwendung erhält nach einem API-Proxy-Aufruf den HTTP-Antwortstatus 503 mit der Meldung Service Unavailable.

Fehlermeldung

Die Clientanwendung erhält den folgenden Antwortcode:

HTTP/1.1 503 Service Unavailable

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

{
   "fault": {
      "faultstring": "The Service is temporarily unavailable",
      "detail": {
           "errorcode": "messaging.adaptors.http.flow.ServiceUnavailable"
       }
    }
}

Mögliche Ursachen

Allgemeine Diagnoseschritte

Nachrichten-ID der fehlgeschlagenen Anfrage ermitteln

Ursache: Zielserver schließt Verbindung vorzeitig

Diagnose

1. Wenn Sie Nutzer von Public Cloud oder Private Cloud sind:
   1. Verwenden Sie das Trace-Tool (wie unter Allgemeine Diagnoseschritte) und prüfen Sie, ob im Bereich Erfasste Analysedaten beide folgenden Werte festgelegt sind:
      • X-Apigee.fault-code: messaging.adaptors.http.flow.ServiceUnavailable
      • X-Apigee.fault-source: target

      

   2. Verwenden Sie das Trace-Tool (wie unter Allgemeine Diagnoseschritte) und prüfen Sie, ob im Bereich Fehler direkt nach der E4/} Eigenschaft Status beide folgenden Werte festgelegt sind:
      TARGET_REQ_FLOW
      • error.class::com.apigee.errors.http.server.ServiceUnavailableException
      • error.cause::Broken pipe

      

   3. Weitere Informationen finden Sie unter „tcpdump“ verwenden.
2. Wenn Sie Nutzer von Private Cloud sind:
   • Ermitteln Sie die Nachrichten-ID der fehlgeschlagenen Anfrage.
   • Suchen Sie im Message Processor-Log (/opt/apigee/var/log/edge-message-processor/logs/system.log) nach der Nachrichten-ID.
   • Eine der folgenden Ausnahmen wird angezeigt:

     Ausnahme 1: java.io.IOException: Broken pipe occurred while writing to channel ClientOutputChannel

     2021-01-30 15:31:14,693 org:anotherorg env:prod api:myproxy
     rev:1 messageid:myorg-opdk-test-1-30312-13747-1  NIOThread@1
     INFO  HTTP.SERVICE - ExceptionHandler.handleException() :
     Exception java.io.IOException: Broken pipe occurred while writing to channel
     ClientOutputChannel(ClientChannel[Connected:
     Remote:IP:PORT Local:0.0.0.0:42828]@8380 useCount=1
     bytesRead=0 bytesWritten=76295 age=2012ms  lastIO=2ms  isOpen=false)

     oder

     Ausnahme 2: onExceptionWrite exception: {}
     java.io.IOException: Broken pipe

     2021-01-31 15:29:37,438 org:anotherorg env:prod api:503-test
     rev:1 messageid:leonyoung-opdk-test-1-18604-13978-1
     NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$2.onException() :
     ClientChannel[Connected: Remote:IP:PORT
     Local:0.0.0.0:57880]@8569 useCount=1 bytesRead=0 bytesWritten=76295 age=3180ms  lastIO=2
     ms  isOpen=false.onExceptionWrite exception: {}
     java.io.IOException: Broken pipe

   • Beide Ausnahmen weisen darauf hin, dass die Verbindung vorzeitig vom Backend-Server geschlossen wurde, während der Message Processor noch die Anfragenutzlast an den Backend-Server gesendet hat. Daher löst der Message Processor die Ausnahme java.io.IOException: Broken pipe aus.
   • The Remote:IP:PORT gibt die aufgelöste IP-Adresse und Portnummer des Backend-Servers an.
   • Das Attribut bytesWritten=76295 in der obigen Fehlermeldung gibt an, dass der Message Processor eine Nutzlast von 76295 Byte an den Backend-Server gesendet hat, als die Verbindung vorzeitig geschlossen wurde.
   • Das Attribut bytesRead=0 gibt an, dass der Message Processor keine Daten (Antwort) vom Backend-Server erhalten hat.
   • Um dieses Problem weiter zu untersuchen, erfassen Sie entweder auf dem Backend Server oder auf dem Message Processor einen tcpdump und analysieren Sie ihn wie unten beschrieben.

„tcpdump“ verwenden

1. Erfassen Sie einen tcpdump entweder auf dem Backend-Server oder auf dem Message Processor mit den folgenden Befehlen:

   Befehl zum Erfassen von tcpdump auf dem Backend-Server:

   tcpdump -i any -s 0 host MP_IP_ADDRESS -w FILE_NAME
   

   Befehl zum Erfassen von tcpdump auf dem Message Processor:

   tcpdump -i any -s 0 host BACKEND_HOSTNAME -w FILE_NAME
   

2. Analysieren Sie den erfassten tcpdump:

   Beispielausgabe von „tcpdump“ (auf dem Message Processor erfasst):

   

   Im obigen tcpdump sehen Sie Folgendes:

   1. In Paket 4 hat der Message Processor eine POST-Anfrage an den Backend-Server gesendet.
   2. In den Paketen 5, 8, 9, 10, 11 hat der Message Processor weiterhin die Anfragenutzlast an den Backend-Server gesendet.
   3. In den Paketen 6 und 7 hat der Backend-Server mit ACK für einen Teil der Anfragenutzlast geantwortet,die er vom Message Processor erhalten hat.
   4. In Paket 12 hat der Backend-Server jedoch nicht mit ACK für die empfangenen Anwendungsdatenpakete geantwortet und anschließend die Antwort nutzlast gesendet, sondern stattdessen mit FIN ACK geantwortet und damit das Schließen der Verbindung eingeleitet.
   5. Dies zeigt deutlich, dass der Backend-Server die Verbindung vorzeitig schließt während der Message Processor noch die Anfragenutzlast sendet.
   6. Dadurch zeichnet der Message Processor einen IOException: Broken Pipe Fehler auf und gibt 503 an den Client zurück.

Auflösung

1. Arbeiten Sie mit Ihrem Anwendungs- und Ihrem Netzwerkteam zusammen, um das Problem mit den vorzeitigen Verbindungsabbrüchen auf dem Backend-Server zu analysieren und zu beheben.
2. Achten Sie darauf, dass für die Backend-Serveranwendung kein Zeitlimit überschritten wird und die Verbindung nicht zurückgesetzt wird, bevor die gesamte Anfragenutzlast empfangen wurde.
3. Wenn Sie ein Netzwerkgerät oder eine Netzwerkschicht zwischen Apigee und dem Backend-Server haben, achten Sie darauf, dass das Zeitlimit nicht überschritten wird, bevor die gesamte Anfragenutzlast empfangen wurde.

Wenn das Problem weiterhin besteht, gehen Sie zu Erfassen von Diagnoseinformationen erforderlich.

Erfassen von Diagnoseinformationen erforderlich

Wenn das Problem auch nach Befolgen der obigen Anweisungen weiterhin besteht, sammeln Sie die folgenden Diagnoseinformationen und wenden Sie sich dann an den Apigee Edge-Support:

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

• Name der Organisation
• Name der Umgebung
• Name des API-Proxys
• Vollständiger curl-Befehl zum Reproduzieren des Fehlers 503
• Trace-Datei mit der Anfrage, die den Fehler 503 Service Unavailable enthält
• Wenn die 503-Fehler derzeit nicht auftreten, geben Sie den Zeitraum mit den Zeitzoneninformationen an, in dem die 503-Fehler in der Vergangenheit aufgetreten sind.

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

• Vollständige Fehlermeldung für die fehlgeschlagenen Anfragen
• Name der Organisation, Name der Umgebung und Name des API-Proxys, für die 503 Fehler auftreten
• API-Proxy-Bundle
• Trace-Datei mit den Anfragen, die den Fehler 503 Service Unavailable enthalten
• NGINX-Zugriffslogs
  /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
• Message Processor-Logs
  /opt/apigee/var/log/edge-message-processor/logs/system.log
• Der Zeitraum mit den Zeitzoneninformationen, in dem die 503-Fehler aufgetreten sind
• Tcpdumps erfasst auf den Message Processors und dem Backend-Server, als der Fehler aufgetreten ist