Diese Seite wurde von der Cloud Translation API übersetzt.

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

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

Symptom

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

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 ausgeführt werden von
Zeitüberschreitung beim TLS/SSL-Handshake	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 beim TLS/SSL-Handshake zwischen dem Nachrichtenprozessor und einem Back-End-Server eine Zeitüberschreitung auftritt.

Diagnose

In diesem Abschnitt wird erläutert, wie Sie eine Zeitüberschreitung beim TLS/SSL-Handshake richtig diagnostizieren. Anweisungen für die Edge Private Cloud und die öffentliche Cloud sind aufgeführt.

Trace-Sitzungsausgabe untersuchen

In den folgenden Schritten wird erläutert, wie Sie mithilfe des Tools Apigee Edge Trace eine vorläufige Diagnose des Problems erstellen.

Aktivieren Sie in der Edge-Benutzeroberfläche eine Trace-Sitzung für den betroffenen API-Proxy.
Wenn der Trace für die fehlgeschlagene API-Anfrage Folgendes zeigt, ist wahrscheinlich ein Zeitüberschreitungsfehler beim TLS/SSL-Handshake aufgetreten. Der Fehler liegt wahrscheinlich daran, dass die Back-End-Server-Firewall den Traffic von Apigee blockiert.
1. Prüfen Sie, ob der Fehler 502 Bad Gateway nach 55 Sekunden auftritt. Dies ist das Standardzeitlimit, das auf dem Message Processor festgelegt wurde. Wenn der Fehler nach 55 Sekunden auftrat, bedeutet dies, dass das Problem wahrscheinlich durch eine Zeitüberschreitung verursacht wurde.
2. Ermitteln 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 sich in Edge Private Cloud befinden, notieren Sie den Wert des Felds X-Apigee.Message-ID in der Trace-Ausgabe, wie unten gezeigt. Ein Nutzer der privaten Cloud kann diesen ID-Wert für weitere Fehlerbehebungen verwenden, wie später erläutert wird.
  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.

Um zu bestätigen, dass das TLS/SSL-Handshake-Zeitlimit die Ursache des Fehlers war, folgen Sie den Schritten in den folgenden Abschnitten, je nachdem, ob Sie sich in einer öffentlichen oder einer privaten Cloud befinden.

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

Wenn Sie Apigee Edge Private Cloud verwenden, können Sie mit den folgenden Schritten die Ursache des Handshakefehlers prüfen. In diesem Schritt prüfen Sie die Protokolldatei von Message Processor auf relevante Informationen. Wenn Sie die Edge Public Cloud verwenden, können Sie diesen Abschnitt überspringen und mit Weitere Diagnoseschritte für Nutzer privater und öffentlicher Clouds fortfahren.

Prüfen Sie mit dem Befehl telnet, ob Sie von jedem der Message Processor aus eine direkte Verbindung zu dem jeweiligen Back-End-Server herstellen können:
1. Wenn der Back-End-Server in eine einzelne IP-Adresse aufgelöst wird, verwenden Sie diesen Befehl:
```
telnet BackendServer-IPaddress 443
```
2. Wenn der Back-End-Server in mehrere IP-Adressen aufgelöst wird, verwenden Sie den Hostnamen des Back-End-Servers im Telnet-Befehl wie unten dargestellt:
```
telnet BackendServer-HostName 443
```
Wenn Sie ohne Fehler eine Verbindung zum Back-End-Server herstellen können, fahren Sie mit dem nächsten Schritt fort.

Wenn der Befehl telnet fehlschlägt, müssen Sie zusammen mit Ihrem Netzwerkteam die Konnektivität zwischen dem Message Processor und dem Back-End-Server prüfen.
Suchen Sie in der Message Processor-Protokolldatei nach Hinweisen auf einen Handshakefehler. Ö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, den Sie in der Trace-Datei gefunden haben). Prüfen Sie, ob eine Handshake-Fehlermeldung in Verbindung mit der Nachrichten-ID angezeigt wird, 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 Message Processor angezeigt wird, fahren Sie mit der weiteren Untersuchung fort. Gehen Sie zu Weitere Diagnoseschritte für Nutzer von Edge Private und Public Cloud.

Wenn die Handshakemeldung in der Protokolldatei nicht angezeigt wird, lesen Sie den Abschnitt Diagnoseinformationen müssen erfasst werden.

Weitere Diagnoseschritte für Nutzer von Edge Private und Public Cloud

Zur weiteren Identifizierung des Problems können Sie mit dem Tool tcpdump TCP/IP-Pakete analysieren, um festzustellen, ob während des TLS/SSL-Handshakes eine Zeitüberschreitung aufgetreten ist.

