502 Bad Gateway - Presa di corrente

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 Bad Gateway con il codice ECONNRESET come risposta per le 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 Istruzioni per la 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 di cloud pubblico e privato perimetrale
Il server di destinazione chiude la connessione prematuramente Il server di destinazione chiude prematuramente la connessione mentre Edge Microgateway invia il payload della richiesta. Utenti di cloud pubblico e privato perimetrale

Passaggi di diagnosi più comuni

  1. Controlla i log di Edge Microgateway: 
    /var/tmp/edgemicro-`hostname`-*.log
  2. Cerca per vedere se si sono verificati errori 502 con il codice ECONNRESET durante un periodo di tempo specifico (se il problema si è verificato in passato) o se ci sono ancora richieste che continuano a non riuscire 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 hai impostato il livello di logging 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 e può essere utilizzata 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. Questa operazione può essere eseguita nei log per determinarne la frequenza.

Causa: timeout keep-alive configurato in modo errato

Diagnostica

  1. Segui la procedura descritta in Procedure comuni di diagnostica e verifica se hai ricevuto l'errore [socket hang up][ECONNRESET].

  2. Se sì, esamina ulteriormente con l'aiuto di tcpdump come spiegato di seguito:

Utilizzo di tcpdump

  1. Acquisisci un tcpdump tra Edge Microgateway e il server di backend sul sistema operativo host di Edge Microgateway con il seguente comando: 
    tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
  2. Analizza gli tcpdump acquisiti:

    Esempio di output di tcpdump: ( visualizza immagine ingrandita)

    Nell'esempio tcpdump 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 un comando ACK.
    4. Nel pacchetto 250560, il server invia il messaggio Continuation.
    5. Nel pacchetto 250561, il client invia un comando ACK.
    6. Nel pacchetto 262436, il server invia un FIN, ACK al client per avviare la chiusura della connessione. Nota: circa cinque secondi dopo il pacchetto precedente (250561).
    7. Nel pacchetto 262441, il client invia un'altra richiesta POST. Tuttavia, l'operazione non riesce perché il server ha già avviato la chiusura della connessione. Risponde con un RST nel pacchetto 262441.

    La stessa connessione è stata riutilizzata almeno una volta con successo in questo esempio, ma nella richiesta finale il server avvia una chiusura della connessione dopo cinque secondi di inattività, che avviene nello stesso momento in cui il client ha inviato una nuova richiesta. Questo suggerisce che il timeout keep-alive del server di backend è molto probabilmente più breve o uguale al valore impostato nel client. Per convalidare questa impostazione, consulta Confrontare 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 su cui viene eseguita. Esempi comuni sono i container Windows, Linux e Docker.
  2. È possibile che sia personalizzato 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. Successivamente, verifica la proprietà di timeout keep-alive configurata sul tuo server di backend. 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 nel sistema operativo è superiore al valore della proprietà di timeout keep-alive sul server di backend come nell'esempio precedente, questa è la causa degli errori 502.

Risoluzione

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

Best practice

Consigliamo vivamente che i componenti downstream abbiano sempre una soglia di timeout keep-alive inferiore rispetto a quella configurata sui server upstream per evitare questo tipo di race condition e errori 502. Ogni hop downstream deve essere inferiore a ogni hop upstream. In Edge Microgateway, è consigliabile utilizzare le seguenti linee guida:

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

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

    edgemicro:
  keep_alive_timeout: 65000
  2. Il timeout keep-alive del sistema operativo 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 lasciare sempre la responsabilità del client downstream di chiudere la connessione con l'upstream.

Causa: il server di destinazione chiude la connessione prematuramente

Diagnostica

  1. Segui i passaggi descritti nella sezione Procedure comuni di diagnostica e verifica se hai ricevuto l'errore [socket hang up][ECONNRESET].
  2. In caso affermativo, procedi a ulteriori accertamenti con l'aiuto di tcpdump, come spiegato di seguito.

    Il messaggio di errore [targetRequest error][GET][][socket hang up][ECONNRESET] nell'esempio sopra riportato indica che questo errore si è verificato mentre Edge Microgateway inviava la richiesta al server di backend (target). In altre parole, Edge Microgateway ha inviato la richiesta API al server di backend ed era in attesa della risposta. Tuttavia, il server di backend 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 aver portato il server di backend a terminare improvvisamente 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 tuo server di backend, raccogli l'output tcpdump sul server Edge Microgateway: 
    tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
  5. Analizza gli tcpdump acquisiti:

    Esempio di output di tcpdump: ( visualizza immagine ingrandita)

    Nell'esempio tcpdump 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 confermare la richiesta.
    3. Tuttavia, nel pacchetto 6, invece di rispondere con un payload di risposta, il server di destinazione invia un FIN, ACK dando inizio alla chiusura della connessione.
    4. Nei pacchetti da 7 in poi, la connessione viene chiusa reciprocamente. Poiché la connessione è stata chiusa prima dell'invio della risposta, Edge Microgateway restituirà al client l'errore HTTP 502.
    5. Tieni presente che il timestamp del pacchetto 8 2021-06-23T03:52:24.110Z corrisponde al timestamp in cui l'errore è stato registrato nei log di Edge Microgateway. Spesso i timestamp nei file di log e in tcpdump possono essere utilizzati per correlare gli errori con i pacchetti effettivi.

    Risoluzione

    Risolvi il problema sul server di backend in modo appropriato.

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

    Devi raccogliere dati diagnostici

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

    • File di log: la cartella predefinita è /var/tmp, ma è possibile eseguirne l'override nel file config.yaml principale (logging > dir parameter). È consigliabile 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 Edge Microgateway predefinita, $HOME/.edgemicro. Esiste un file di configurazione predefinito denominato default.yaml, seguito da uno per ogni ambiente ORG-ENV-config.yaml. Carica il file per intero per l'organizzazione e l'ambiente interessati.