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

Sie sehen sich die Dokumentation zu Apigee Edge an.
Sehen Sie sich die Apigee X-Dokumentation an. info

Symptom

Die Clientanwendung erhält den Fehler 502 Bad Gateway. Der Message Processor gibt diesen Fehler an die Clientanwendung zurück, wenn sie keine Antwort von einem Back-End-Server empfängt.

Fehlermeldung

Die Clientanwendung empfängt den folgenden Antwortcode:

HTTP/1.1 502 Bad Gateway

Möglicherweise wird auch 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 von
TLS/SSL-Handshake-Zeitüberschreitung Während des TLS/SSL-Handshakes zwischen dem Message Processor und dem Backend-Server tritt ein Zeitlimit 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-Timeout richtig diagnostizieren. Es werden Anleitungen für Edge Private Cloud und Public Cloud 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 in der Ablaufverfolgung für die fehlgeschlagene API-Anfrage Folgendes angezeigt wird, ist wahrscheinlich ein TLS-/SSL-Handshake-Zeitüberschreitungsfehler aufgetreten. Die wahrscheinliche Ursache für den Fehler ist, dass die Firewall des Backend-Servers den 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 der Fehler nach 55 Sekunden aufgetreten ist, bedeutet dies, dass eine Zeitüberschreitung die wahrscheinliche Ursache des Problems war.
    2. Prüfen Sie, ob der Fehler messaging.adaptors.http.BadGateway enthält. Auch dieser Fehler weist in der Regel auf eine Zeitüberschreitung hin.

    3. Wenn Sie die Edge Private Cloud verwenden, notieren Sie sich den Wert des Felds X-Apigee.Message-ID in der Trace-Ausgabe, wie unten dargestellt. 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 des Felds X-Apigee.Message-ID.

Wenn Sie prüfen möchten, ob das TLS-/SSL-Handshake-Zeitlimit die Ursache für den Fehler war, folgen Sie je nach Verwendung der Public Cloud oder Private Cloud der Anleitung in den folgenden Abschnitten.

Zusätzliche Schritte zur Fehlerbehebung nur für Edge Private Cloud-Nutzer

Wenn Sie sich in Apigee Edge Private Cloud befinden, können Sie die folgenden Schritte ausführen, um die Ursache des Handshakefehlers zu ermitteln. In diesem Schritt prüfen Sie die Logdatei des Nachrichtenverarbeiters auf relevante Informationen. Wenn Sie sich in Edge Public Cloud befinden, können Sie diesen Abschnitt überspringen und mit Weitere Diagnoseschritte für Nutzer von privaten und öffentlichen Clouds 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 problemlos 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 die Verbindung zwischen dem Nachrichtenprozessor und dem Backend-Server prüfen.

  2. Prüfen Sie die Protokolldatei des Nachrichten-Prozessors auf Hinweise auf einen Handshake-Fehler. Öffnen Sie die Datei:

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

    und suchen Sie nach der eindeutigen Nachrichten-ID (dem Wert von X-Apigee.Message-ID, die Sie in der Trace-Datei gefunden haben). 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 Nachrichten-Prozessors angezeigt wird, fahren Sie mit der Fehlerbehebung fort. Rufen Sie Weitere Schritte zur Fehlerbehebung für Edge Private und Public Cloud-Nutzer auf.

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

Weitere Diagnoseschritte 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 ein Private Cloud-Nutzer sind, können Sie die TCP/IP-Pakete auf dem Back-End-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 Nutzer der Public Cloud sind, haben Sie keinen Zugriff auf den Nachrichtenprozessor. Das Erfassen der TCP/IP-Pakete auf dem Backend-Server kann jedoch helfen, ein Problem zu lokalisieren.

  3. Nachdem Sie entschieden haben, wo die TCP/IP-Pakete erfasst werden sollen, 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 die öffentliche IP-Adresse des Message Processors im tcpdump-Befehl. Hilfe zum Befehl zum Untersuchen des Back-End-Server-Traffics finden Sie unter tcpdump.

    • Wenn Sie die TCP/IP-Pakete auf dem Message Processor übernehmen, verwenden Sie die öffentliche IP-Adresse des Back-End-Servers im Befehl tcpdump. Hilfe zum Befehl zum Untersuchen des Message Processor-Traffics finden Sie unter tcpdump.

    • Wenn es mehrere IP-Adressen für den Back-End-Server/Message Processor gibt, müssen Sie eine andere Verwendung des Befehls tcpdump ausprobieren. Weitere Informationen zu diesem Tool und anderen Varianten dieses Befehls finden Sie unter tcpdump.

  4. Analysiere die TCP/IP-Pakete mit dem Wireshark-Tool oder einem ähnlichen 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 Nachrichtenprozessor sendet dann die Nachricht „Client Hello“ in Paket 4.

  7. Da keine Bestätigung vom Backend-Server erfolgt, sendet der Nachrichtenprozessor die Nachricht „Client Hello“ nach einem vordefinierten Zeitintervall mehrmals in den Paketen 5, 6 und 7 noch einmal.

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

  9. Wie in der Beispiel-Wireshark-Sitzung zu sehen, ist die Verbindung zum Backend erfolgreich (Schritt 1). Der SSL-Handshake ist jedoch abgelaufen, da der Backend-Server nie geantwortet hat.

Wenn Sie die Schritte zur Fehlerbehebung in diesem Playbook ausgeführt haben und festgestellt haben, dass eine Zeitüberschreitung den TLS/SSL-Handshake-Fehler verursacht hat, fahren Sie mit dem Abschnitt Lösung fort.

Mit API-Monitoring ein Problem identifizieren

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 SSL-Handshake-Zeitüberschreitungen aufgrund von Firewalleinschränkungen auf dem Backend-Server auf, die den Traffic von Apigee Edge blockieren. 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, dass die Einschränkungen für die IP-Adressen der Message Processors auf allen Netzwerkschichten aufgehoben werden, um einen reibungslosen Trafficfluss zwischen Apigee Edge und dem Backend-Server zu ermöglichen.

Wenn es keine Firewalleinschränkungen gibt und/oder das Problem weiterhin besteht, fahre mit Erfassen von Diagnoseinformationen erforderlich fort.

Erfassen von Diagnoseinformationen erforderlich

Wenn das Problem auch nach Befolgen der obigen Anweisungen weiterhin besteht, erfassen Sie bitte die folgenden Diagnoseinformationen. Wenden Sie sich an den Apigee Edge-Support und senden Sie ihm die folgenden Informationen:

  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. Ablaufverfolgungsdatei mit 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
    2. API-Proxy-Bundle
    3. Ablaufverfolgungsdatei mit Fehler
    4. Message Processor-Logs /opt/apigee/var/log/edge-message-processor/logs/system.log
    5. TCP/IP-Pakete, die auf dem Backend-Server oder Message Processor erfasst wurden.
  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