Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

gateway non valido (502)

Stai visualizzando la documentazione di Apigee Edge.
Consulta la documentazione di Apigee X. info

Sintomo

L'applicazione client riceve un codice di stato HTTP 502 con il messaggio "Bad Gateway" come risposta alle chiamate API.

Il codice di stato HTTP 502 indica che il client non riceve una risposta valida dai server di backend che dovrebbero soddisfare la richiesta.

Messaggi di errore

L'applicazione client riceve il seguente codice di risposta:

HTTP/1.1 502 Bad Gateway

Inoltre, potresti visualizzare i seguenti messaggi di errore:

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

Se l'errore proviene dal server di backend, potresti visualizzare un messaggio simile al seguente. Il messaggio di errore del backend dipende completamente dalla sua implementazione.

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

Possibili cause

Di seguito sono riportate alcune possibili cause che possono generare l'errore 502 Bad Gateway per le API che passano attraverso Apigee Edge:

Causa	Descrizione	Istruzioni per la risoluzione dei problemi applicabili a
Nessun MP disponibile nel pool	Questo errore si verifica se tutti gli MP del pool non sono disponibili, ovvero sono inattivi o occupati e quindi non rispondono.	Utenti di Edge Private Cloud
Configurazione SSL errata tra router e MP	Questo errore si verifica se il certificato radice firmato dalla CA del client non è presente nell'archivio attendibilità del router di Edge.	Utenti di Edge Private Cloud
Errore del server di backend	Questo errore si verifica se il server di backend non funziona e invia questa risposta.	Utenti di Edge Public Cloud e Private Cloud

Causa: nessun MP disponibile nel pool

Questo errore si verifica se il router rileva che tutti i Message Processor in una determinata regione/data center non sono disponibili (ad esempio, se sono tutti inattivi).

Apigee Edge è configurato in modo che il traffico API in entrata (richieste) in una determinata regione/data center venga sempre instradato dai router ai Message Processor (MP) nella stessa regione/data center. In alcuni casi, i componenti di Apigee Edge possono essere configurati in una sola regione/data center e, in altri casi, in più regioni/data center. In ogni regione/data center saranno configurati due o più router e Message Processor.

Diagnosi

Se sono presenti più regioni/data center, determina la regione/il data center in cui le richieste API non vanno a buon fine con l'errore 502 Bad Gateway. Puoi trovare questa informazione identificando la regione in cui gli utenti riscontrano errori 502 o controllando i log di accesso NGINX nella directory /opt/apigee/var/log/edge-router/nginx/ su ciascuno dei router appartenenti a regioni diverse.

Nei log degli errori NGINX (/opt/apigee/var/log/edge-router/nginx/ORG-Env._error_log)
viene visualizzato il seguente errore:

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

Scenario 1: tutti i Message Processor sono inattivi

Verifica se i Message Processor nella regione/nel data center specifici sono attivi e in esecuzione.
Se tutti i Message Processor sono inattivi, riavviali.

Risoluzione

Riavvia tutti i Message Processor utilizzando il seguente comando:

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

Scenario 2: tutti i Message Processor sono occupati a elaborare le richieste in corso

Questo errore si verifica se i router rilevano che tutti i Message Processor in una determinata regione/data center non sono disponibili perché sono tutti occupati a elaborare le richieste in corso.

Verifica se i Message Processor nella regione/nel data center specifici sono attivi e in esecuzione.
Se tutti i processori di messaggi sono attivi, controlla se i processori di messaggi hanno un utilizzo elevato della CPU, quindi genera tre dump dei thread ogni 30 secondi utilizzando il seguente comando:
```
<JAVA_HOME>/bin/jstack -l <pid> > <filename>
```
Se i Message Processor hanno un utilizzo elevato della memoria, genera un dump dell'heap utilizzando il seguente comando:
```
sudo -u apigee /bin/jmap -dump:live,format=b,file= 
```
Riavvia il processore di messaggi utilizzando il comando riportato di seguito. Dovrebbe ridurre l'utilizzo di CPU e memoria:
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```
Monitora le chiamate API per verificare se il problema persiste.
Contatta l'assistenza Apigee e fornisci i dump dei thread, il dump dell'heap e i log dei processori di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log) per aiutarci a capire la causa dell'utilizzo elevato di CPU/memoria utilizzata.

Causa: configurazione SSL errata tra router e MP

Diagnosi

Controlla i log di accesso NGINX (/opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log). Vedrai la risposta 502 come mostrato di seguito:

    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	-

Controlla i log degli errori NGINX (/opt/apigee/var/log/edge-router/nginx/ORG-Env._error_log). Verranno visualizzati errori simili a questo:

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

Questo mostra che l'handshake SSL non riesce tra il router e il processore di messaggi.
Se osservi attentamente il messaggio di errore nei passaggi 1 e 2, il numero di porta utilizzato per comunicare con il processore di messaggi è 8998, che è una porta non sicura, ma il protocollo è SSL (https). In genere, il numero di porta sicura utilizzato è 8443. Poiché per la comunicazione sicura viene utilizzata una porta non sicura, l'handshake SSL non riesce.
In genere, questo può accadere se hai saltato alcuni passaggi o hai impostato valori errati durante la configurazione di SSL tra il router e il Message Processor. Fai riferimento ai passaggi descritti qui.
Ad esempio, questo errore può verificarsi se
1. Il numero di porta è specificato come 8998 anziché 8443 in /opt/apigee/customer/application/message-processor.properties as shown below
```
        conf/message-processor-communication.properties+local.http.port=8998
```
2. I file di configurazione del router nella directory /opt/nginx/conf.d/* non vengono eliminati e il router non è stato riavviato durante la configurazione di SSL. In questo scenario, puoi notare che il numero di porta dei Message Processor rimarrà 8998 nei file di configurazione.

Risoluzione

Assicurati che tutti i passaggi forniti in Configurare TLS tra un router e un processore di messaggi siano seguiti correttamente.
Se il problema persiste, vai a Raccogliere informazioni di diagnostica.

Causa: errore del server di backend

Diagnosi

Se l'errore si verifica ogni volta, puoi acquisire la traccia dell'interfaccia utente per le richieste non riuscite. Seleziona una richiesta non riuscita e scorri le varie fasi della traccia. Se noti che ricevi "502 Bad Gateway" dal server di backend stesso, il problema potrebbe essere dovuto a un errore sul server di backend.
Traccia che mostra 502 Bad Gateway proveniente dal server di backend
Se il problema è intermittente e non riesci ad acquisire la traccia,
1. Se sei un utente di Public Cloud, puoi utilizzare API Monitoring e controllare i dettagli degli errori 502.
  1. Se il codice di errore è messaging.adaptors.http.flow.ErrorResponseCode e l'origine dell'errore è target, l'errore è causato dal server di backend.
2. Se sei un utente di Private Cloud, puoi analizzare i log di accesso NGINX
  /opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log.
  Vedrai la voce relativa alla richiesta non riuscita come segue:
```
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. Se il codice di errore è messaging.adaptors.http.flow.ErrorResponseCode e l'origine dell'errore è target, l'errore è causato dal server di backend.

Risoluzione

Collabora con il team del server di backend per risolvere il problema nel backend.

Raccogliere informazioni di diagnostica

Log di accesso NGINX
(/opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log)
e log degli errori
(/opt/apigee/var/log/edge-router/nginx/ORG-Env._error_log).
Log dei Message Processor
(/opt/apigee/var/log/edge-message-processor/logs/system.log).