gateway non valido (502)

Stai visualizzando la documentazione di Apigee Edge.
Vai alla documentazione di Apigee X. informazioni

Sintomo

L'applicazione client riceve un codice di stato HTTP 502 con il messaggio "Gateway non valido" come risposta per le chiamate API.

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

Messaggi di errore

L'applicazione client riceve il seguente codice di risposta:

HTTP/1.1 502 Bad Gateway

Inoltre, potresti ricevere 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 qualcosa di simile. 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 causare 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 i MP nel pool non sono disponibili, ovvero se sono inattivi o occupati e quindi non rispondono. Utenti di Edge Private Cloud
Configurazione SSL errata tra router e MP Questo errore viene osservato 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 verrà osservato se il server di backend non funziona e invia questa risposta. Utenti Edge cloud pubblici e privati

Causa: nessun MP disponibile nel pool

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

Apigee Edge è configurato in modo tale che il traffico API in entrata (richieste) in una determinata regione/data center venga sempre instradato dai router ai processori di messaggi (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 alcuni casi, in più di una regione/data center. In ogni regione/data center devono essere configurati due o più router e processori di messaggi.

Diagnostica

  1. Determina la regione/i data center in cui le richieste API non vanno a buon fine con l'errore 502 Gateway non valido, se è presente più di una regione/data center. Puoi trovarlo identificando la regione in cui gli utenti stanno notando 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.
  2. Vedrai il seguente errore nei log degli errori NGINX (/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>"

Scenario 1: tutti i processori di messaggi non sono attivi

  1. Verifica che i processori dei messaggi nella regione o nel data center specifici siano attivi e in funzione.
  2. Se tutti i processori di messaggi non sono attivi, riavviali.

Risoluzione

Riavvia tutti i processori di messaggi utilizzando il seguente comando:

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

Scenario 2: tutti i processori di messaggi sono impegnati nell'elaborazione delle richieste in corso

Questo errore si verifica se i router rilevano che tutti i processori di messaggi in una determinata regione/data center non sono disponibili perché sono tutti impegnati nell'elaborazione delle richieste in corso.

  1. Verifica che i processori dei messaggi nella regione o nel data center specifici siano attivi e in funzione.
  2. Se tutti i processori di messaggi sono attivi e attivi, controlla se questi presentano un elevato utilizzo della CPU, quindi genera tre thread dump ogni 30 secondi utilizzando il seguente comando:
    <JAVA_HOME>/bin/jstack -l <pid> > <filename>
  3. Se uno o più processori di messaggi riscontrano un utilizzo elevato di memoria, genera un dump dell'heap utilizzando il seguente comando:
    sudo -u apigee /bin/jmap -dump:live,format=b,file=
  4. Riavvia il processore di messaggi utilizzando il comando riportato di seguito. Dovrebbe ridurre la CPU e la memoria:
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
  5. Monitora le chiamate API per verificare se il problema persiste.
  6. Contatta l'Assistenza Apigee e fornisci i log dump del thread, del dump dell'heap e del processore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log) per indagare sulla causa dell'elevato utilizzo di CPU/memoria.

Causa: configurazione SSL errata tra router e MP

Diagnostica

  1. 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	-
  2. Controlla i log degli errori NGINX (/opt/apigee/var/log/edge-router/nginx/ORG-Env._error_log). Vedrai errori come 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>"
  3. Mostra che l'handshake SSL non riesce tra il router e il processore di messaggi.
  4. Se noti attentamente il messaggio di errore nei passaggi 1 e 2, la porta # utilizzata per la comunicazione con il processore di messaggi è 8998, che è una porta non sicura ma il protocollo è SSL (https). In genere, il numero di porta sicura utilizzata è 8443. Poiché per le comunicazioni sicure viene utilizzata una porta non sicura, si verifica l'errore di handshake SSL.
  5. In genere questo può accadere se hai saltato passaggi o imposti valori errati durante la configurazione di SSL tra router e processore di messaggi. 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 SSL. In questo scenario, puoi notare che il numero di porta dei processori di messaggi rimarrà 8998 nei file di configurazione.

Risoluzione

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

Causa: errore del server di backend

Diagnostica

  1. Se l'errore si verifica ogni volta, puoi acquisire la traccia UI per le richieste non riuscite. Seleziona una richiesta non riuscita ed esplora varie fasi della traccia. Se noti che ricevi il messaggio "502 Bad Gateway" dal server di backend, è possibile che si sia verificato un errore sul server di backend.
    La traccia mostra il gateway non valido 502 proveniente dal server di backend
  2. Se il problema è intermittente e non riesci ad acquisire la traccia,
    1. Se sei un utente del cloud pubblico, puoi utilizzare Monitoraggio API e controllare i dettagli sugli errori 502.
      1. Se noti che 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 del cloud privato, puoi analizzare i log degli accessi 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 noti che il codice di errore è messaging.adaptors.http.flow.ErrorResponseCode e l'origine dell'errore è target, l'errore è causato dal server di backend.

Risoluzione

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

Raccogliere informazioni diagnostiche

  1. Log degli accessi 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).
  2. Log del processore di messaggi
    (/opt/apigee/var/log/edge-message-processor/logs/system.log).