502: Fehler wegen Zeitüberschreitung bei ungültigem Gateway

Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie zur Apigee X-Dokumentation. Weitere Informationen

Symptom

In der Clientanwendung wird der Fehler 502 Bad Gateway zurückgegeben. Der Message Processor gibt diesen Fehler an die Clientanwendung zurück, wenn er keine Antwort von einem Backend-Server erhält.

Fehlermeldung

Die Clientanwendung empfängt den folgenden Antwortcode:

HTTP/1.1 502 Bad Gateway

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

{
 "fault": {
    "faultstring":"Bad Gateway",
    "detail":{
        "errorcode":"messaging.adaptors.http.flow.BadGateway"
    }
 }
}

Mögliche Ursache

Die mögliche Ursache für dieses Problem ist in der folgenden Tabelle aufgeführt:

Ursache Beschreibung Schritte zur Fehlerbehebung können durch
TLS/SSL-Handshake-Zeitüberschreitung Während des TLS/SSL-Handshakes zwischen dem Nachrichtenprozessor und dem Back-End-Server tritt eine Zeitüberschreitung auf. Nutzer von Edge Private und Public Cloud

Ursache: Zeitüberschreitung beim TLS-/SSL-Handshake

In Apigee Edge können Sie eine TLS/SSL-Verbindung zum Back-End-Server einrichten, um die TLS-Kommunikation zwischen dem Edge Message Processor und einem Back-End-Server zu ermöglichen.

Ein TLS/SSL-Handshake umfasst mehrere Schritte. Dieser Fehler tritt in der Regel auf, wenn der TLS/SSL-Handshake zwischen dem Message Processor und einem Backend-Server abläuft.

Diagnose

In diesem Abschnitt wird beschrieben, wie Sie ein TLS/SSL-Handshake-Zeitlimit richtig diagnostizieren. Anleitungen für Edge Private Cloud und Public Cloud werden aufgeführt.

Ausgabe der Trace-Sitzung untersuchen

In den folgenden Schritten wird beschrieben, wie Sie mit dem Apigee Edge Trace-Tool eine vorläufige Diagnose des Problems durchführen.

  1. Aktivieren Sie in der Edge-Benutzeroberfläche eine Trace-Sitzung für den betroffenen API-Proxy.

  2. Wenn das Trace für die fehlgeschlagene API-Anfrage Folgendes anzeigt, ist wahrscheinlich ein Zeitüberschreitungsfehler beim TLS/SSL-Handshake aufgetreten. Der wahrscheinliche Grund für den Fehler ist, dass die Firewall des Back-End-Servers Traffic von Apigee blockiert.

    1. Prüfen Sie, ob der Fehler 502 Bad Gateway nach 55 Sekunden auftritt. Das ist die Standardzeitüberschreitung, die für den Message Processor festgelegt ist. Wenn Sie sehen, dass wenn der Fehler nach 55 Sekunden aufgetreten ist, wahrscheinliche Ursache des Problems.
    2. Prüfen Sie, ob der Fehler den Fehler anzeigt: messaging.adaptors.http.BadGateway. Auch dieser Fehler weist in der Regel auf eine Zeitüberschreitung hin.

    3. Wenn Sie Edge Private Cloud verwenden, beachten Sie den Wert des X-Apigee.Message-ID in der Trace-Ausgabe, wie unten gezeigt. Ein Private Cloud-Nutzer kann diesen ID-Wert für die weitere Fehlerbehebung verwenden, wie unten beschrieben.

      1. Klicken Sie im Trace-Pfad auf das Symbol Aufgezeichnete Analytics-Daten:

      2. Scrollen Sie nach unten und notieren Sie sich den Wert im Feld X-Apigee.Message-ID.

Um zu überprüfen, ob das TLS/SSL-Handshake-Zeitlimit die Ursache des Fehlers war, führen Sie die Schritte in den folgenden Abschnitten aus, je nachdem, ob Sie sich in der öffentlichen Cloud oder in der Private Cloud befinden.

Zusätzliche Diagnoseschritte nur für Edge Private Cloud-Nutzer

