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
- Controlla i log di Edge Microgateway:
/var/tmp/edgemicro-`hostname`-*.log
- Cerca per vedere se si sono verificati errori
502
con il codiceECONNRESET
durante un periodo di tempo specifico (se il problema si è verificato in passato) o se ci sono ancora richieste che continuano a non riuscire con502
.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][]
- Se hai impostato il livello di logging su
warn
oinfo
, 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 untcpdump
.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]
- 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
- Segui la procedura descritta in Procedure comuni di diagnostica e verifica se hai ricevuto
l'errore
[socket hang up][ECONNRESET]
. Se sì, esamina ulteriormente con l'aiuto di
tcpdump
come spiegato di seguito:
Utilizzo di tcpdump
- 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
- Analizza gli
tcpdump
acquisiti:Esempio di output di tcpdump: ( visualizza immagine ingrandita)
Nell'esempio
tcpdump
sopra, puoi vedere quanto segue:- Nel pacchetto 250288, il client invia una richiesta
POST
. - Nel pacchetto 250371, il server risponde con
200 OK
. - Nel pacchetto 250559, il client invia un comando
ACK.
- Nel pacchetto 250560, il server invia il messaggio
Continuation
. - Nel pacchetto 250561, il client invia un comando
ACK.
- 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). - 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 unRST
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.
- Nel pacchetto 250288, il client invia una richiesta
Confrontare i timeout keep-alive
- 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.
- È 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.
- 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.
- 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.
- Determina il valore impostato per il timeout keep-alive sul server di backend.
- 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:
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
- Il timeout keep-alive del sistema operativo Edge Microgateway deve essere inferiore al timeout keep-alive del server di destinazione.
- 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
- Segui i passaggi descritti nella sezione Procedure comuni di diagnostica e verifica se hai ricevuto l'errore
[socket hang up][ECONNRESET]
. - 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. - 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.
- 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
- Analizza gli
tcpdump
acquisiti:Esempio di output di tcpdump: ( visualizza immagine ingrandita)
Nell'esempio
tcpdump
sopra, puoi vedere quanto segue:- Nel pacchetto 4, Edge Microgateway ha inviato una richiesta
GET
al server di destinazione. - Nel pacchetto 5, il server di destinazione ha risposto con
ACK
per confermare la richiesta. - 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. - 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
. - 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 intcpdump
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 fileconfig.yaml
principale (logging > dir parameter
). È consigliabile modificarelog > level
ininfo
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 denominatodefault.yaml
, seguito da uno per ogni ambienteORG-ENV-config.yaml
. Carica il file per intero per l'organizzazione e l'ambiente interessati.
- Nel pacchetto 4, Edge Microgateway ha inviato una richiesta