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

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

Symptom

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

Fehlermeldung

Die Clientanwendung erhält 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: Zeitüberschreitung beim TLS/SSL-Handshake

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

Ein TLS/SSL-Handshake umfasst mehrere Schritte. Dieser Fehler tritt in der Regel auf, wenn beim TLS/SSL-Handshake zwischen dem Message Processor und einem Backend-Server eine Zeitüberschreitung auftritt.

Diagnose

In diesem Abschnitt wird erläutert, wie Sie eine Zeitüberschreitung beim TLS/SSL-Handshake 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 erläutert, wie Sie mit dem Apigee Edge-Trace-Tool eine vorläufige Diagnose des Problems durchführen.

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

2. Wenn im Trace für die fehlgeschlagene API-Anfrage Folgendes angezeigt wird, ist wahrscheinlich ein Fehler aufgrund einer Zeitüberschreitung beim TLS/SSL-Handshake aufgetreten. Die wahrscheinliche Ursache des Fehlers ist, dass die Firewall des Backend-Servers Traffic von Apigee blockiert.

   1. Prüfen Sie, ob der Fehler 502 Bad Gateway nach 55 Sekunden auftritt. Dies ist das Standardzeitlimit, das für den Message Processor festgelegt ist. Wenn der Fehler nach 55 Sekunden auftritt, ist eine Zeitüberschreitung wahrscheinlich die Ursache des Problems.
   2. Prüfen Sie, ob der Fehler messaging.adaptors.http.BadGateway angezeigt wird. Auch dieser Fehler deutet in der Regel auf eine Zeitüberschreitung hin.

   3. Wenn Sie Edge Private Cloud verwenden, notieren Sie sich den Wert des X-Apigee.Message-ID Felds in der Trace-Ausgabe, wie unten gezeigt. Ein Private Cloud-Nutzer kann diesen ID-Wert für die weitere Fehlerbehebung verwenden, wie später erläutert.

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

         

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

Um zu bestätigen, dass eine Zeitüberschreitung beim TLS/SSL-Handshake die Ursache des Fehlers war, folgen Sie der Anleitung in den folgenden Abschnitten, je nachdem, ob Sie Public Cloud oder Private Cloud verwenden.

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

Wenn Sie 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 Message Processors auf relevante Informationen. Wenn Sie Edge Public Cloud verwenden, können Sie diesen Abschnitt überspringen und mit Weitere Schritte zur Fehlerbehebung für Nutzer von Private und Public Cloud fortfahren.

1. Prüfen Sie, ob Sie von jedem Message Processor aus mit dem Befehl telnet eine direkte Verbindung zum jeweiligen Backend-Server herstellen können:

   1. Wenn der Backend-Server in einer einzelnen IP-Adresse aufgelöst wird, verwenden Sie diesen Befehl:

      telnet BackendServer-IPaddress 443

   2. Wenn der Backend-Server in mehreren IP-Adressen aufgelöst wird, verwenden Sie den Hostnamen des Backend-Servers im Befehl „telnet“, 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 die Verbindung zwischen dem Message Processor und dem Backend-Server prüfen.

2. Prüfen Sie die Logdatei des Message Processors auf Hinweise auf einen fehlgeschlagenen Handshake. Ö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 , den Sie in der Trace-Datei gefunden haben). Prüfen Sie, ob eine Fehlermeldung zum Handshake angezeigt wird, die mit der Nachrichten-ID verknüpft ist, wie unten gezeigt:

   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 Logdatei des Message Processors angezeigt wird, führen Sie weitere Untersuchungen durch. Weitere Schritte zur Fehlerbehebung für Nutzer von Edge Private und Public Cloud

Wenn die Handshake-Meldung nicht in der Logdatei angezeigt wird, lesen Sie den Abschnitt Erfassen von Diagnoseinformationen erforderlich.

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 zu bestätigen, ob während des TLS/SSL-Handshake eine 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. Erfassen Sie sie vorzugsweise auf dem Backend-Server, da die Pakete dort entschlüsselt werden.
2. Wenn Sie ein Public Cloud-Nutzer sind, haben Sie keinen Zugriff auf den Message Processor. Das Erfassen der TCP/IP-Pakete auf dem Backend-Server kann jedoch helfen, ein Problem einzugrenzen.

