499 Connessione client chiusa

Stai visualizzando la documentazione di Apigee Edge.
Vai alla sezione Documentazione di Apigee X. Informazioni

Sintomo

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

Osserverai il codice di stato 499 per queste richieste API in API Monitoring e Log di accesso NGINX. A volte, vedrai codici di stato diversi in API Analytics 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 su Edge Platform è Cliente > Router > Processore di messaggi > Server di backend, come illustrato nella figura seguente:

I router e i processori di messaggi all'interno della piattaforma Apigee Edge sono configurati con valori di timeout predefiniti 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 adeguato in base alle proprie esigenze.

I client come i browser web e le app mobile hanno dei timeout definiti dal sistema operativo.

Timeout sul router

Il timeout predefinito configurato sui router è 57 secondi. Si tratta dell'intervallo di tempo massimo Il proxy API può essere eseguito dal momento in cui la richiesta API viene ricevuta su Edge fino a quando la risposta non viene che viene restituito, inclusa la risposta del backend e tutti i criteri eseguiti. Il valore predefinito il timeout sui router e sugli host virtuali come spiegato Configurazione del timeout di I/O sui router.

Timeout sui processori di messaggi

Il timeout predefinito configurato sui processori di messaggi è 55 secondi. Questo è l'importo massimo di tempo che il server di backend può impiegare per elaborare la richiesta e rispondere al messaggio Processore. Il timeout predefinito può essere ignorato sui processori di messaggi o all'interno dell'API Proxy come spiegato in Configurazione del timeout di I/O sui processori di messaggi.

Se il client chiude la connessione con il router prima del timeout del proxy API, osserverà l'errore di timeout per la specifica richiesta API. Il codice di stato 499 Client Closed Connection è stato registrato nel router per queste richieste, che possono essere osservate nell'API Monitoraggio e log degli accessi NGINX.

Possibili cause

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

Causa	Descrizione	Le istruzioni di risoluzione dei problemi applicabili a
Il client ha chiuso bruscamente la connessione	Questo accade quando il client chiude la connessione perché l'utente finale ha annullato la una richiesta prima che venga completata.	Utenti di cloud pubblico e privato
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 ciò si verifica quando il timeout del client è inferiore rispetto al timeout del router.	Utenti di cloud pubblico e privato

Passaggi diagnostici comuni

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

• Monitoraggio delle API
• Log di accesso NGINX

Causa: il client ha chiuso improvvisamente la connessione

Diagnosi

1. Quando un'API viene chiamata da un'app a pagina singola in esecuzione in un browser o in un'applicazione mobile, il browser interromperà la richiesta se l'utente finale chiude improvvisamente il browser, naviga a un'altra pagina web nella stessa scheda o interrompe il caricamento della pagina facendo clic o toccando close interrompi il caricamento.
2. In questo caso, le transazioni con stato HTTP 499 variano in genere nel tempo di elaborazione delle richieste (Tempo di risposta) per ciascuna richiesta.
3. Puoi stabilire se questa è la causa confrontando il Tempo di risposta e verificando se è diverso per ogni errore 499 che utilizza il monitoraggio delle API o l'accesso NGINX come spiegato in Passaggi comuni di diagnostica.

Risoluzione

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

2. Se si verifica spesso per lo stesso percorso dell'URL, è possibile che lo stesso proxy associati al percorso è molto lento e gli utenti non vogliono aspettare.

   Quando sai quale proxy potrebbe essere interessato, utilizza il Latenza dashboard di analisi per esaminare ulteriormente la causa della latenza del proxy.

   1. In questo caso, per determinare il proxy interessato, segui i passaggi nella Passaggi diagnostici comuni.
   2. Utilizza la Dashboard per l'analisi della latenza per esaminare ulteriormente la causa della latenza del proxy risolvere il problema.
   3. Se noti che la latenza è prevista per il proxy specifico, è possibile che per informare gli utenti che il proxy impiegherà un po' di tempo per rispondere.

Causa: timeout dell'applicazione client

Ciò può verificarsi in una serie di scenari.

1. È previsto che il completamento della richiesta richieda un certo tempo (diciamo 10 secondi) in normali condizioni di funzionamento. Tuttavia, l'applicazione client è impostata con un errore valore di timeout (ad esempio 5 secondi) che causa il timeout dell'applicazione client prima del la richiesta API viene completata, generando 499. In questo caso, dobbiamo impostare il timeout del client su un valore appropriato.
2. Un server o un callout di destinazione sta richiedendo più tempo del previsto. In questo caso, devi correggere i componenti appropriati e i valori di timeout in modo appropriato.
3. Il cliente non aveva più bisogno della risposta e pertanto l'ha interrotta. Questo può accadere in caso di utenti a frequenza elevata, come il completamento automatico o il polling breve.

Diagnosi

Log di accesso di API Monitoring o NGINX

Diagnostica l'errore utilizzando i log di accesso di API Monitoring o NGINX:

1. Controlla i log di monitoraggio delle API o di accesso NGINX per verificare le transazioni HTTP 499 come spiegato in Passaggi comuni per la diagnostica.
2. Determina se il tempo di risposta è coerente per tutti gli errori 499.
3. Se sì, è possibile che una determinata applicazione client abbia configurato un timeout fisso dalla sua parte. Se un proxy API o un server di destinazione risponde lentamente, si verifica un timeout del client prima del timeout del proxy, generando grandi quantità di 499s HTTP per lo stesso percorso URI. In questo caso, determina lo User agent dai log di accesso NGINX può aiutarti a determinare l'applicazione client specifica.
4. È anche possibile che ci sia un bilanciatore del carico davanti ad Apigee, come Akamai, F5, AWS ELB e così via. Se Apigee è in esecuzione dietro un bilanciatore del carico personalizzato, la richiesta del bilanciatore del carico deve essere configurato in modo da essere superiore al timeout dell'API Apigee. Di predefinito, il router Apigee scade dopo 57 secondi, quindi è adatto configurare una richiesta di 60 secondi sul bilanciatore del carico.

Trace

Diagnosticare l'errore utilizzando Trace

Se il problema è ancora attivo (499 errori continuano a verificarsi), esegui la seguenti passaggi:

1. Attiva il sessione di tracciamento per l'API interessata nella UI Edge.
2. Attendi che si verifichi l'errore oppure, se hai ricevuto la chiamata API, effettua alcune chiamate API e riprodurre l'errore.
3. Controlla il tempo trascorso in ogni fase e prendi nota della fase in cui la maggior parte del tempo di Google Cloud.
4. Se noti l'errore con il tempo trascorso più lungo subito dopo uno dei le fasi successive, indica che il server di backend è lento o richiede molto tempo per elaborare la richiesta:
   • Richiesta inviata al server di destinazione
   • Norme ServiceCallout

   Ecco una traccia UI di esempio che mostra un Timeout del gateway dopo che la Richiesta è stata inviati al server di destinazione

   

Risoluzione

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

Se il problema persiste, vai all'articolo È necessario raccogliere i dati diagnostici .

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 organizzazione
• Nome ambiente
• Nome proxy API
• Completa il comando curl utilizzato per riprodurre l'errore di timeout
• File di traccia per le richieste API per le quali si verificano 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 proxy API
• File di traccia per le richieste API per le quali si verificano errori di timeout del client
• Log di accesso 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)