499 Connessione client chiusa

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

Sintomo

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

Per queste richieste API, vedrai il codice di stato 499 in Monitoraggio API e nei log di accesso NGINX. A volte, in Analisi API vedrai codici di stato diversi perché ti mostra il codice di stato restituito dal processore di messaggi.

Messaggio di errore

Le applicazioni client potrebbero visualizzare errori come: 

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 di una richiesta API sulla piattaforma Edge è Client > 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 appropriati per garantire che le richieste API non richiedano troppo tempo per essere completate.

Timeout sul client

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

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

Timeout sul router

Il timeout predefinito configurato sui router è di 57 secondi. Questo è il tempo massimo di esecuzione di un proxy API dal momento in cui la richiesta API viene ricevuta su Edge fino all'invio della risposta, inclusa la risposta del backend e tutte le policy eseguite. Il timeout predefinito può essere sostituito 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. Questo è il tempo massimo che il server di backend può impiegare per elaborare la richiesta e rispondere al processore di messaggi . Il timeout predefinito può essere sostituito 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, vedrai l'errore di timeout per la richiesta API specifica. Il codice di stato 499 Client Closed Connection viene registrato nel router per queste richieste, che possono essere osservate in Monitoraggio API e nei log di accesso NGINX.

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 bruscamente la connessione Ciò si verifica quando il client chiude la connessione perché l'utente finale annulla la richiesta prima che venga completata. Utenti di Cloud pubblico e privato
Timeout dell'applicazione client Ciò si verifica quando l'applicazione client va in timeout 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 al timeout del router. Utenti di Cloud pubblico e privato

Passaggi di diagnostica comuni

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

  • Monitoraggio API
  • Log di accesso NGINX

Monitoraggio API

Per diagnosticare l'errore utilizzando Monitoraggio API:

  1. Vai alla pagina Analizza > Monitoraggio API > Analizza.
  2. Filtra gli errori 4xx e seleziona l'intervallo di tempo.
  3. Traccia il codice di stato rispetto al tempo.
  4. Seleziona una cella con errori 499 come mostrato di seguito:

  5. Nel riquadro a destra vedrai le informazioni sull'errore 499 come mostrato di seguito:

  6. Nel riquadro a destra, fai clic su Visualizza log.

    Nella finestra Log del traffico, prendi nota dei seguenti dettagli per alcuni errori 499:

    • Richiesta:fornisce il metodo di richiesta e l'URI utilizzati per effettuare le chiamate
    • Tempo di risposta:fornisce il tempo totale trascorso per la richiesta.

    Puoi anche recuperare tutti i log utilizzando l'API Monitoraggio API GET logs. Ad esempio, eseguendo una query sui log per org, env, timeRange, e status, potresti scaricare tutti i log per le transazioni in cui il client ha raggiunto il timeout.

    Poiché Monitoraggio API imposta il proxy su - per gli errori HTTP 499, puoi utilizzare l'API (API Logs) per ottenere il proxy associato per l'host virtuale e il percorso.

    For example : 

    curl "https://apimonitoring.enterprise.apigee.com/logs/apiproxies?org=ORG&env=ENV&select=https://VIRTUAL_HOST/BASEBATH" -H "Authorization: Bearer $TOKEN"
  7. Esamina il tempo di risposta per altri errori 499 e verifica se il tempo di risposta è coerente (ad esempio 30 secondi) per tutti gli errori 499.

Log di accesso NGINX

Per diagnosticare l'errore utilizzando i log di accesso NGINX:

  1. Se sei un utente di Cloud privato, puoi utilizzare i log di accesso NGINX per determinare le informazioni chiave sugli errori HTTP 499.
  2. Controlla i log di accesso NGINX:
    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
  3. Cerca se sono presenti errori 499 durante un periodo di tempo specifico (se il problema si è verificato in passato) o se sono presenti richieste che continuano a non riuscire con 499.
  4. Prendi nota delle seguenti informazioni per alcuni errori 499:
    • Tempo di risposta totale
    • URI della richiesta
    • User agent

    Esempio di errore 499 dal log di accesso NGINX:

    2019-08-23T06:50:07+00:00       rrt-03f69eb1091c4a886-c-sy      50.112.119.65:47756
