Diese Seite wurde von der Cloud Translation API übersetzt.

502 Fehlerhaftes Gateway

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

Symptom

Die Clientanwendung erhält den HTTP-Statuscode 502 mit der Meldung "Bad Gateway" als Antwort auf API-Aufrufe.

Der HTTP-Statuscode 502 bedeutet, dass der Client keine gültige Antwort von den Back-End-Servern erhält, die die Anfrage tatsächlich ausführen sollten.

Fehlermeldungen

Die Clientanwendung ruft den folgenden Antwortcode ab:

HTTP/1.1 502 Bad Gateway

Darüber hinaus werden möglicherweise die folgenden Fehlermeldungen angezeigt:

<html>
<head>
<title>Error</title>
<style>
body {
width: 35em;
margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif;
}
</style>
</head>
<body>
<h1>An error occurred.</h1>
<p>Sorry, the page you are looking for is currently unavailable.<br/>
Please try again later.</p>
</body>
</html>

Wenn der Fehler vom Back-End-Server stammt, sehen Sie möglicherweise in etwa Folgendes. Die Fehlermeldung vom Back-End hängt vollständig von der Implementierung ab.

<html>
<head><title>502 Bad Gateway</title></head>
<body bgcolor="white">
<center><h1>502 Bad Gateway</h1></center>
</body>
</html>

Mögliche Ursachen

Im Folgenden sind einige mögliche Ursachen aufgeführt, die für APIs, die über Apigee Edge ausgeführt werden, den Fehler 502 Bad Gateway verursachen können:

Ursache	Beschreibung	Gilt für die Anleitung zur Fehlerbehebung
Keine MPs im Pool verfügbar	Dieser Fehler tritt auf, wenn alle MPs im Pool nicht verfügbar sind, das heißt, sie sind entweder offline oder beschäftigt und reagieren daher nicht.	Edge Private Cloud-Nutzer
Falsche SSL-Konfiguration zwischen Routern und MPs	Dieser Fehler tritt auf, wenn das von der Zertifizierungsstelle signierte Root-Zertifikat des Clients im Truststore des Edge-Routers fehlt.	Edge Private Cloud-Nutzer
Fehler vom Back-End-Server	Dieser Fehler tritt auf, wenn der Back-End-Server ausfällt und diese Antwort sendet.	Nutzer von Edge Public und Private Cloud

Ursache: Keine MPs im Pool verfügbar

Dieser Fehler tritt auf, wenn der Router feststellt, dass alle Nachrichtenprozessoren in einer bestimmten Region/einem bestimmten Rechenzentrum nicht verfügbar sind, z. B. wenn sie alle ausgefallen sind.

Apigee Edge ist so konfiguriert, dass der eingehende API-Traffic (Anfragen) in einer bestimmten Region/einem Rechenzentrum immer von den Routern an die Message Processor (MPs) in derselben Region/einem Rechenzentrum weitergeleitet wird. In einigen Fällen können Apigee Edge-Komponenten nur in einer Region/einem Rechenzentrum und in einigen Fällen in mehr als einer Region/einem Rechenzentrum eingerichtet sein. In jeder Region bzw. jedem Rechenzentrum sind mindestens zwei Router und Message Processor konfiguriert.

Diagnose

Ermitteln Sie die Region bzw. die Rechenzentren, in denen die API-Anfragen mit dem Fehler 502 Bad Gateway fehlschlagen, wenn mehr als eine Region bzw. ein Rechenzentrum vorhanden ist. Dazu können Sie entweder die Region ermitteln, in der die Nutzer 502-Fehler beobachten, oder die NGINX-Zugriffslogs im Verzeichnis /opt/apigee/var/log/edge-router/nginx/ für jeden Router prüfen, der zu einer anderen Region gehört.

In den NGINX-Fehlerlogs wird der folgende Fehler ausgegeben (/opt/apigee/var/log/edge-router/nginx/ORG-Env._error_log).

2019/06/24 15:26:00 [error] 4796#4796: *56357443 no live upstreams while connecting to upstream, client: <Router_IP_address>, server: <HostAlias>, request: "PUT <BasePath> HTTP/1.1", upstream: "http://<ListOfMP-IP_R-MP-Port>/<BasePath>", host: "<HostAlias>"

Szenario 1: Alle Message Processor sind ausgefallen

Prüfen Sie, ob die Message Processors in der jeweiligen Region bzw. im jeweiligen Rechenzentrum aktiv sind.
Wenn alle Message Processor ausfallen, starten Sie sie neu.

Auflösung

Starten Sie alle Message Processors mit dem folgenden Befehl neu:

/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

Szenario 2: Alle Message Processor sind mit der Verarbeitung laufender Anfragen beschäftigt

Dieser Fehler tritt auf, wenn die Router feststellen, dass alle Nachrichtenprozessoren in einer bestimmten Region/einem bestimmten Rechenzentrum nicht verfügbar sind, da sie alle mit der Verarbeitung laufender Anfragen beschäftigt sind.