3. Nachdem Sie entschieden haben, wo die TCP/IP-Pakete erfasst werden sollen, verwenden Sie den folgenden tcpdump , 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 erfassen, verwenden Sie die öffentliche IP-Adresse des Message Processors im Befehl tcpdump. Informationen zur Verwendung des Befehls zum Untersuchen des Traffics des Backend-Servers finden Sie unter tcpdump.

   • Wenn Sie die TCP/IP-Pakete auf dem Message Processor erfassen, verwenden Sie die öffentliche IP-Adresse des Backend-Servers im Befehl tcpdump. Informationen zur Verwendung des Befehls zum Untersuchen des Traffics des Message Processors finden Sie unter tcpdump.

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

4. Analysieren Sie die TCP/IP-Pakete mit dem Tool „Wireshark“ 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 Message Processor sendet dann die Nachricht „Client Hello“ in Paket 4.

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

8. Wenn der Message Processor nach drei Wiederholungen keine Bestätigung erhält, sendet er die Nachricht FIN, ACK an den Backend-Server, um anzugeben, dass er die Verbindung schließt.

9. Wie in der Beispiel-Wireshark-Sitzung gezeigt, ist die Verbindung zum Backend erfolgreich (Schritt 1). Beim SSL-Handshake ist jedoch eine Zeitüberschreitung aufgetreten, 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 die Ursache für den TLS/SSL-Handshake-Fehler war, lesen Sie den Abschnitt Auflösung.

Problem mit API Monitoring identifizieren

API Monitoring ermöglicht Ihnen, Problembereiche schnell zu isolieren, um Fehler, Leistungs- und Latenzprobleme sowie deren Quelle zu diagnostizieren, z. B. Entwickler-Apps, API-Proxys, Backend-Ziele oder die API-Plattform.

Sehen Sie sich ein Beispielszenario an in dem gezeigt wird, wie Sie mit API Monitoring 5xx-Probleme mit Ihren APIs beheben können. Sie können beispielsweise eine Benachrichtigung einrichten, die Sie benachrichtigt, wenn die Anzahl der Fehler vom Typ messaging.adaptors.http.BadGateway einen bestimmten Grenzwert überschreitet.

Auflösung

In der Regel treten Zeitüberschreitungen beim SSL-Handshake aufgrund von Firewallbeschränkungen auf dem Backend-Server auf, die den Traffic von Apigee Edge blockieren. Wenn Sie die Schritte zur Fehlerbehebung ausgeführt haben und festgestellt haben, dass die Ursache des Handshake-Fehlers eine Zeitüberschreitung ist, müssen Sie Ihr Netzwerkteam hinzuziehen, um die Ursache zu ermitteln und die Firewallbeschränkungen zu beheben.

Beachten Sie, dass die Firewallbeschränkungen auf verschiedenen Netzwerkschichten auferlegt werden können. Es ist wichtig, dass die Beschränkungen auf allen Netzwerkschichten in Bezug auf die IP-Adressen des Message Processors entfernt werden, um einen reibungslosen Traffic zwischen Apigee Edge und dem Backend-Server zu gewährleisten.

Wenn keine Firewallbeschränkungen vorhanden sind und/oder das Problem weiterhin besteht, lesen Sie den Abschnitt Erfassen von Diagnoseinformationen erforderlich.

Erfassen von Diagnoseinformationen erforderlich

Wenn das Problem auch nach dem Ausführen der obigen Anleitung weiterhin besteht, erfassen Sie die folgenden Diagnoseinformationen. Wenden Sie sich an den Apigee Edge-Support und teilen Sie ihm die Informationen mit:

1. Wenn Sie Public Cloud-Nutzer sind, geben Sie die folgenden Informationen an:
   1. Name der Organisation
   2. Umgebungsname
   3. Name des API-Proxys
   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 Private Cloud-Nutzer sind, geben Sie die folgenden Informationen an:
   1. Vollständige Fehlermeldung
   2. API-Proxy-Bundle
   3. Trace-Datei mit dem Fehler
   4. Message Processor-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 zu den Abschnitten in diesem Playbook, die Sie ausprobiert haben, und alle anderen Informationen, die uns helfen, das Problem schnell zu beheben.