Wenn Sie ein Private Cloud-Nutzer sind, können Sie die TCP/IP-Pakete auf dem Back-End-Server oder Message Processor erfassen. Sie sollten sie vorzugsweise auf dem Back-End-Server erfassen, da die Pakete auf dem Back-End-Server entschlüsselt werden.
Als Nutzer einer öffentlichen Cloud haben Sie keinen Zugriff auf den MessageProcessor. Es kann jedoch helfen, die TCP/IP-Pakete auf dem Back-End-Server zu erfassen, um ein Problem zu ermitteln.
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 Back-End-Server übernehmen, verwenden Sie die öffentliche IP-Adresse des Message Processor im Befehl tcpdump. Hilfe zur Verwendung des Befehls zum Untersuchen des Back-End-Server-Traffics finden Sie unter tcpdump.
- Wenn Sie die TCP/IP-Pakete auf dem Message Processor verarbeiten, verwenden Sie die öffentliche IP-Adresse des Back-End-Servers im Befehl tcpdump. Hilfe zur Verwendung des Befehls zum Untersuchen des Nachrichtenprozessor-Traffics finden Sie unter tcpdump.
- Wenn es mehrere IP-Adressen für den Back-End-Server/Message Processor gibt, müssen Sie einen anderen tcpdump-Befehl verwenden. Weitere Informationen zu diesem Tool und anderen Varianten dieses Befehls finden Sie unter tcpdump.
Analysieren Sie die TCP/IP-Pakete mit dem Wireshark-Tool oder einem ähnlichen Tool. Der folgende Screenshot zeigt TCP/IP-Pakete in Wireshark.
Die Wireshark-Ausgabe zeigt, dass der Drei-Wege-TCP-Handshake in den ersten drei Paketen erfolgreich abgeschlossen wird.
Der Message Processor sendet dann die Nachricht "Client Hello" in Paket 4.
Da es keine Bestätigung vom Back-End-Server gibt, sendet der Message Processor die „Client Hello“-Nachricht nach einer Wartezeit für ein vordefiniertes Zeitintervall mehrmals in den Paketen 5, 6 und 7 noch einmal.
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 er die Verbindung beendet.
Wie Sie in der Wireshark-Beispielsitzung gezeigt haben, ist die Verbindung zum Back-End erfolgreich (Schritt 1). Beim SSL-Handshake ist jedoch eine Zeitüberschreitung aufgetreten, da der Back-End-Server nie geantwortet hat.

Wenn Sie die Schritte zur Fehlerbehebung in diesem Playbook ausgeführt haben und festgestellt haben, dass der TLS/SSL-Handshakefehler durch eine Zeitüberschreitung verursacht wurde, 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 und deren Quelle zu diagnostizieren, z. B. Entwickleranwendungen, API-Proxys, Back-End-Ziele oder die API-Plattform.

Gehen Sie ein Beispielszenario durch, in dem gezeigt wird, wie Sie 5xx-Probleme mit Ihren APIs mithilfe von API Monitoring beheben können. Sie können beispielsweise eine Benachrichtigung einrichten, damit Sie informiert werden, wenn die Anzahl der Fehler vom Typ messaging.adaptors.http.BadGateway einen bestimmten Schwellenwert überschreitet.

Auflösung

In der Regel treten die SSL-Handshake-Zeitüberschreitungen auf Firewall-Einschränkungen auf dem Back-End-Server auf, die den Traffic von Apigee Edge blockieren. Wenn Sie die Diagnoseschritte ausgeführt haben und festgestellt haben, dass die Ursache des Handshakefehlers eine Zeitüberschreitung ist, wenden Sie sich an Ihr Netzwerkteam, um 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 auf allen Netzwerkebenen in Bezug auf die Nachrichtenprozessor-IP-Adressen entfernt werden, um einen reibungslosen Traffic-Fluss zwischen Apigee Edge und dem Back-End-Server zu gewährleisten.

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

Diagnoseinformationen müssen erfasst werden

Wenn das Problem trotz Befolgen der obigen Anweisungen weiterhin besteht, stellen Sie die folgenden Diagnoseinformationen zusammen. Kontaktieren Sie sie und geben Sie sie für den Apigee Edge-Support frei:

Wenn Sie die öffentliche Cloud nutzen, geben Sie die folgenden Informationen an:
1. Name der Organisation
2. Name der Umgebung
3. API-Proxy-Name
4. Führen Sie den curl-Befehl aus, um den Fehler zu reproduzieren
5. Trace-Datei mit dem Fehler
6. Auf dem Back-End-Server erfasste TCP/IP-Pakete
Wenn Sie die private Cloud nutzen, geben Sie die folgenden Informationen an:
1. Vollständige Fehlermeldung angezeigt
2. API-Proxy-Bundle
3. Trace-Datei mit dem Fehler
4. Meldungsverarbeiter protokolliert /opt/apigee/var/log/edge-message-processor/logs/system.log
5. TCP/IP-Pakete, die auf dem Back-End-Server oder Message Processor erfasst werden.
Details zu den Abschnitten in diesem Playbook, die du ausprobiert hast, und zu anderen Informationen, die uns helfen könnten, dieses Problem zügig zu lösen.