Prüfen Sie, ob die Message Processors in der jeweiligen Region bzw. im jeweiligen Rechenzentrum aktiv sind.
Wenn alle Message Processor betriebsbereit und aktiv sind, prüfen Sie, ob die CPU-Auslastung bei den Message Processor(s) hoch ist. Generieren Sie dann alle 30 Sekunden mit dem folgenden Befehl drei Thread-Dumps:
```
<JAVA_HOME>/bin/jstack -l <pid> > <filename>
```
Wenn die Arbeitsspeichernutzung der Nachrichtenprozessoren hoch ist, generieren Sie mit dem folgenden Befehl einen Heap-Dump:
```
sudo -u apigee /bin/jmap -dump:live,format=b,file= 
```
Starten Sie den Message Processor mit dem folgenden Befehl neu. Es sollte die CPU und den Arbeitsspeicher reduzieren:
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```
Überwachen Sie die API-Aufrufe, um festzustellen, ob das Problem weiterhin besteht.
Wenden Sie sich an den Apigee-Support und senden Sie die Thread-Dumps, Heap-Dumps und Message Processor-Protokolle (/opt/apigee/var/log/edge-message-processor/logs/system.log), um die Ursache für die hohe CPU-/Arbeitsspeichernutzung zu untersuchen.

Ursache: Falsche SSL-Konfiguration zwischen Routern und MPs

Diagnose

Prüfen Sie die NGINX-Zugriffslogs (/opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log). Sie erhalten dann die Antwort 502 wie unten gezeigt:

    2019-07-23T12:13:42+03:00	sc-10-254-226-23	10.X.X.X:53634	10.X.X.X:8998	0.000	-	-	502	502	189	344	GET <path> curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh2/1.4.2	<host alias>	mp-10-254-226-23-23706-8552529-1	10.129.107.101	-	-	-1	-	-	dc-2	gateway-2	green	-	gateway-2	dc-2	op	pilot	http	-

Prüfen Sie die NGINX-Fehlerlogs (/opt/apigee/var/log/edge-router/nginx/ORG-Env._error_log). Sie sehen Fehler wie diesen:

	2019/07/30 17:02:24 [error] 7691#7691: *11753633 peer closed connection in SSL handshake while SSL handshaking to upstream, client: X.X.X.X, server: <HostAlias>, request: "GET /no-target HTTP/1.1", upstream: "https://X.X.X.X:8998/no-target", host: "<HostAlias>"

Dies zeigt, dass der SSL-Handshake zwischen Router und Message Processor fehlschlägt.
Wenn Sie in der Fehlermeldung in Schritt 1 und 2 genau feststellen, dass die für die Kommunikation mit dem Nachrichtenprozessor verwendete Portnummer 8998 ist, ist 8998 ein nicht sicherer Port, das Protokoll ist jedoch SSL (https). In der Regel ist die verwendete sichere Portnummer 8443. Da für die sichere Kommunikation ein nicht sicherer Port verwendet wird, schlägt der SSL-Handshake fehl.
Dies kann in der Regel passieren, wenn Sie bei der Konfiguration von SSL zwischen Router und Message Processor Fehler ausgelassen oder falsche Werte festgelegt haben. Gehen Sie dazu wie hier beschrieben vor.
Dieser Fehler kann beispielsweise auftreten, wenn
1. Die Portnummer ist in /opt/apigee/customer/application/message-processor.properties as shown below als 8998 statt 8443 angegeben.
```
        conf/message-processor-communication.properties+local.http.port=8998
```
2. Die Router-Konfigurationsdateien im Verzeichnis /opt/nginx/conf.d/* werden nicht gelöscht und der Router wurde während der SSL-Konfiguration nicht neu gestartet. In diesem Szenario sehen Sie, dass die Portnummer der Message Processor 8998 in den Konfigurationsdateien beibehalten wird.

Auflösung

Stellen Sie sicher, dass alle Schritte unter TLS zwischen einem Router und einem Nachrichtenprozessor konfigurieren korrekt ausgeführt wurden.
Wenn das Problem weiterhin besteht, lesen Sie den Abschnitt Diagnoseinformationen erfassen.

Ursache: Fehler vom Back-End-Server

Diagnose

Wenn der Fehler jedes Mal auftritt, können Sie das UI-Trace für die fehlgeschlagenen Anfragen erfassen. Wählen Sie eine fehlgeschlagene Anfrage aus und durchlaufen Sie die verschiedenen Phasen im Trace. Wenn Sie feststellen, dass Sie die Meldung „502 Bad Gateway“ vom Back-End-Server selbst erhalten, könnte das Problem auf den Back-End-Server zurückzuführen sein.
Trace zu „502 Ungültiges Gateway“ vom Back-End-Server
Wenn das Problem zeitweise auftritt und Sie den Trace nicht erfassen können,
1. Nutzer von Public Clouds können das API-Monitoring verwenden und sich die Details zu den 502-Fehlern ansehen.
  1. Wenn Sie feststellen, dass der Fehlercode messaging.adaptors.http.flow.ErrorResponseCode und die Fehlerquelle target ist, wird der Fehler durch den Back-End-Server verursacht.
2. Als Private Cloud-Nutzer können Sie die NGINX-Zugriffslogs analysieren.
  /opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log.
  Der Eintrag für die fehlgeschlagene Anfrage wird so angezeigt:
```
2017-02-24T14:42:12+00:00	rt-01	192.8.155.2:18118	192.168.84.166:8998	10.225	-	-	502	502	440	0	GET /adv-eadlg-test/documents?type=doctype HTTP/1.1	rt-02efawae234-1234	Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36	myorg-dev.apigee.net	 rt-02efawae234-1234	6	-	false	target	messaging.adaptors.http.flow.ErrorResponseCode	null/null	-	/organizations/myorg/environments/dev/apiproxies/api123
```
  1. Wenn Sie feststellen, dass der Fehlercode messaging.adaptors.http.flow.ErrorResponseCode und die Fehlerquelle target ist, wird der Fehler durch den Back-End-Server verursacht.

Auflösung

Arbeiten Sie mit Ihrem Back-End-Serverteam zusammen, um dieses Problem im Back-End zu beheben.

Diagnosedaten erfassen

NGINX-Zugriffslogs
(/opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log)
und Fehlerlogs
(/opt/apigee/var/log/edge-router/nginx/ORG-Env._error_log).
Message Processor-Logs
(/opt/apigee/var/log/edge-message-processor/logs/system.log).