499 Connessione client chiusa

Stai visualizzando la documentazione di Apigee Edge.
Vai alla documentazione di Apigee X. informazioni

Sintomo

L'applicazione client riceve un errore di timeout per le richieste API o la richiesta viene terminata bruscamente mentre la richiesta API è ancora in esecuzione su Apigee.

Potrai osservare il codice di stato 499 per queste richieste API in API Monitoring e nei log degli accessi NGINX. A volte, vedrai codici di stato diversi in Analisi delle API perché mostra il codice di stato restituito dal processore di messaggi.

Messaggio di errore

Le applicazioni client potrebbero visualizzare errori quali:

curl: (28) Operation timed out after 6001 milliseconds with 0 out of -1 bytes received

Quali sono le cause dei timeout del client?

Il percorso tipico per una richiesta API sulla piattaforma Edge è Cliente > Router > Processore di messaggi > Server di backend, come mostrato nella figura seguente:

I router e i processori di messaggi all'interno della piattaforma Apigee Edge sono configurati con valori di timeout predefiniti adatti per garantire che il completamento delle richieste API non richieda troppo tempo.

Timeout sul client

Le applicazioni client possono essere configurate con un valore di timeout appropriato in base alle proprie esigenze.

Client come browser web e app mobile hanno timeout definiti dal sistema operativo.

Timeout sul router

Il timeout predefinito configurato sui router è di 57 secondi. Si tratta del tempo massimo di esecuzione di un proxy API dal momento in cui la richiesta API viene ricevuta su Edge fino al reinvio della risposta, inclusi la risposta del backend e tutti i criteri eseguiti. Il timeout predefinito può essere ignorato sui router e sugli host virtuali, come spiegato in Configurare il timeout di I/O sui router.

Timeout sui processori di messaggi

Il timeout predefinito configurato sui processori di messaggi è di 55 secondi. Si tratta del tempo massimo che il server di backend può impiegare per elaborare la richiesta e rispondere al processore di messaggi. Il timeout predefinito può essere ignorato sui processori di messaggi o all'interno del proxy API, come spiegato in Configurare il timeout di I/O sui processori di messaggi.

Se il client chiude la connessione con il router prima del timeout del proxy API, osserverai l'errore di timeout per la richiesta API specifica. Per queste richieste, il codice di stato 499 Client Closed Connection viene registrato nel router, che può essere osservato nei log di API Monitoring e NGINX Access.

Possibili cause

In Edge, le cause tipiche dell'errore 499 Client Closed Connection sono:

Causa	Descrizione	Istruzioni per la risoluzione dei problemi applicabili a
Il client ha chiuso improvvisamente la connessione	Questo accade quando il client chiude la connessione perché l'utente finale annulla la richiesta prima che venga completata.	Utenti di cloud pubblici e privati
Timeout applicazione client	Questo accade quando l'applicazione client scade prima che il proxy API abbia il tempo di elaborare e inviare la risposta. In genere questo accade quando il timeout del client è inferiore al timeout del router.	Utenti di cloud pubblici e privati

Passaggi di diagnosi più comuni

Utilizza uno dei seguenti strumenti/tecniche per diagnosticare questo errore:

• Monitoraggio delle API
• Log degli accessi NGINX

Causa: il client ha chiuso improvvisamente la connessione

Diagnostica

1. Quando un'API viene chiamata da un'app a pagina singola in esecuzione in un browser o in un'applicazione mobile, il browser interrompe la richiesta se l'utente finale chiude improvvisamente il browser, passa a un'altra pagina web nella stessa scheda o interrompe il caricamento della pagina toccando o facendo clic su close interrompi caricamento.
2. In questo caso, in genere le transazioni con stato HTTP 499 variano in base al tempo di elaborazione delle richieste (Tempo di risposta) per ciascuna richiesta.
3. Puoi determinare se questa è la causa confrontando il tempo di risposta e verificando se è diverso per ciascuno degli errori 499 utilizzando i log di monitoraggio delle API o di accesso NGINX, come spiegato nella sezione Passaggi comuni di diagnosi.

Risoluzione

1. Questo è normale e di solito non è un motivo di preoccupazione se gli errori HTTP 499 si verificano in quantità ridotte.

2. Se accade spesso per lo stesso percorso dell'URL, è possibile che il proxy associato a quel percorso sia molto lento e gli utenti non siano disposti ad attendere.

   Una volta scoperto quale proxy potrebbe essere interessato, utilizza la dashboard di analisi della latenza per esaminare ulteriormente la causa della latenza del proxy.

   1. In questo caso, determina il proxy interessato utilizzando la procedura descritta in Passaggi di diagnostica comuni.
   2. Utilizza la dashboard dell'analisi della latenza per esaminare ulteriormente la causa della latenza proxy e risolvere il problema.
   3. Se ritieni che la latenza sia prevista per un proxy specifico, potresti dover comunicare agli utenti che il proxy impiegherà del tempo per rispondere.