Wenn Sie die Apigee Edge Private Cloud verwenden, können Sie die folgenden Schritte ausführen, um die Ursache des Handshake-Fehlers zu ermitteln. In diesem Schritt prüfen Sie die Logdatei des Nachrichtenverarbeiters auf relevante Informationen. Wenn Sie die Edge Public Cloud verwenden, können Sie diesen Abschnitt überspringen und mit Weitere Schritte zur Fehlerbehebung für Nutzer der Private Cloud und Public Cloud fortfahren.

  1. Prüfen Sie mit dem Befehl telnet, ob Sie von jedem der Nachrichtenprozessoren direkt eine Verbindung zum jeweiligen Back-End-Server herstellen können:

    1. Wenn der Backend-Server in eine einzelne IP-Adresse aufgelöst wird, verwende diesen Befehl:

      telnet BackendServer-IPaddress 443

    2. Wenn der Backend-Server auf mehrere IP-Adressen aufgelöst wird, verwenden Sie den Hostnamen des Backend-Servers im Telnet-Befehl, wie unten gezeigt:

      telnet BackendServer-HostName 443

    Wenn Sie ohne Fehler eine Verbindung zum Backend-Server herstellen können, fahren Sie mit dem nächsten Schritt fort.

    Wenn der Befehl telnet fehlschlägt, müssen Sie mit Ihrem Netzwerkteam zusammenarbeiten, um die Verbindung zwischen dem Nachrichtenprozessor und dem Back-End-Server zu prüfen.

  2. Überprüfen Sie die Message Processor-Protokolldatei auf Hinweise auf einen Handshake-Fehler. Öffnen Sie die Datei:

    /opt/apigee/var/log/edge-message-processor/system.log

    Suchen Sie nach der eindeutigen Nachrichten-ID (dem Wert von X-Apigee.Message-ID, die Sie Sie in der Trace-Datei finden. Prüfen Sie, ob eine Handshake-Fehlermeldung mit der Nachrichten-ID verknüpft ist, wie unten dargestellt:

    org:xxx env:xxx api:xxx rev:x messageid:<MESSAGE_ID> NIOThread@1 ERROR HTTP.CLIENT -
HTTPClient$Context.handshakeTimeout() : SSLClientChannel[Connected: Remote:X.X.X.X:443
Local:X.X.X.X]@739028 useCount=1 bytesRead=0 bytesWritten=0 age=55221ms lastIO=55221ms
isOpen=true handshake timeout

Wenn dieser Fehler in der Protokolldatei des Prozessors auftritt, fahren Sie mit der weiteren Untersuchung fort. Rufen Sie Weitere Schritte zur Fehlerbehebung für Edge Private Cloud- und Public Cloud-Nutzer auf.

Wenn die Handshake-Nachricht nicht in der Protokolldatei angezeigt wird, fahre mit Diagnoseinformationen müssen erfasst werden fort.

Weitere Schritte zur Fehlerbehebung für Nutzer von Edge Private und Public Cloud

Um das Problem weiter einzugrenzen, können Sie mit dem Tool tcpdump TCP/IP-Pakete analysieren, um festzustellen, ob während des TLS/SSL-Handshake ein Zeitüberschreitung aufgetreten ist.

  1. Wenn Sie Private Cloud-Nutzer sind, können Sie die TCP/IP-Pakete auf dem Backend-Server oder Message Processor erfassen. Am besten erfassen Sie sie auf dem Back-End-Server, da die Pakete dort entschlüsselt werden.
  2. Wenn Sie ein Public Cloud-Nutzer sind, haben Sie keinen Zugriff auf die Nachricht. Prozessor; Es kann jedoch helfen, die TCP/IP-Pakete auf dem Back-End-Server zu erfassen. um ein Problem zu identifizieren.

  3. Nachdem Sie entschieden haben, wo Sie die TCP/IP-Pakete erfassen möchten, verwenden Sie den folgenden tcpdump-Befehl, um TCP/IP-Pakete zu erfassen.

    tcpdump -i any -s 0 host <IP address> -w <File name>

    • Wenn Sie die TCP/IP-Pakete auf dem Backend-Server entgegennehmen, verwenden Sie im Befehl tcpdump die öffentliche IP-Adresse des Message Processors. Hilfe zur Verwendung des um den Back-End-Server-Traffic zu untersuchen, finden Sie unter tcpdump.

    • Wenn Sie die TCP/IP-Pakete auf den Message Processor übertragen, verwenden Sie die öffentliche IP-Adresse des Back-End-Servers im Befehl tcpdump. Informationen zur Verwendung des Befehls zum Prüfen des Traffics des Nachrichten-Prozessors finden Sie unter tcpdump.

    • Wenn es mehrere IP-Adressen für den Backend-Server/Message Processor gibt, müssen Sie es mit einer anderen tcpdump-Befehlsverwendung versuchen. Weitere Informationen zu diesem Tool finden Sie unter tcpdump für andere Varianten dieses Befehls.

  4. TCP/IP-Pakete mit dem Wireshark-Tool analysieren oder ein ähnliches Tool. Der folgende Screenshot zeigt TCP/IP-Pakete in Wireshark.

  5. In der Wireshark-Ausgabe sehen Sie, dass der dreifache TCP-Handshake in den ersten drei Paketen erfolgreich abgeschlossen wird.

  6. Der Message Processor sendet dann die Nachricht „Client Hello“ in Paket Nr. 4 angezeigt.

  7. Da keine Bestätigung vom Back-End-Server vorliegt, wird die Meldung Der Prozessor überträgt die „Client Hello“-Anfrage noch einmal. in Paketen 5 mehrere Male gesendet, 6 und 7, nachdem ein vordefiniertes Zeitintervall gewartet wurde.

  8. Wenn der Message Processor nach drei Wiederholungsversuchen keine Bestätigung erhält, wird die Nachricht FIN, ACK an den Back-End-Server gesendet, um anzuzeigen, dass die Verbindung geschlossen wird.

  9. Wie Sie in der Wireshark-Beispielsitzung gezeigt haben, erfolgreich war (Schritt 1). Beim SSL-Handshake trat jedoch eine Zeitüberschreitung auf, da das Back-End Server nie geantwortet.

Wenn Sie die Schritte zur Fehlerbehebung in diesem Playbook ausgeführt haben und festgestellt haben, dass ein Das Zeitlimit hat den TLS/SSL-Handshake-Fehler verursacht. Rufen Sie den Abschnitt Lösung auf.

API-Monitoring zur Identifizierung eines Problems verwenden

Mit dem API-Monitoring können Sie Problembereiche schnell isolieren, um Fehler-, Leistungs- und Latenzprobleme sowie deren Quelle zu diagnostizieren, z. B. Entwickler-Apps, API-Proxys, Back-End-Ziele oder die API-Plattform.

In diesem Beispielszenario wird gezeigt, wie Sie mithilfe des API-Monitorings 5xx-Probleme mit Ihren APIs beheben. Sie können beispielsweise eine Benachrichtigung einrichten, die benachrichtigt wird, wenn die Anzahl der Fehler messaging.adaptors.http.BadGateway einen bestimmten Grenzwert überschreitet.

Auflösung

In der Regel treten Zeitüberschreitungen beim SSL-Handshake aufgrund von den Backend-Server, der den Traffic von Apigee Edge blockiert. Wenn Sie die Schritte zur Fehlerbehebung ausgeführt und festgestellt haben, dass der Handshake-Fehler auf eine Zeitüberschreitung zurückzuführen ist, müssen Sie Ihr Netzwerkteam bitten, die Ursache zu ermitteln und die Firewalleinschränkungen zu beheben.

Beachten Sie, dass die Firewall-Einschränkungen auf verschiedenen Netzwerkebenen gelten können. Es ist wichtig sicherzustellen, dass die Einschränkungen auf allen Netzwerkebenen entfernt werden, an die Message Processor-IPs, um einen reibungslosen Trafficfluss zwischen Apigee Edge zu gewährleisten und den Back-End-Server.

Wenn keine Firewall-Einschränkungen vorliegen und/oder das Problem weiterhin besteht, gehen Sie zu Es müssen Diagnoseinformationen erfasst werden.

Erfassen von Diagnoseinformationen erforderlich

Wenn das Problem auch nach Befolgen der obigen Anweisungen weiterhin besteht, erfassen Sie bitte die folgenden Diagnoseinformationen. Teilen Sie sie dem Apigee Edge-Support mit:

  1. Wenn Sie ein Nutzer der öffentlichen Cloud sind, geben Sie die folgenden Informationen an:
    1. Name der Organisation
    2. Umgebungsname
    3. API-Proxy-Name
    4. Vollständiger curl-Befehl zum Reproduzieren des Fehlers
    5. Trace-Datei mit dem Fehler
    6. Auf dem Backend-Server erfasste TCP/IP-Pakete
  2. Wenn Sie ein Private Cloud-Nutzer sind, geben Sie die folgenden Informationen an:
    1. Vollständige Fehlermeldung beobachtet
    2. API-Proxy-Bundle
    3. Trace-Datei mit dem Fehler
    4. Nachrichtenverarbeiter-Logs /opt/apigee/var/log/edge-message-processor/logs/system.log
    5. Auf dem Backend-Server oder Message Processor erfasste TCP/IP-Pakete.
  3. Details dazu, welche Abschnitte in diesem Playbook Sie ausprobiert haben, und alle anderen Informationen, die uns bei der schnellen Lösung dieses Problems helfen