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

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

Symptom

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

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

Ursache	Beschreibung	Anleitungen zur Fehlerbehebung gelten für
Zielserver trennt die Verbindung vorzeitig	Der Zielserver beendet die Verbindung vorzeitig, während der Message Processor noch aktiv ist. das Senden der Anfragenutzlast.	Edge-Nutzer von öffentlichen und privaten Clouds

Allgemeine Diagnoseschritte

Nachrichten-ID der fehlgeschlagenen Anfrage ermitteln

Ursache: Zielserver trennt die Verbindung vorzeitig

Diagnose

1. Wenn Sie ein Public Cloud- oder Private Cloud-Nutzer sind: <ph type="x-smartling-placeholder">
   </ph>
   1. Das Trace-Tool verwenden (wie unter Allgemeine Diagnoseschritte erläutert) Prüfen Sie, ob im Bereich Aufgezeichnete Analytics-Daten die beiden folgenden Einstellungen festgelegt sind: <ph type="x-smartling-placeholder">
      </ph>
      • X-Apigee.fault-code: messaging.adaptors.http.flow.ServiceUnavailable
      • X-Apigee.fault-source: target

      

   2. Das Trace-Tool verwenden (wie unter Allgemeine Diagnoseschritte erläutert) und prüfen Sie, ob die beiden folgenden Einstellungen direkt nach dem Erstellen im Bereich Fehler die TARGET_REQ_FLOW-Property state:
      .
      • error.class::com.apigee.errors.http.server.ServiceUnavailableException
      • error.cause: Broken pipe

      

   3. Weitere Informationen finden Sie unter tcpdump verwenden.
2. Wenn Sie ein Private Cloud-Nutzer sind: <ph type="x-smartling-placeholder">
   </ph>
   • <ph type="x-smartling-placeholder"></ph> Ermitteln Sie die Nachrichten-ID der fehlgeschlagenen Anfrage.
   • Suchen Sie im Message Processor-Protokoll nach der Nachrichten-ID. (/opt/apigee/var/log/edge-message-processor/logs/system.log)
   • Es wird eine der folgenden Ausnahmen angezeigt:

     Ausnahme 1: java.io.IOException: Eine fehlerhafte Pipe ist beim Schreiben in den Kanal „ClientOutputChannel“ aufgetreten

     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-Ausnahme: {}
     java.io.IOException: Fehlerhafte 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 zeigen an, dass während der Message Processor an den Back-End-Server sendet, wurde die Verbindung vom Back-End-Server. Daher löst der Message Processor die Ausnahme java.io.IOException: Broken pipe aus.
   • Remote:IP:PORT gibt den aufgelösten Backend-Server an. IP-Adresse und Portnummer.
   • Das Attribut bytesWritten=76295 in der obigen Fehlermeldung gibt an, dass der Message Processor eine Nutzlast von 76295 Byte an das Back-End gesendet hat wenn die Verbindung vorzeitig beendet wurde.
   • Das Attribut bytesRead=0 gibt an, dass der Message Processor hat Daten (Antwort) vom Back-End-Server empfangen.
   • Um dieses Problem weiter zu untersuchen, erfassen Sie ein tcpdump im Back-End. Message Processor und analysiert sie wie unten beschrieben.

„tcpdump“ verwenden

1. Erfasse ein tcpdump auf dem Backend-Server oder dem Message Processor mit die folgenden Befehle:

   Befehl zum Abrufen von tcpdump auf dem Back-End-Server:

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

   Befehl zum Erfassen von tcpdump im Message Processor:

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

2. Analysieren Sie die erfassten tcpdump:

   tcpdump-Beispielausgabe (im Message Processor erfasst):

   

   In der tcpdump oben sehen Sie Folgendes:

   1. Im Paket 4 hat der Message Processor eine POST-Anfrage an auf dem Back-End-Server.
   2. Im Paket 5, 8, 9, 10 11, hat der Message Processor die Nutzlast der Anfrage weiterhin an die Back-End-Server.
   3. In den Paketen 6 und 7 hat der Backend-Server geantwortet mit ACK für einen Teil der vom Message Processor empfangenen Anfragenutzlast.
   4. Im Paket 12 antworten Sie jedoch nicht mit einem ACK. für die empfangenen Anwendungsdatenpakete und antwortet mit der Antwort verwendet, antwortet der Back-End-Server mit einem FIN ACK, wodurch Schließung der Verbindung.
   5. Dies zeigt deutlich, dass der Backend-Server die Verbindung vorzeitig beendet. während der Message Processor noch die Nutzlast der Anfrage sendete.
   6. Dies führt dazu, dass der Message Processor ein IOException: Broken Pipe aufzeichnet. Fehler und gibt 503 an den Client zurück

Auflösung

1. Analysieren und korrigieren Sie gemeinsam mit Ihrem Anwendungs- oder Ihrem Netzwerkteam die vorzeitige Verbindungstrennung aufseiten des Back-End-Servers verursacht.
2. Achten Sie darauf, dass die Backend-Serveranwendung keine Zeitüberschreitung auslöst oder die Verbindung zurücksetzt bevor die gesamte Nutzlast der Anfrage empfangen wird.
3. Wenn zwischen Apigee und Back-End-Server ein Netzwerkgerät oder eine Netzwerkschicht zwischengeschaltet ist, und stellen Sie sicher, dass keine Zeitüberschreitung auftritt, bevor die gesamte Nutzlast der Anfrage empfangen wurde.

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

Erfassen von Diagnoseinformationen erforderlich

Wenn das Problem trotz Befolgung der obigen Anleitung weiterhin besteht, stellen Sie Folgendes zusammen: Diagnoseinformationen und wenden Sie sich dann 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 curl-Befehl aus, um den 503-Fehler zu reproduzieren
• Ablaufverfolgungsdatei mit der Anfrage mit dem Fehler 503 Service Unavailable
• Falls die 503 Fehler derzeit nicht auftreten, geben Sie den Zeitraum mit Die Zeitzoneninformationen, wenn 503 Fehler in der Vergangenheit aufgetreten sind.

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

• Vollständige Fehlermeldung für fehlgeschlagene Anfragen
• Organisation, Umgebungsname und API-Proxy-Name, den Sie beobachten 503 Fehler
• API-Proxy-Bundle
• Ablaufdatei mit den Anfragen mit dem Fehler 503 Service Unavailable
• 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 wurde auf den Message Processors und dem Backend-Server erfasst, wenn der Fehler aufgetreten