502 Bad Gateway - Presa di corrente

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 Bad Gateway con codice ECONNRESET come risposta alle chiamate API in Edge Microgateway.

Messaggio di errore

Il client vedrà il seguente codice di risposta:

HTTP/1.1 502 Bad Gateway

La risposta includerà il seguente messaggio di errore:

{"message":"socket hang up","code":"ECONNRESET"}

Possibili cause

Causa	Descrizione	Le istruzioni di risoluzione dei problemi applicabili a
Timeout keep-alive configurato in modo errato	Timeout keep-alive configurati in modo errato tra Edge Microgateway e il server di destinazione.	Utenti perimetrali di cloud pubblici e privati
Il server di destinazione chiude prematuramente la connessione	Il server di destinazione chiude prematuramente la connessione durante l'invio di Edge Microgateway il payload della richiesta.	Utenti perimetrali di cloud pubblici e privati

Passaggi diagnostici comuni

1. Controlla i log di Edge Microgateway:

   /var/tmp/edgemicro-`hostname`-*.log
   

2. Cerca se ci sono errori 502 con il codice ECONNRESET durante un periodo di tempo specifico (se il problema si è verificato in passato) o se sono presenti richieste non funziona ancora con 502.

   2021-06-23T03:52:24.110Z [error][0:8000][3][myorg][test]
   [emg_badtarget/flakey/hangup][][][6b089a00-d3d6-11eb-95aa-911f1ee6c684]
   [microgateway-core][][GET][502][socket hang up][ECONNRESET][]
   

3. Se il livello di logging è impostato su warn o info, essere un messaggio [warn] che includa il nome host del server di destinazione e la porta nel secondo . In questo esempio è X.X.X.X:8080 e può essere usato in un secondo momento per acquisire un tcpdump.

   2021-06-23T03:52:24.109Z
   [warn][X.X.X.X:8080][3][myorg][test][emg_badtarget/flakey/hangup]
   [][][6b089a00-d3d6-11eb-95aa-911f1ee6c684][plugins-middleware]
   [targetRequest error][GET][][socket hang up][ECONNRESET][395]
   

4. Il codice di errore [socket hang up][ECONNRESET] indica che il server di destinazione ha chiuso la connessione con Edge Microgateway. Puoi eseguire ricerche nei log per determinare con quale frequenza si verifica.

Causa: timeout keep-alive configurato in modo errato

Diagnosi

1. Segui la procedura descritta in Passaggi comuni di diagnostica e verifica se hai ricevuto il Errore [socket hang up][ECONNRESET].

2. In caso affermativo, esegui ulteriori accertamenti con l'aiuto di tcpdump come spiegato di seguito:

Utilizzo di tcpdump

1. Acquisisci un valore tcpdump tra Edge Microgateway e il server di backend su il sistema operativo host Edge Microgateway con il seguente comando:

   tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
   

2. Analizza il tcpdump acquisito:

   Esempio di output tcpdump: ( visualizza immagine ingrandita)

   

   Nell'esempio tcpdump riportato sopra, puoi vedere quanto segue:

   1. Nel pacchetto 250288, il client invia una richiesta POST.
   2. Nel pacchetto 250371, il server risponde con 200 OK.
   3. Nel pacchetto 250559, il client invia una richiesta ACK.
   4. Nel pacchetto 250560, il server invia Continuation .
   5. Nel pacchetto 250561, il client invia una richiesta ACK.
   6. Nel pacchetto 262436, il server invia un FIN, ACK al il client che avvia la chiusura della connessione. Sono circa cinque secondi dopo il pacchetto precedente (250561).
   7. Nel pacchetto 262441, il client invia un altro POST richiesta. Tuttavia, l'operazione non riesce perché il server ha già avviato la chiusura del connessione. Risponde con un RST nel pacchetto 262441.

   La stessa connessione è stata riutilizzata almeno una volta in questo esempio, ma in l'ultima richiesta, il server avvia una chiusura della connessione dopo cinque secondi di tempo di inattività, che si verifica nello stesso momento in cui il client ha inviato una nuova richiesta. Questo suggerisce che il timeout keep-alive del server di backend è probabilmente più breve o uguale al il valore impostato nel client. Per verificarlo, consulta Confronta il timeout keep-alive su Edge Microgateway e sul server di backend.

Confrontare i timeout keep-alive

1. Edge Microgateway non ha una proprietà di timeout keep-alive specifica. È determinato dal sistema operativo in cui è in esecuzione. Esempi comuni sono Windows, Container Linux e Docker.
2. È possibile che questa opzione sia stata personalizzata nel sistema operativo. Verifica con il tuo amministratore di sistema. Per impostazione predefinita, i sistemi operativi Linux hanno un'impostazione keep-alive predefinita di due ore.
3. Quindi, controlla la proprietà di timeout keep-alive configurata sul tuo server di backend. Iniziamo supponiamo che il tuo server di backend sia configurato con un valore di 10 secondi.
4. Se determini che il valore del timeout keep-alive sul sistema operativo è superiore al valore della proprietà di timeout keep-alive sul server di backend come dell'esempio riportato sopra, questa è la causa degli errori di 502.

