502 Bad Gateway – Steckdose auflegen

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

Symptom

Die Clientanwendung erhält den HTTP-Statuscode 502 Bad Gateway mit dem Code ECONNRESET als Antwort auf API-Aufrufe in Edge Microgateway.

Fehlermeldung

Der Client sieht den folgenden Antwortcode:

HTTP/1.1 502 Bad Gateway

Die Antwort enthält die folgende Fehlermeldung:

{"message":"socket hang up","code":"ECONNRESET"}

Mögliche Ursachen

Allgemeine Diagnoseschritte

1. Prüfen Sie die Edge Microgateway-Logs:

   /var/tmp/edgemicro-`hostname`-*.log

2. Suchen Sie nach 502-Fehlern mit dem Code ECONNRESET innerhalb eines bestimmten Zeitraums (wenn das Problem in der Vergangenheit aufgetreten ist) oder nach Anfragen, bei denen weiterhin 502-Fehler auftreten.

   2021-06-23T03:52:24.110Z [error][0:8000][3][myorg][test]
   [emg_badtarget/flakey/hangup][][][6b089a00-d3d6-11eb-95aa-911f1ee6c684]
   [microgateway-core][][GET][502][socket hang up][ECONNRESET][]

3. Wenn die Logging-Ebene auf warn oder info festgelegt ist, wird auch eine [warn] Meldung mit dem Hostnamen und Port des Zielservers im zweiten Element angezeigt. In diesem Beispiel ist das X.X.X.X:8080. Dieser Wert kann später verwendet werden um einen tcpdump zu erfassen.

   2021-06-23T03:52:24.109Z
   [warn][X.X.X.X:8080][3][myorg][test][emg_badtarget/flakey/hangup]
   [][][6b089a00-d3d6-11eb-95aa-911f1ee6c684][plugins-middleware]
   [targetRequest error][GET][][socket hang up][ECONNRESET][395]

4. Der Fehlercode [socket hang up][ECONNRESET] gibt an, dass der Zielserver die Verbindung zu Edge Microgateway geschlossen hat. Sie können in den Logs danach suchen, um zu ermitteln, wie oft das passiert.

Ursache: Falsch konfiguriertes Keep-Alive-Zeitlimit

Diagnose

1. Führen Sie die Schritte unter Allgemeine Diagnoseschritte aus und prüfen Sie, ob der [socket hang up][ECONNRESET] Fehler aufgetreten ist.

2. Wenn ja, untersuchen Sie das Problem mit tcpdump weiter, wie unten beschrieben:

„tcpdump“ verwenden

1. Erfassen Sie ein tcpdump zwischen Edge Microgateway und dem Backend-Server im Betriebssystem des Edge Microgateway-Hosts mit dem folgenden Befehl:

   tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
   

2. Analysieren Sie den erfassten tcpdump:

   Beispielausgabe von „tcpdump“: ( größere Ansicht)

   

   Im obigen Beispiel für tcpdump sehen Sie Folgendes:

   1. In Paket 250288 sendet der Client eine POST-Anfrage.
   2. In Paket 250371 antwortet der Server mit 200 OK.
   3. In Paket 250559 sendet der Client ein ACK.
   4. In Paket 250560 sendet der Server die Continuation Nachricht.
   5. In Paket 250561 sendet der Client ein ACK.
   6. In Paket 262436 sendet der Server ein FIN, ACK an den Client, um das Schließen der Verbindung zu initiieren. Das ist etwa fünf Sekunden nach dem vorherigen Paket (250561).
   7. In Paket 262441 sendet der Client eine weitere POST Anfrage. Diese schlägt jedoch fehl, da der Server bereits das Schließen der Verbindung initiiert hat. Er antwortet mit einem RST in Paket 262441.

   Dieselbe Verbindung wurde in diesem Beispiel mindestens einmal erfolgreich wiederverwendet. Bei der letzten Anfrage initiiert der Server jedoch nach fünf Sekunden Inaktivität das Schließen der Verbindung. Das passiert gleichzeitig mit dem Senden einer neuen Anfrage durch den Client. Das deutet darauf hin, dass das Keep-Alive-Zeitlimit des Backend-Servers höchstwahrscheinlich kürzer oder gleich dem im Client festgelegten Wert ist. Informationen zum Prüfen finden Sie unter Keep-Alive-Zeitlimit in Edge Microgateway und auf dem Backend-Server vergleichen.

Keep-Alive-Zeitlimits vergleichen

1. Edge Microgateway hat keine spezifische Keep-Alive-Zeitlimit-Eigenschaft. Sie wird durch das Betriebssystem bestimmt, auf dem es ausgeführt wird. Häufige Beispiele sind Windows, Linux- und Docker-Container.
2. Möglicherweise wurde diese Einstellung im Betriebssystem angepasst. Wenden Sie sich an Ihren Systemadministrator. Standardmäßig haben Linux-Betriebssysteme ein Keep-Alive Zeitlimit von zwei Stunden.
3. Prüfen Sie als Nächstes die Keep-Alive-Zeitlimit-Eigenschaft, die auf Ihrem Backend-Server konfiguriert ist. Angenommen, Ihr Backend-Server ist mit einem Wert von 10 Sekunden konfiguriert.
4. Wenn Sie feststellen, dass der Wert des Keep-Alive-Zeitlimits im Betriebssystem höher ist als der Wert der Keep-Alive-Zeitlimit-Eigenschaft auf dem Backend-Server (wie im obigen Beispiel), ist das die Ursache für 502 Fehler.

Auflösung

Die Keep-Alive-Zeitlimit-Eigenschaft muss im Betriebssystem, auf dem Edge Microgateway ausgeführt wird, immer niedriger sein als auf dem Backend-Server.

