gateway non valido (502)

Stai visualizzando la documentazione di Apigee Edge.
Vai alla sezione Documentazione di Apigee X. Informazioni

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 dall' di backend che devono effettivamente soddisfare la richiesta.

Messaggi di errore

L'applicazione client riceve il seguente codice di risposta:

HTTP/1.1 502 Bad Gateway

Potresti anche 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 vedere 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

Ecco alcune possibili cause che possono portare all'errore 502 Bad Gateway per le API che passano attraverso Apigee Edge:

Causa Descrizione Istruzioni per la risoluzione dei problemi applicabili per
Nessun MP disponibile nel pool Questo errore si osserva 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 di attendibilità del router di Edge. Utenti di Edge Private Cloud
Errore del server di backend Questo errore viene osservato se il server di backend ha un errore e invia questa risposta. Utenti di Edge Cloud pubblico e privato

Causa: nessun MP disponibile nel pool

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

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 o nello stesso data center. In alcuni casi, i componenti Apigee Edge possono essere configurati in una sola regione/data center e in alcuni casi in più regioni/data center. In ogni regione/data center saranno configurati due o più router e processori di messaggi.

Diagnosi

  1. Determina le regioni/i data center in cui le richieste API non vanno a buon fine con l'errore 502 Gateway non valido, se sono presenti più regioni/data center. Puoi trovarlo identificando la regione in cui gli utenti osservano gli 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. Visualizzerai 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 sono inattivi

  1. Verifica che i processori di messaggi nella regione o nel data center specifici siano attivi e in esecuzione.
  2. Se tutti i processori di messaggi sono inattivi, 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 occupati a elaborare le richieste in corso

Questo errore si verifica se i router rilevano che tutti i processori di messaggi in una determinata regione/centro dati non sono disponibili perché sono tutti occupati a elaborare le richieste in corso.

  1. Verifica che i processori di messaggi nella regione o nel data center specifici siano attivi e in esecuzione.
  2. Se tutti i processori di messaggi sono attivi, controlla se i processori di messaggi stanno riscontrando un elevato utilizzo della CPU, quindi genera tre dump di thread ogni 30 secondi utilizzando il seguente comando:
    <JAVA_HOME>/bin/jstack -l <pid> > <filename>
  3. Se la memoria utilizzata dai processori di messaggi è elevata, genera un dump dell'heap con il seguente comando:
    sudo -u apigee /bin/jmap -dump:live,format=b,file=
  4. Riavvia il processore di messaggi utilizzando il comando seguente. 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, heap e del processore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log) per cercare di capire meglio la causa dell'utilizzo elevato di CPU/memoria.

Causa: configurazione SSL errata tra router e MP

Diagnosi

  1. Controlla i log di accesso NGINX (/opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log). Verrà visualizzata 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). Visualizzerai 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 con attenzione nel messaggio di errore ai passaggi #1 e #2, la porta # utilizzata 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 le comunicazioni sicure viene utilizzata una porta non sicura, si verifica l'errore dell'handshake SSL.
  5. In genere questo può accadere se non hai eseguito alcuni passaggi o hai impostato valori errati durante la configurazione del protocollo SSL tra router e processore di messaggi. Fai riferimento alla procedura descritta 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 di seguire correttamente tutti i passaggi indicati in Configurare TLS tra un router e un processore di messaggi.
  2. Se il problema persiste, vai a Raccogliere informazioni diagnostiche.

Causa: errore del server di backend

Diagnosi

  1. Se l'errore si verifica ogni volta, puoi acquisire la traccia dell'interfaccia utente per le richieste non riuscite. Seleziona una richiesta non riuscita ed esplora le varie fasi della traccia. Se noti che ricevi il messaggio "502 gateway non valido" dallo stesso server di backend, il problema potrebbe essere dovuto al fatto che sul server di backend potrebbe essersi verificato un errore.
    Traccia che mostra 502 gateway non valido 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 il monitoraggio delle API 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 del cloud privato, potresti analizzare i log di accesso NGINX
      /opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log.
      La voce relativa alla richiesta non riuscita verrà visualizzata 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

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

Raccogliere informazioni diagnostiche

  1. Log di accesso NGINX
    (/opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log)
    e i 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).