502 Bad Gateway - Presa di corrente

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

Sintomo

L'applicazione client riceve un codice di stato HTTP di 502 Bad Gateway con il codice ECONNRESET come risposta per le chiamate API in Edge Microgateway.

Messaggio di errore

Il client visualizzerà 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

Passaggi di diagnostica comuni

1. Controlla i log di Edge Microgateway:

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

2. Cerca se sono presenti errori 502 con il codice ECONNRESET durante un periodo di tempo specifico (se il problema si è verificato in passato) o se sono presenti richieste che ancora non vanno a buon fine 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, sarà presente anche un messaggio [warn] che include il nome host e la porta del server di destinazione nel secondo elemento. In questo esempio è X.X.X.X:8080, che può essere utilizzato 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 cercare questo codice nei log per determinare la frequenza con cui si verifica.

Causa: timeout keep-alive configurato in modo errato

Diagnosi

1. Segui i passaggi descritti in Passaggi di diagnostica comuni e verifica se hai ricevuto l'errore [socket hang up][ECONNRESET].

2. In caso affermativo, approfondisci la questione con l'aiuto di tcpdump, come spiegato di seguito:

Utilizzo di tcpdump

1. Acquisisci un tcpdump tra Edge Microgateway e il server di backend su il sistema operativo host di 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 di tcpdump: ( visualizza l'immagine più grande)

   

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

   1. Nel pacchetto 250288, il client invia una POST richiesta.
   2. Nel pacchetto 250371, il server risponde con 200 OK.
   3. Nel pacchetto 250559, il client invia un ACK.
   4. Nel pacchetto 250560, il server invia il Continuation messaggio.
   5. Nel pacchetto 250561, il client invia un ACK.
   6. Nel pacchetto 262436, il server invia un FIN, ACK a il client che avvia la chiusura della connessione. Tieni presente che questo pacchetto è stato inviato circa cinque secondi dopo il pacchetto precedente (250561).
   7. Nel pacchetto 262441, il client invia un'altra POST richiesta. Tuttavia, questa richiesta non va a buon fine perché il server ha già avviato la chiusura della connessione. Il server risponde con un RST nel pacchetto 262441.

   In questo esempio, la stessa connessione è stata riutilizzata almeno una volta, ma nella richiesta finale il server avvia la chiusura della connessione dopo cinque secondi di inattività, che coincide con il momento in cui il client ha inviato una nuova richiesta. Ciò suggerisce che il timeout keep-alive del server di backend è molto probabilmente inferiore o uguale a il valore impostato nel client. Per verificare questa ipotesi, consulta Confrontare i 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 su cui è in esecuzione. Esempi comuni sono i container Windows, Linux e Docker.
2. È possibile che questa impostazione sia personalizzata nel sistema operativo. Rivolgiti al tuo amministratore di sistema. Per impostazione predefinita, i sistemi operativi Linux hanno un timeout keep-alive predefinito di due ore.
3. Poi, controlla la proprietà di timeout keep-alive configurata sul server di backend. Supponiamo che il 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 nell' esempio precedente, allora questa è la causa degli errori 502.

Risoluzione

Assicurati che la proprietà di timeout keep-alive sia sempre inferiore nel sistema operativo su cui è in esecuzione Edge Microgateway rispetto a quella del 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 sistema operativo in modo che sia inferiore al valore impostato sul server di backend seguendo i passaggi applicabili al tuo sistema operativo.

Best practice

È vivamente consigliabile che i componenti downstream abbiano sempre una soglia di timeout keep-alive inferiore a quella configurata sui server upstream per evitare questo tipo di condizioni di race e 502 errori. 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 dell'applicazione client o del bilanciatore del carico deve essere inferiore al timeout keep-alive di Edge Microgateway.

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

   edgemicro:
     keep_alive_timeout: 65000

2. Il timeout keep-alive del sistema operativo di Edge Microgateway deve essere inferiore al timeout keep-alive del server di destinazione.
3. Se hai altri hop davanti o dietro Edge Microgateway, devi applicare la stessa regola. Dovresti sempre lasciare al client downstream la responsabilità di chiudere la connessione con l'upstream.

Causa: il server di destinazione chiude prematuramente la connessione

Diagnosi

1. Segui i passaggi descritti in Passaggi di diagnostica comuni e verifica se hai ricevuto l'errore [socket hang up][ECONNRESET].
2. In caso affermativo, approfondisci la questione 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 inviava la richiesta al server di backend (di destinazione). Ovvero, Edge Microgateway ha inviato la richiesta API al server di backend e stava attendendo la risposta. Tuttavia, il server di backend ha interrotto 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 aver portato il server di backend a interrompere bruscamente la connessione. Se trovi errori o informazioni, vai a Risoluzione e correggi il problema in modo appropriato nel server di backend.
4. Se non trovi errori o informazioni nel server di backend, raccogli l' tcpdump output sul server Edge Microgateway:

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

5. Analizza il tcpdump acquisito:

   Esempio di output di tcpdump: ( visualizza l'immagine più grande)

   

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

   1. Nel pacchetto 4, Edge Microgateway ha inviato una richiesta GET al server di destinazione.
   2. Nel pacchetto 5, il server di destinazione ha risposto con ACK per riconoscere la richiesta.
   3. Tuttavia, nel pacchetto 6, anziché rispondere con un payload di risposta, il server di destinazione invia un FIN, ACK che avvia la chiusura della connessione.
   4. Nei pacchetti 7 e successivi, la connessione viene chiusa reciprocamente. Poiché la connessione è stata chiusa prima dell'invio della risposta, Edge Microgateway restituirà l'errore 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 nei log di Edge Microgateway logs. I timestamp nei file di log e in tcpdump possono spesso essere utilizzati per correlare gli errori con i pacchetti effettivi.

   Risoluzione

   Correggi il problema sul server di backend in modo appropriato.

   Se il problema persiste e hai bisogno di assistenza per risolvere i problemi 502 Bad Gateway Error o sospetti che si tratti di un problema all'interno di Edge Microgateway, vai a Informazioni di diagnostica da raccogliere.

   Informazioni di diagnostica da raccogliere

   Se il problema persiste anche dopo aver seguito le istruzioni riportate sopra, raccogli le seguenti informazioni di diagnostica e contatta l'assistenza Apigee Edge:

   • File di log: la cartella predefinita è /var/tmp, ma può 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 si trova nel file YAML nella cartella predefinita di Edge Microgateway, $HOME/.edgemicro. Esiste un file di configurazione predefinito denominato default.yaml e uno per ogni ambiente ORG-ENV-config.yaml. Carica questo file per intero per l'organizzazione e l'ambiente interessati.