10.10.53.154:8443       10.001  -       -       499     -       422     0
   GET /v1/products HTTP/1.1        -       okhttp/3.9.1    api.acme.org
rrt-03f69eb1091c4a886-c-sy-13001-6496714-1
    50.112.119.65   -       -       -       -       -       -       -       -1      -       -       dc-1  router-pod-1
rt-214-190301-0020137-latest-7d
36       TLSv1.2 gateway-1     dc-1  acme    prod  https   -

    Per questo esempio, vediamo le seguenti informazioni:

    • Tempo di risposta totale:10.001 secondi. Ciò indica che il client ha raggiunto il timeout dopo 10,001 secondi
    • Richiesta:GET /v1/products
    • Host:api.acme.org
    • User agent:okhttp/3.9.1
  5. Verifica se il tempo di risposta totale e lo user agent sono coerenti per tutti gli errori 499.

Causa: il client ha chiuso bruscamente 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 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 facendo clic o toccando Interrompi caricamento.
  2. In questo caso, i tempi di elaborazione delle transazioni con stato HTTP 499 (Tempo di risposta) variano in genere per ogni richiesta.
  3. Puoi determinare se questa è la causa confrontando il tempo di risposta e verificando se è diverso per ciascuno degli errori 499 utilizzando Monitoraggio API o i log di accesso NGINX come spiegato in Passaggi di diagnostica comuni.

Risoluzione

  1. Questo è normale e in genere 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, potrebbe essere perché il proxy specifico associato a quel percorso è molto lento e gli utenti non sono disposti ad aspettare.

    Una volta individuato il proxy potenzialmente 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 seguendo i passaggi descritti in Passaggi di diagnostica comuni.
    2. Utilizza la dashboard di analisi della latenza per esaminare ulteriormente la causa della latenza del proxy e risolvere il problema.
    3. Se riscontri che la latenza è prevista per il proxy specifico, potresti dover informare gli utenti che questo proxy impiegherà un po' di tempo per rispondere.

Causa: timeout dell'applicazione client

Questo può verificarsi in diversi scenari.

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

Diagnosi

Monitoraggio API o log di accesso NGINX

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

  1. Controlla i log di Monitoraggio API o i log di accesso NGINX per le transazioni HTTP 499 come spiegato in Passaggi di diagnostica comuni.
  2. Determina se il tempo di risposta è coerente per tutti gli errori 499.
  3. In caso affermativo, è 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, il client raggiungerà il timeout prima del proxy, generando grandi quantità di HTTP 499s per lo stesso percorso URI. In questo caso, determina lo user agent dai log di accesso NGINX, che possono aiutarti a determinare l'applicazione client specifica.
  4. Potrebbe anche essere presente 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, il timeout della richiesta del bilanciatore del carico deve essere configurato in modo che sia superiore al timeout dell'API Apigee. Per impostazione predefinita, il router Apigee raggiunge il timeout dopo 57 secondi, quindi è opportuno configurare un timeout della richiesta di 60 secondi sul bilanciatore del carico.

Traccia

Diagnostica l'errore utilizzando Trace

Se il problema è ancora attivo (si verificano ancora errori 499), segui questi passaggi:

  1. Attiva la sessione di traccia per l'API interessata nell'interfaccia utente di 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 trascorso la maggior parte del tempo viene trascorso.
  4. Se riscontri l'errore con il tempo trascorso più lungo immediatamente 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
    • Policy ServiceCallout

    Ecco un esempio di traccia dell'interfaccia utente che mostra un timeout del gateway dopo che la richiesta è stata inviata al server di destinazione:

Risoluzione

  1. Consulta Best practice per la configurazione del timeout di I/O per capire quali valori di timeout devono essere impostati sui diversi componenti coinvolti nel flusso di richieste API tramite 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 a Raccogliere informazioni di diagnostica .

Raccogliere informazioni di diagnostica

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

Se sei un utente di Cloud pubblico, fornisci le seguenti informazioni:

  • Nome 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 visualizzi errori di timeout del client

Se sei un utente di Cloud privato, 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 visualizzi 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)