502 Bad Gateway – Steckdose auflegen

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

<ph type="x-smartling-placeholder">

Symptom

Die Clientanwendung empfängt den HTTP-Statuscode 502 Bad Gateway mit dem Code ECONNRESET als Antwort für 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. Edge-Nutzer von öffentlichen und privaten Clouds
Zielserver trennt die Verbindung vorzeitig Der Zielserver trennt die Verbindung vorzeitig, während das Edge Microgateway sendet die Nutzlast der Anfrage. Edge-Nutzer von öffentlichen und privaten Clouds

Allgemeine Diagnoseschritte

  1. Prüfen Sie die Edge Microgateway-Logs: 
    /var/tmp/edgemicro-`hostname`-*.log
  2. Nach 502-Fehlern mit dem Code ECONNRESET suchen während eines bestimmten Zeitraums (wenn das Problem in der Vergangenheit aufgetreten ist) oder wenn es Anfragen schlagen immer noch mit 502 fehl. 
    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 festgelegt haben, wird auch eine [warn]-Nachricht mit dem Hostnamen des Zielservers und dem Port in der zweiten -Elements. In diesem Beispiel ist dies X.X.X.X:8080. Dies kann verwendet werden, um eine 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 hat die Verbindung mit Edge Microgateway geschlossen. Dies kann in den Protokollen durchsucht werden, um festzustellen, wie oft es passiert.

Ursache: Falsch konfiguriertes Keep-Alive-Zeitlimit

<ph type="x-smartling-placeholder">

Diagnose

  1. Folgen Sie der Anleitung unter Häufige Diagnoseschritte und stellen Sie sicher, dass das Gerät [socket hang up][ECONNRESET] Fehler.

  2. Falls ja, gehen Sie näher darauf ein. tcpdump wie unten beschrieben:

„tcpdump“ verwenden

  1. Erfassen Sie einen tcpdump zwischen Edge Microgateway und dem Backend-Server auf das Betriebssystem des Edge Microgateway-Hosts mit dem folgenden Befehl: 
    tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
  2. Analysieren Sie die erfassten tcpdump:

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

    In der obigen Beispiel-tcpdump sehen Sie Folgendes:

    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 das Continuation angezeigt.
    5. Im Paket 250561 sendet der Client eine ACK..
    6. Im Paket 262436 sendet der Server eine FIN, ACK an den Client, der die Verbindung schließt. Beachten Sie, dass dies etwa fünf Sekunden nach dem vorherigen Paket (250561)
    7. Im Paket 262441 sendet der Client eine weitere POST. Dies schlägt jedoch fehl, da der Server das Schließen der Er antwortet mit einem RST in einem Paket 262441.

    In diesem Beispiel wurde dieselbe Verbindung mindestens einmal erfolgreich wiederverwendet, aber auf Der Server löst die Beendigung der Verbindung nach fünf Sekunden aus. der Inaktivitätszeit, also der Zeitpunkt, zu dem der Client eine neue Anfrage gesendet hat. Dieses deutet darauf hin, dass das Keep-Alive-Zeitlimit des Back-End-Servers höchstwahrscheinlich kürzer oder gleich den im Client festgelegten Wert. Informationen zur Validierung finden Sie unter Vergleichen Sie das Keep-Alive-Zeitlimit für Edge Microgateway und den Back-End-Server.

Keep-Alive-Zeitlimits vergleichen

  1. Edge Microgateway hat kein spezielles Keep-Alive-Zeitüberschreitungsattribut. Es ist das vom Betriebssystem bestimmt wird, in dem es ausgeführt wird. Gängige Beispiele sind Windows, Linux- und Docker-Container.
  2. Es kann sein, dass dies im Betriebssystem angepasst wurde. Erkundigen Sie sich bei Ihrem Systemadministrators. Linux-Betriebssysteme haben standardmäßig einen Keep-Alive-Standard Timeout von zwei Stunden.
  3. Prüfen Sie als Nächstes die Eigenschaft für das Keep-Alive-Zeitlimit, die auf Ihrem Back-End-Server konfiguriert wurde. Lassen Sie uns Ihr Backend-Server ist mit einem Wert von 10 Sekunden konfiguriert.
  4. Wenn Sie feststellen, dass der Wert des Keep-Alive-Zeitlimits auf dem Betriebssystem ist höher als der Wert der Keep-Alive-Zeitüberschreitungseigenschaft auf dem Back-End-Server, wie in der oben im Beispiel, dann ist dies die Ursache für 502-Fehler.

