Diese Seite wurde von der Cloud Translation API übersetzt.

502 Fehlerhaftes Gateway

<ph type="x-smartling-placeholder"></ph> Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie zur Apigee X-Dokumentation. Weitere Informationen

Symptom

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

Der HTTP-Statuscode 502 bedeutet, dass der Client keine gültige Antwort vom die die Anfrage erfüllen sollen.

Fehlermeldungen

Die Clientanwendung ruft den folgenden Antwortcode ab:

HTTP/1.1 502 Bad Gateway

Außerdem 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, wird in etwa Folgendes angezeigt. Die Fehlermeldung vom Back-End hängt ganz 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 zum Fehler 502 Bad Gateway für APIs führen können, die über Apigee Edge laufen:

Ursache	Beschreibung	Geltende Anleitung zur Fehlerbehebung
Keine Abgeordneten im Pool verfügbar	Dieser Fehler wird beobachtet, wenn alle MPs im Pool nicht verfügbar sind, d. h., sie sind entweder ausgefallen oder ausgelastet und reagieren daher nicht.	Edge Private Cloud-Nutzer
Falsche SSL-Konfiguration zwischen Routern und MPs	Dieser Fehler tritt auf, wenn das von der Zertifizierungsstelle (CA) signierte Root-Zertifikat des Clients im Truststore des Edge-Routers fehlt.	Edge Private Cloud-Nutzer
Fehler vom Backend-Server	Dieser Fehler wird beobachtet, wenn der Back-End-Server ausfällt und diese Antwort sendet.	Edge-Nutzer von öffentlichen und privaten Clouds

Ursache: Im Pool sind keine Abgeordneten verfügbar

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

Apigee Edge ist so konfiguriert, dass der eingehende API-Traffic (Anfragen) in einer bestimmten Region bzw. einem bestimmten Rechenzentrum immer von den Routern an die Message Processors (MPs) in derselben Region bzw. demselben Rechenzentrum weitergeleitet wird. In einigen Fällen können Apigee Edge-Komponenten nur in einer Region oder einem Rechenzentrum eingerichtet sein, in manchen Fällen aber auch in mehreren Regionen oder Rechenzentren. 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 es mehrere Regionen oder Rechenzentren gibt. Dazu können Sie entweder die Region identifizieren, in der die Nutzer 502-Fehler beobachten, oder die NGINX-Zugriffslogs im Verzeichnis /opt/apigee/var/log/edge-router/nginx/ auf jedem Router prüfen, der zu verschiedenen Regionen gehört.

In den NGINX-Fehlerlogs wird der folgende Fehler angezeigt (/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 in Betrieb sind.
Wenn alle Message Processors ausgefallen sind, starten Sie sie neu.

Auflösung

Starten Sie mit dem folgenden Befehl alle Message Processors 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 Message Processor 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 in Betrieb sind.
Wenn alle Message Processor aktiv und aktiv sind, prüfen Sie, ob die CPU-Auslastung des Message Processor hoch ist. Generieren Sie dann alle 30 Sekunden mit dem folgenden Befehl drei Thread-Dumps:
```
<JAVA_HOME>/bin/jstack -l <pid> > <filename>
```
Wenn der/die Message Processor eine hohe Arbeitsspeicherauslastung hat, 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. Dadurch sollten CPU und Arbeitsspeicher heruntergefahren werden:
```
/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 uns die Thread-Dumps, den Heap-Dump und die Message Processor-Logs (/opt/apigee/var/log/edge-message-processor/logs/system.log), um die Ursache für die hohe CPU-/Arbeitsspeichernutzung zu ermitteln.

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 die Antwort „502“, wie unten dargestellt:

    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 erhalten Fehlermeldungen wie diese:

	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 dem Router und dem Message Processor fehlschlägt.
Wenn Sie in der Fehlermeldung in Schritt 1 und 2 sorgfältig feststellen, ist die Portnummer 8998, die für die Kommunikation mit dem Message Processor verwendet wird, 8998. Das ist ein nicht sicherer Port, aber das Protokoll ist SSL (https). In der Regel wird die sichere Portnummer 8443 verwendet. Da für die sichere Kommunikation ein nicht sicherer Port verwendet wird, schlägt der SSL-Handshake fehl.
Dies kann normalerweise passieren, wenn Sie bei der Konfiguration von SSL zwischen Router und Message Processor Schritte ausgelassen haben oder falsche Werte festgelegt haben. Eine Anleitung dazu finden Sie hier.
Dieser Fehler kann beispielsweise auftreten, wenn
<ph type="x-smartling-placeholder">
1. Die Portnummer wird in /opt/apigee/customer/application/message-processor.properties as shown below
  als 8998 anstelle von 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 Processors in den Konfigurationsdateien 8998 bleibt.

Auflösung

Stellen Sie sicher, dass alle unter TLS zwischen einem Router und einem Message Processor konfigurieren angegebenen Schritte korrekt ausgeführt werden.
Wenn das Problem weiterhin besteht, gehen Sie zu Diagnoseinformationen erfassen.

Ursache: Fehler vom Backend-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 gehen Sie durch die verschiedenen Phasen im Trace. Wenn Sie feststellen, dass Sie die Meldung „502 Bad Gateway“ vom Backend-Server selbst erhalten, könnte das Problem daran liegen, dass auf dem Backend-Server ein Fehler aufgetreten ist.
Trace zu 502 „Bad Gateway“, das vom Backend-Server kommt
Wenn das Problem zeitweise auftritt und Sie den Trace nicht erfassen können,
<ph type="x-smartling-placeholder">
1. Wenn Sie eine öffentliche Cloud nutzen, können Sie API-Monitoring verwenden und die Details zu den 502-Fehlern überprüfen.
  1. Wenn Sie feststellen, dass der Fehlercode messaging.adaptors.http.flow.ErrorResponseCode und die Fehlerquelle target ist, wird der Fehler vom Back-End-Server verursacht.
2. Wenn Sie ein Nutzer der Private Cloud sind, 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
```
  <ph type="x-smartling-placeholder">
  1. Wenn Sie feststellen, dass der Fehlercode messaging.adaptors.http.flow.ErrorResponseCode und die Fehlerquelle target ist, wird der Fehler vom Back-End-Server verursacht.

Auflösung

Arbeiten Sie mit Ihrem Backend-Server-Team zusammen, um dieses Problem im Backend zu beheben.

Diagnoseinformationen einholen

NGINX-Zugriffsprotokolle
(/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)