Risoluzione

Assicurati che la proprietà di timeout keep-alive sia sempre più bassa nel sistema operativo in cui Edge Il Microgateway è in esecuzione rispetto a quello sul server di backend.

1. Determina il valore impostato per il timeout keep-alive sul server di backend.
2. Configura un valore appropriato per la proprietà di timeout keep-alive nel di sistema, in modo che la proprietà di timeout keep-alive sia inferiore al valore impostato nel backend utilizzando i passaggi applicabili al tuo sistema operativo.

Best practice

È vivamente consigliato che i componenti downstream abbiano sempre un timeout keep-alive minore soglia minima rispetto a quella configurata sui server upstream per evitare questo tipo di condizioni di gara e 502 errore. Ogni hop downstream deve essere inferiore a ogni hop upstream. In-edge Microgateway, è buona norma utilizzare le seguenti linee guida:

1. Il timeout keep-alive sull'applicazione client o sul bilanciatore del carico deve essere inferiore al Timeout keep-alive del Microgateway Edge.

   Per configurare il timeout keep-alive sul Microgateway Edge, aggiungi il token keep_alive_timeout al tuo ~/.edgemicro/org-env-config.yaml file.

   edgemicro:
     keep_alive_timeout: 65000
   

2. Il timeout keep-alive del sistema operativo Edge Microgateway deve essere inferiore al target timeout keep-alive del server.
3. Se ci sono altri hop davanti o dietro a Edge Microgateway, la stessa regola dovrebbe . Dovresti sempre lasciare che sia il client downstream a chiudere la connessione con l'upstream.

di Gemini Advanced.

Causa: il server di destinazione chiude prematuramente la connessione

Diagnosi

1. Segui i passaggi descritti in Passaggi comuni di diagnostica e verifica se ha ricevuto l'errore [socket hang up][ECONNRESET].
2. In caso affermativo, esegui ulteriori indagini con l'aiuto di tcpdump, come spiegato di seguito.

   Il messaggio di errore [targetRequest error][GET][][socket hang up][ECONNRESET] nell'esempio precedente indica che questo errore si è verificato mentre Edge Microgateway stava inviando la richiesta al server backend (target). In altre parole, Edge Microgateway ha inviato richiesta API al server di backend ed era in attesa di risposta. Tuttavia, il backend il server ha terminato bruscamente la connessione prima che Edge Microgateway ricevesse una risposta.

3. Controlla i log del server di backend e verifica se sono presenti errori o informazioni che potrebbero hanno portato il server di backend a interrompere bruscamente la connessione. Se riscontri errori o informazioni, quindi vai a Risoluzione e correggi il problema in modo appropriato nel tuo server di backend.
4. Se non trovi errori o informazioni nel tuo server di backend, raccogli le informazioni Output tcpdump sul server Edge Microgateway:

   tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
   

5. Analizza il tcpdump acquisito:

   Esempio di output tcpdump: ( visualizza immagine ingrandita)

   

   Nell'esempio tcpdump riportato sopra, puoi vedere quanto segue:

   1. Nel pacchetto 4, Edge Microgateway ha inviato una richiesta GET alla destinazione server web.
   2. Nel pacchetto 5, il server di destinazione ha risposto con ACK per confermare la richiesta.
   3. Tuttavia, nel pacchetto 6, invece di rispondere con un payload di risposta, la destinazione il server invia un FIN, ACK che avvia la chiusura della connessione.
   4. Nei pacchetti 7 in poi, la connessione si chiude a vicenda. Dato che la connessione è stata chiuso prima dell'invio della risposta, Edge Microgateway restituirà l'elemento HTTP 502 al client.
   5. Tieni presente che il timestamp del pacchetto 8, 2021-06-23T03:52:24.110Z corrisponde al timestamp in cui è stato registrato l'errore in Edge Microgateway logaritmi. Spesso i timestamp nei file di log e in tcpdump possono da utilizzare per correlare gli errori con i pacchetti effettivi.

   Risoluzione

   Risolvi correttamente il problema sul server di backend.

   Se il problema persiste e hai bisogno di assistenza per risolvere il problema 502 Bad Gateway Error o sospetti che si tratti di un problema all'interno di Edge Microgateway, vai su Devi raccogliere i dati diagnostici.

   Raccogliere dati diagnostici

   Se il problema persiste anche dopo aver seguito le istruzioni riportate sopra, raccogli i seguenti dati informazioni diagnostiche e contattare l'assistenza Apigee Edge:

   • File di log: la cartella predefinita è /var/tmp, ma potrebbe essere sostituita nel file config.yaml principale (logging > dir parameter). È ti consigliamo di modificare log > level in info prima di fornire i file di log all'assistenza Apigee.
   • File di configurazione: la configurazione principale di Edge Microgateway risiede nella File YAML nella cartella Edge Microgateway predefinita, $HOME/.edgemicro. C'è un il file di configurazione predefinito denominato default.yaml e uno per ogni ambiente ORG-ENV-config.yaml. Carica questo file per l'organizzazione e l'ambiente colpiti.