1. Ermitteln Sie den für das Keep-Alive-Zeitlimit auf dem Backend-Server festgelegten Wert.
2. Konfigurieren Sie einen geeigneten Wert für die Keep-Alive-Zeitlimit-Eigenschaft im Betriebssystem sodass die Keep-Alive-Zeitlimit-Eigenschaft niedriger ist als der auf dem Backend-Server festgelegte Wert. Verwenden Sie dazu die Schritte, die für Ihr Betriebssystem gelten.

Best Practice

Es wird dringend empfohlen, dass die Downstream-Komponenten immer einen niedrigeren Keep-Alive-Zeitlimit Schwellenwert haben als die auf den Upstream-Servern konfigurierten Werte, um diese Art von Race-Bedingungen und 502 Fehler zu vermeiden. Jeder Downstream-Hop sollte niedriger sein als jeder Upstream-Hop. In Edge Microgateway sollten Sie die folgenden Richtlinien verwenden:

1. Das Keep-Alive-Zeitlimit in der Clientanwendung oder im Load-Balancer sollte niedriger sein als das Keep-Alive-Zeitlimit von Edge Microgateway.

   Wenn Sie das Keep-Alive-Zeitlimit in Edge Microgateway konfigurieren möchten, fügen Sie den keep_alive_timeout Wert in der ~/.edgemicro/org-env-config.yaml Datei hinzu.

   edgemicro:
     keep_alive_timeout: 65000

2. Das Keep-Alive-Zeitlimit des Betriebssystems von Edge Microgateway sollte niedriger sein als das Keep-Alive-Zeitlimit des Ziel servers.
3. Wenn Sie weitere Hops vor oder hinter Edge Microgateway haben, sollte dieselbe Regel angewendet werden. Es sollte immer in der Verantwortung des Downstream-Clients liegen, die Verbindung zum Upstream zu schließen.

Ursache: Zielserver schließt die Verbindung vorzeitig

Diagnose

1. Führen Sie die Schritte unter Allgemeine Diagnoseschritte aus und prüfen Sie, ob der [socket hang up][ECONNRESET] Fehler aufgetreten ist.
2. Wenn ja, untersuchen Sie das Problem mit tcpdump weiter, wie unten beschrieben.

   Die Fehlermeldung [targetRequest error][GET][][socket hang up][ECONNRESET] im obigen Beispiel gibt an, dass dieser Fehler aufgetreten ist, als Edge Microgateway die Anfrage an den Backend-Server (Zielserver) gesendet hat. Das heißt, Edge Microgateway hat die API-Anfrage an den Backend-Server gesendet und auf die Antwort gewartet. Der Backend Server hat die Verbindung jedoch abrupt beendet, bevor Edge Microgateway eine Antwort erhalten hat.

3. Prüfen Sie die Logs Ihres Backend-Servers und suchen Sie nach Fehlern oder Informationen, die dazu geführt haben könnten, dass der Backend-Server die Verbindung abrupt beendet hat. Wenn Sie Fehler oder Informationen finden, lesen Sie den Abschnitt Auflösung und beheben Sie das Problem entsprechend auf Ihrem Backend-Server.
4. Wenn Sie keine Fehler oder Informationen auf Ihrem Backend-Server finden, erfassen Sie die tcpdump Ausgabe auf dem Edge Microgateway-Server:

   tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
   

5. Analysieren Sie den erfassten tcpdump:

   Beispielausgabe von „tcpdump“: ( größere Ansicht)

   

   Im obigen Beispiel für tcpdump sehen Sie Folgendes:

   1. In Paket 4 hat Edge Microgateway eine GET Anfrage an den Ziel server gesendet.
   2. In Paket 5 hat der Zielserver mit ACK geantwortet, um die Anfrage zu bestätigen.
   3. In Paket 6 sendet der Zielserver jedoch anstelle einer Antwortnutzlast ein FIN, ACK, um das Schließen der Verbindung zu initiieren.
   4. In den Paketen 7 und danach wird die Verbindung beidseitig geschlossen. Da die Verbindung geschlossen wurde, bevor die Antwort gesendet wurde, gibt Edge Microgateway den HTTP 502 Fehler an den Client zurück.
   5. Der Zeitstempel von Paket 8, 2021-06-23T03:52:24.110Z entspricht dem Zeitstempel, zu dem der Fehler in den Edge Microgateway Logs protokolliert wurde. Die Zeitstempel in den Logdateien und im tcpdump können oft verwendet werden, um die Fehler den tatsächlichen Paketen zuzuordnen.

   Auflösung

   Beheben Sie das Problem auf dem Backend-Server entsprechend.

   Wenn das Problem weiterhin besteht und Sie Hilfe bei der Fehlerbehebung für 502 Bad Gateway Error benötigen oder vermuten, dass es sich um ein Problem in Edge Microgateway handelt, lesen Sie den Abschnitt 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:

   • Logdateien: Der Standardordner ist /var/tmp. Er kann jedoch in der Hauptdatei config.yaml (logging > dir parameter) überschrieben werden. Es wird empfohlen, log > level in info zu ändern, bevor Sie die Logdateien an den Apigee-Support senden.
   • Konfigurationsdatei: Die Hauptkonfiguration von Edge Microgateway befindet sich in der YAML-Datei im Standardordner von Edge Microgateway, $HOME/.edgemicro. Es gibt eine Standardkonfigurationsdatei namens default.yaml und dann eine für jede Umgebung ORG-ENV-config.yaml. Laden Sie diese Datei vollständig für die betroffene Organisation und Umgebung hoch.