502 Bad Gateway – Steckdose auflegen

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

Symptom

Die Clientanwendung empfängt 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

Ursache	Beschreibung	Anleitungen zur Fehlerbehebung gelten für
Falsch konfiguriertes Keep-Alive-Zeitlimit	Falsch konfigurierte Keep-Alive-Zeitüberschreitungen zwischen Edge Microgateway und dem Zielserver.	Nutzer von Edge Public und Private Cloud
Zielserver beendet die Verbindung vorzeitig	Der Zielserver schließt die Verbindung vorzeitig, während das Edge Microgateway die Nutzlast der Anfrage sendet.	Nutzer von Edge Public und Private Cloud

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 (ob das Problem in der Vergangenheit aufgetreten ist) oder ob Anfragen immer noch mit 502 fehlschlagen.

   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 Sie die Logging-Ebene auf warn oder info gesetzt haben, wird auch eine [warn]-Meldung angezeigt, die den Hostnamen und den Port des Zielservers im zweiten Element enthält. In diesem Beispiel ist das X.X.X.X:8080. Damit kann später ein tcpdump erfasst werden.

   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 mit Edge Microgateway geschlossen hat. Sie können in den Logs danach suchen, um zu ermitteln, wie oft es passiert.

Ursache: Falsch konfiguriertes Keep-Alive-Zeitlimit

Diagnose

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

2. Wenn ja, kannst du mithilfe von tcpdump wie unten erläutert weitere Nachforschungen anstellen:

„tcpdump“ verwenden

1. Erfassen Sie mit dem folgenden Befehl ein tcpdump zwischen Edge Microgateway und dem Back-End-Server auf dem Edge Microgateway-Hostbetriebssystem:

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

2. Analysieren Sie die erfassten tcpdump:

   tcpdump-Beispielausgabe: ( größeres Bild ansehen)

   

   Im obigen Beispiel-tcpdump wird Folgendes angezeigt:

   1. Im Paket 250288 sendet der Client eine POST-Anfrage.
   2. Im Paket 250371 antwortet der Server mit 200 OK.
   3. Im Paket 250559 sendet der Client eine ACK..
   4. Im Paket 250560 sendet der Server die Nachricht Continuation.
   5. Im Paket 250561 sendet der Client eine ACK..
   6. Im Paket 262436 sendet der Server eine FIN, ACK an den Client, wodurch die Beendigung der Verbindung initiiert wird. Dies ist etwa fünf Sekunden nach dem vorherigen Paket (250561).
   7. Im Paket 262441 sendet der Client eine weitere POST-Anfrage. Dieser Vorgang schlägt jedoch fehl, da der Server bereits die Schließung der Verbindung initiiert hat. Er antwortet mit einer RST im Paket 262441.

   Dieselbe Verbindung wurde in diesem Beispiel mindestens einmal erfolgreich wiederverwendet. Bei der letzten Anfrage löst der Server die Verbindung jedoch nach fünf Sekunden Inaktivität auf. Dabei hat der Client gleichzeitig eine neue Anfrage gesendet. Dies deutet darauf hin, dass das Keep-Alive-Zeitlimit des Back-End-Servers höchstwahrscheinlich kürzer oder gleich dem im Client festgelegten Wert ist. Informationen dazu finden Sie unter Keep-Alive-Zeitlimit auf Edge Microgateway und Back-End-Server vergleichen.

Keep-Alive-Zeitlimits vergleichen

1. Edge Microgateway hat kein bestimmtes Keep-Alive-Zeitlimitattribut. Sie wird durch das Betriebssystem bestimmt, auf dem sie ausgeführt wird. Gängige Beispiele sind Windows-, Linux- und Docker-Container.
2. Möglicherweise wurde dies im Betriebssystem angepasst. Wenden Sie sich an Ihren Systemadministrator. Bei Linux-Betriebssystemen gilt standardmäßig ein Keep-Alive-Zeitlimit von zwei Stunden.
3. Prüfen Sie als Nächstes das Attribut für die Keep-Alive-Zeitüberschreitung, das auf Ihrem Back-End-Server konfiguriert ist. Angenommen, Ihr Back-End-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 des Keep-Alive-Zeitlimits auf dem Back-End-Server wie im obigen Beispiel, dann ist dies die Ursache für 502-Fehler.

Auflösung

Achten Sie darauf, dass das Keep-Alive-Zeitlimitattribut auf dem Betriebssystem, auf dem Edge Microgateway ausgeführt wird, immer niedriger ist als auf dem Back-End-Server.