Causa: timeout dell'applicazione client

Questo può accadere in diversi casi.

1. Prevediamo che il completamento della richiesta richieda un certo tempo (ad esempio 10 secondi) in condizioni operative normali. Tuttavia, l'applicazione client è impostata con un valore di timeout errato (ad esempio 5 secondi) che causa il timeout dell'applicazione client prima che la richiesta API venga completata, il che genera 499. In questo caso, dobbiamo impostare il timeout del client su un valore appropriato.
2. Un server di destinazione o un callout sta richiedendo più tempo del previsto. In questo caso, devi correggere il componente appropriato e regolare i valori di timeout in modo appropriato.
3. Il client non aveva più bisogno della risposta e quindi l'ha interrotta. Questo può accadere per le API ad alta frequenza, come il completamento automatico o il polling breve.

Diagnostica

Log degli accessi di API Monitoring o NGINX

Per diagnosticare l'errore, utilizza i log degli accessi di API Monitoring o NGINX:

1. Verifica le transazioni HTTP 499 nei log di monitoraggio delle API o negli accessi di NGINX, come spiegato nella sezione Passaggi comuni di diagnosi.
2. Determina se il tempo di risposta è coerente per tutti gli errori 499.
3. Se sì, potrebbe essere che una determinata applicazione client abbia configurato un timeout fisso. Se un proxy API o un server di destinazione risponde lentamente, si verifica il timeout del client prima del timeout del proxy, causando grandi quantità di 499s HTTP per lo stesso percorso URI. In questo caso, determina lo user agent dai log degli accessi NGINX che possono aiutarti a determinare l'applicazione client specifica.
4. Potrebbe anche essere possibile che ci sia un bilanciatore del carico davanti ad Apigee, come Akamai, F5, AWS ELB e così via. Se Apigee viene eseguito dietro un bilanciatore del carico personalizzato, il timeout della richiesta del bilanciatore del carico deve essere configurato in modo da essere superiore al timeout dell'API Apigee. Per impostazione predefinita, il timeout del router Apigee dopo 57 secondi è consigliabile, pertanto è opportuno configurare un timeout della richiesta di 60 secondi sul bilanciatore del carico.

Traccia

Diagnosi dell'errore utilizzando Trace

Se il problema è ancora attivo (gli errori 499 persistono), svolgi i seguenti passaggi:

1. Abilita la sessione di traccia per l'API interessata nella UI Edge.
2. Attendi che si verifichi l'errore oppure, se hai la chiamata API, effettua alcune chiamate API e riproduci l'errore.
3. Controlla il tempo trascorso in ogni fase e prendi nota della fase in cui viene dedicata la maggior parte del tempo.
4. Se noti l'errore con il tempo trascorso più lungo subito dopo una delle seguenti fasi, significa che il server di backend è lento o impiega molto tempo per elaborare la richiesta:
   • Richiesta inviata al server di destinazione
   • Norme sui callout di servizio

   Ecco una traccia UI di esempio che mostra un Timeout del gateway dopo l'invio della Richiesta al server di destinazione:

   

Risoluzione

1. Consulta le Best practice per la configurazione del timeout I/O per capire quali valori di timeout devono essere impostati sui diversi componenti coinvolti nel flusso di richieste API attraverso Apigee Edge.
2. Assicurati di impostare un valore di timeout appropriato per l'applicazione client in base alle best practice.

Se il problema persiste, consulta la pagina Devi raccogliere dati diagnostici .

Devi raccogliere dati diagnostici

Se il problema persiste, raccogli le seguenti informazioni diagnostiche e contatta l'assistenza Apigee Edge.

Se sei un utente del cloud pubblico, fornisci le seguenti informazioni:

• Nome dell'organizzazione.
• Nome ambiente
• Nome proxy API
• Comando curl completo utilizzato per riprodurre l'errore di timeout
• File di traccia per le richieste API per le quali vengono visualizzati errori di timeout del client

Se sei un utente Private Cloud, fornisci le seguenti informazioni:

• Messaggio di errore completo osservato per le richieste non riuscite
• Nome ambiente
• Bundle del proxy API
• File di traccia per le richieste API per le quali vengono visualizzati errori di timeout del client
• Log degli accessi NGINX (/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log)
• Log di sistema del processore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log)