Auflösung

Achten Sie darauf, dass die Keep-Alive-Zeitüberschreitungseigenschaft auf dem Betriebssystem, in dem Edge sich befindet, immer niedriger ist Microgateway wird im Vergleich zu dem auf dem Back-End-Server ausgeführt.

  1. Ermitteln Sie den für das Keep-Alive-Zeitlimit auf dem Back-End-Server eingestellten Wert.
  2. Konfigurieren Sie einen geeigneten Wert für das Keep-Alive-Zeitlimit unter der System, sodass die Eigenschaft für das Keep-Alive-Zeitlimit niedriger ist als der im Back-End festgelegte Wert für Ihr Betriebssystem ausführen.

Best Practice

Es wird dringend empfohlen, dass die Downstream-Komponenten immer ein geringeres Keep-Alive-Zeitlimit haben. Grenzwert als auf den Upstream-Servern konfiguriert, um diese Art von Race-Bedingungen und 502 Fehler. Jeder Downstream-Hop muss kleiner sein als jeder Upstream-Hop. Im Rand Microgateway verwenden, werden die folgenden Richtlinien empfohlen:

  1. Das Keep-Alive-Zeitlimit für die Clientanwendung oder den Load-Balancer sollte kleiner sein als die Keep-Alive-Zeitlimit für Edge Microgateway.

    Um das Keep-Alive-Zeitlimit auf dem Edge Microgateway zu konfigurieren, fügen Sie die Methode keep_alive_timeout auf Ihr ~/.edgemicro/org-env-config.yaml-Datei.

    edgemicro:
  keep_alive_timeout: 65000
    <ph type="x-smartling-placeholder">
  2. Das Keep-Alive-Zeitlimit des Edge Microgateway-Betriebssystems sollte kleiner als das Ziel sein Keep-Alive-Zeitüberschreitung des Servers.
  3. Wenn Sie weitere Hops vor oder hinter Edge Microgateway haben, sollte dieselbe Regel angewendet werden. Sie sollten es immer dem Downstream-Client überlassen, die Verbindung mit den Upstream-Elementen.
<ph type="x-smartling-placeholder">

Ursache: Zielserver trennt die Verbindung vorzeitig

<ph type="x-smartling-placeholder">

Diagnose

  1. Folgen Sie der Anleitung unter Häufige Diagnoseschritte und prüfen Sie, ob Sie hat den Fehler [socket hang up][ECONNRESET] erhalten.
  2. Falls ja, kannst du das Problem mithilfe von tcpdump wie unten beschrieben genauer untersuchen.

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

  3. Überprüfe deine Backend-Serverprotokolle auf Fehler oder Informationen, die möglicherweise haben den Back-End-Server dazu veranlasst, die Verbindung abrupt zu beenden. Wenn Sie Fehler oder rufen Sie Lösung auf und beheben Sie das Problem. auf Ihrem Back-End-Server.
  4. Wenn Sie auf Ihrem Backend-Server keine Fehler oder Informationen finden, erfassen Sie den 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)

    In der obigen Beispiel-tcpdump sehen Sie Folgendes:

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

    Auflösung

    Beheben Sie das Problem auf dem Backend-Server entsprechend.

    Wenn das Problem weiterhin besteht und du Hilfe bei der Fehlerbehebung benötigst 502 Bad Gateway Error Wenn Sie vermuten, dass ein Problem in Edge Microgateway vorliegt, gehen Sie zu Diagnoseinformationen müssen erfasst werden.

    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:

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