1. Legen Sie den Wert für das Keep-Alive-Zeitlimit auf dem Back-End-Server fest.
2. Konfigurieren Sie einen geeigneten Wert für das Keep-Alive-Zeitlimit-Attribut im Betriebssystem, sodass der Wert für das Keep-Alive-Zeitlimit unter dem Wert liegt, der auf dem Back-End-Server festgelegt ist. Folgen Sie dazu den Schritten für Ihr Betriebssystem.

Best Practices

Es wird dringend empfohlen, dass die nachgelagerten Komponenten immer einen geringeren Keep-Alive-Zeitlimitgrenzwert haben als auf den Upstream-Servern konfiguriert, um diese Art von Race-Bedingungen und 502-Fehlern zu vermeiden. Jeder nachgelagerte Hop sollte kleiner sein als jeder Upstream-Hop. In Edge Microgateway sollten Sie die folgenden Richtlinien verwenden:

1. Das Keep-Alive-Zeitlimit der Clientanwendung oder des Load-Balancers sollte kleiner als das Keep-Alive-Zeitlimit von Edge Microgateway sein.

   Fügen Sie der Datei ~/.edgemicro/org-env-config.yaml den Wert keep_alive_timeout hinzu, um das Keep-Alive-Zeitlimit auf Edge Microgateway zu konfigurieren.

   edgemicro:
     keep_alive_timeout: 65000
   

2. Das Keep-Alive-Zeitlimit des Edge Microgateway-Betriebssystems sollte kleiner als das Keep-Alive-Zeitlimit des Zielservers sein.
3. Wenn sich andere Hops vor oder hinter Edge Microgateway befinden, sollte dieselbe Regel angewendet werden. Sie sollten es immer in der Verantwortung des nachgelagerten Clients liegen, die Verbindung mit dem Upstream zu schließen.

Ursache: Zielserver schließt Verbindung vorzeitig

Diagnose

1. Folgen Sie der Anleitung unter Allgemeine Diagnoseschritte und prüfen Sie, ob der Fehler [socket hang up][ECONNRESET] auftritt.
2. Wenn ja, untersuchen Sie die Angelegenheit mithilfe von tcpdump wie unten erläutert.

   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 Back-End-Server (Zielserver) gesendet hat. Dies bedeutet, dass Edge Microgateway die API-Anfrage an den Back-End-Server gesendet und auf die Antwort gewartet hat. Der Back-End-Server hat die Verbindung jedoch abrupt beendet, bevor Edge Microgateway eine Antwort erhalten hat.

3. Prüfen Sie die Logs des Back-End-Servers auf Fehler oder Informationen, die dazu geführt haben könnten, dass der Back-End-Server die Verbindung abrupt beendet hat. Wenn Sie Fehler oder Informationen finden, gehen Sie zu Lösung und beheben Sie das Problem auf Ihrem Back-End-Server entsprechend.
4. Wenn Sie auf Ihrem Back-End-Server keine Fehler oder Informationen 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 die erfassten tcpdump:

   tcpdump-Beispielausgabe: ( größeres Bild ansehen)

   

   Im obigen Beispiel-tcpdump wird Folgendes angezeigt:

   1. Im Paket 4 hat Edge Microgateway eine GET-Anfrage an den Zielserver gesendet.
   2. Im Paket 5 hat der Zielserver mit ACK geantwortet, um die Anfrage zu bestätigen.
   3. Im Paket 6 sendet der Zielserver jedoch nicht mit einer Antwortnutzlast, sondern ein FIN, ACK, das das Schließen der Verbindung initiiert.
   4. Ab Paketen 7 wird die Verbindung gegenseitig geschlossen. Da die Verbindung vor dem Senden der Antwort geschlossen wurde, gibt Edge Microgateway den HTTP-Fehler 502 zurück an den Client.
   5. Beachten Sie, dass der Zeitstempel des Pakets 8, 2021-06-23T03:52:24.110Z , dem Zeitstempel entspricht, zu dem der Fehler in den Edge Microgateway-Logs protokolliert wurde. Die Zeitstempel in den Logdateien und im tcpdump können häufig verwendet werden, um die Fehler mit den tatsächlichen Paketen in Beziehung zu setzen.

   Auflösung

   Beheben Sie das Problem auf dem Back-End-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 Diagnoseinformationen müssen erfasst werden.

   Erfassen von Diagnoseinformationen erforderlich

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

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