502 Fehlerhaftes Gateway

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

Symptom

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

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

Fehlermeldungen

Die Clientanwendung erhält den folgenden Antwortcode:

HTTP/1.1 502 Bad Gateway

Außerdem können die folgenden Fehlermeldungen angezeigt werden:

<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 Backend-Server stammt, sehen Sie möglicherweise Folgendes. Die Fehlermeldung vom Backend 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

Hier sind einige mögliche Ursachen für den Fehler 502 (Fehlerhaftes Gateway) bei APIs, die über Apigee Edge laufen:

Ursache: Keine Message Processors im Pool verfügbar

Dieser Fehler tritt auf, wenn der Router feststellt, dass alle Message Processors 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 bestimmten Rechenzentrum immer von den Routern zu den Message Processors in derselben Region/demselben Rechenzentrum weitergeleitet wird. In einigen Fällen werden Apigee Edge-Komponenten nur in einer Region/einem Rechenzentrum eingerichtet, in anderen Fällen in mehreren Regionen/Rechenzentren. In jeder Region/jedem Rechenzentrum werden zwei oder mehr Router und Message Processors konfiguriert.

Diagnose

1. Bestimmen Sie die Region(en)/das Rechenzentrum (die Rechenzentren), in denen die API-Anfragen mit dem Fehler 502 (Fehlerhaftes Gateway) fehlschlagen, wenn es mehr als eine Region/ein Rechenzentrum gibt. Sie können dies entweder ermitteln, indem Sie die Region identifizieren, in der die Nutzer 502-Fehler beobachten, oder indem Sie die NGINX-Zugriffsprotokolle im Verzeichnis /opt/apigee/var/log/edge-router/nginx/ auf jedem der Router überprüfen, die zu verschiedenen Regionen gehören.
2. In den NGINX-Fehlerprotokollen (/opt/apigee/var/log/edge-router/nginx/ORG-Env._error_log)
   wird der folgende Fehler angezeigt:

   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 Processors sind ausgefallen

1. Prüfen Sie, ob die Message Processors in der jeweiligen Region/im jeweiligen Rechenzentrum ausgeführt werden.
2. Wenn alle Message Processors ausgefallen sind, 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 Processors sind mit der Verarbeitung laufender Anfragen beschäftigt

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

1. Prüfen Sie, ob die Message Processors in der jeweiligen Region/im jeweiligen Rechenzentrum ausgeführt werden.
2. Wenn alle Message Processors ausgeführt werden und aktiv sind, prüfen Sie, ob die CPU-Auslastung der Message Processors hoch ist. Generieren Sie dann alle 30 Sekunden drei Thread-Dumps mit dem folgenden Befehl:
   

   <JAVA_HOME>/bin/jstack -l <pid> > <filename>

3. Wenn die Arbeitsspeichernutzung der Message Processor hoch ist, generieren Sie mit dem folgenden Befehl einen Heap-Dump:
   

   sudo -u apigee /bin/jmap -dump:live,format=b,file= 

4. Starten Sie den Message Processor mit dem folgenden Befehl neu. Dadurch sollte die CPU- und Speicherauslastung sinken:
   

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

5. Beobachten Sie die API-Aufrufe, um zu prüfen, ob das Problem weiterhin besteht.
6. Wenden Sie sich an den Apigee-Support und senden Sie 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-/Speicherauslastung zu untersuchen.

Ursache: Falsche SSL-Konfiguration zwischen Routern und Message Processors

Diagnose

1. Prüfen Sie die NGINX-Zugriffsprotokolle (/opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log). Die Antwort 502 wird wie unten dargestellt angezeigt:
   

       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	-

2. Prüfen Sie die NGINX-Fehlerprotokolle (/opt/apigee/var/log/edge-router/nginx/ORG-Env._error_log). Es werden Fehler wie die folgenden angezeigt:
   

   	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>"

3. Dies zeigt, dass der SSL-Handshake zwischen Router und Message Processor fehlschlägt.
4. Wenn Sie die Fehlermeldung in Schritt 1 und 2 genau betrachten, sehen Sie, dass der Port 8998 für die Kommunikation mit dem Message Processor verwendet wird. Dies ist ein nicht sicherer Port, aber das Protokoll ist SSL (https). Normalerweise wird der sichere Port 8443 verwendet. Da ein nicht sicherer Port für die sichere Kommunikation verwendet wird, schlägt der SSL-Handshake fehl.
5. Dies kann in der Regel passieren, wenn Sie bei der Konfiguration von SSL zwischen Router und Message Processor Schritte ausgelassen oder falsche Werte festgelegt haben. Beachten Sie die hier beschriebenen Schritte.
   Dieser Fehler kann beispielsweise auftreten, wenn
   
   1. der Port in /opt/apigee/customer/application/message-processor.properties as shown below
      als 8998 anstelle von 8443 angegeben ist

              conf/message-processor-communication.properties+local.http.port=8998

   2. die Router-Konfigurationsdateien im Verzeichnis /opt/nginx/conf.d/* nicht gelöscht wurden und der Router bei der SSL-Konfiguration nicht neu gestartet wurde. In diesem Fall bleibt der Port der Message Processors in den Konfigurationsdateien 8998.

Auflösung

1. Achten Sie darauf, dass alle Schritte unter TLS zwischen einem Router und einem Message Processor konfigurieren richtig ausgeführt werden.
2. Wenn das Problem weiterhin besteht, lesen Sie den Abschnitt Diagnoseinformationen erfassen.

Ursache: Fehler vom Backend-Server

Diagnose

1. Wenn der Fehler jedes Mal auftritt, können Sie die UI-Ablaufverfolgung für die fehlerhaften Anfragen erfassen. Wählen Sie eine fehlerhafte Anfrage aus und navigieren Sie durch die verschiedenen Phasen in der Ablaufverfolgung. Wenn Sie feststellen, dass Sie die Meldung „502 Fehlerhaftes Gateway“ vom Backend-Server selbst erhalten, kann das Problem daran liegen, dass auf dem Backend-Server ein Fehler aufgetreten ist.
   Ablaufverfolgung mit der Meldung „502 Fehlerhaftes Gateway“ vom Backend-Server
   
2. Wenn das Problem nur zeitweise auftritt und Sie die Ablaufverfolgung nicht erfassen können,
   
   1. können Sie als Public Cloud-Nutzer die API-Überwachung verwenden und die Details zu den 502-Fehlern prüfen.
      
      1. Wenn der Fehlercode messaging.adaptors.http.flow.ErrorResponseCode und die Fehlerquelle target ist, wird der Fehler vom Backend-Server verursacht.
   2. Als Private Cloud-Nutzer können Sie die NGINX-Zugriffsprotokolle analysieren:
      /opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log.
      Der Eintrag für die fehlerhafte Anfrage sieht so aus:
      

      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 der Fehlercode messaging.adaptors.http.flow.ErrorResponseCode und die Fehlerquelle target ist, wird der Fehler vom Backend-Server verursacht.

Auflösung

1. Arbeiten Sie mit Ihrem Backend-Serverteam zusammen, um dieses Problem im Backend zu beheben.

Diagnoseinformationen erfassen

1. NGINX-Zugriffsprotokolle
   (/opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log)
   und Fehlerprotokolle
   (/opt/apigee/var/log/edge-router/nginx/ORG-Env._error_log).
2. Message Processor-Protokolle
   (/opt/apigee/var/log/edge-message-processor/logs/system.log).