Stai visualizzando la documentazione di Apigee Edge.
Vai alla sezione
Documentazione di Apigee X. Informazioni
Sintomo
L'applicazione client riceve uno stato di risposta HTTP 503 con il messaggio
Service Unavailable a seguito di una chiamata proxy API.
Messaggio di errore
L'applicazione client riceve il seguente codice di risposta:
HTTP/1.1 503 Service Unavailable
Potresti inoltre visualizzare il seguente messaggio di errore:
{
"fault": {
"faultstring": "The Service is temporarily unavailable",
"detail": {
"errorcode": "messaging.adaptors.http.flow.ServiceUnavailable"
}
}
}Possibili cause
| Causa | Descrizione | Le istruzioni di risoluzione dei problemi applicabili a |
|---|---|---|
| Il server di destinazione chiude prematuramente la connessione | Il server di destinazione termina prematuramente la connessione mentre il processore di messaggi è ancora che invia il payload della richiesta. | Utenti perimetrali di cloud pubblici e privati |
Passaggi diagnostici comuni
Determinare l'ID messaggio della richiesta non riuscita
Strumento Trace
Per determinare l'ID messaggio della richiesta non riuscita utilizzando lo strumento Trace:
- Se il problema è ancora attivo, abilita sessione di tracciamento per l'API interessata.
- Effettua la chiamata API e riproduci il problema -
503 Service Unavailablecon codice di erroremessaging.adaptors.http.flow.ServiceUnavailable. - Seleziona una delle richieste non riuscite.
- Vai alla fase AX e determina l'ID messaggio.
(
X-Apigee.Message-ID) della richiesta scorrendo verso il basso Dettagli fase come mostrato nella figura che segue.
Log di accesso NGINX
Per determinare l'ID messaggio della richiesta non riuscita utilizzando i log di accesso NGINX:
Puoi anche fare riferimento ai log di accesso NGINX per determinare l'ID messaggio degli errori 503.
Ciò è particolarmente utile se il problema si è verificato in passato o se il problema è intermittente
e non riesci ad acquisire la traccia nell'interfaccia utente. Segui questi passaggi per determinare queste informazioni dai log di accesso di NGINX:
- Controlla i log di accesso NGINX: (
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log) - Cerca se sono presenti errori
503per il proxy API specifico durante un periodo di tempo specifico (se il problema si è verificato in passato) o se sono presenti richieste ancora non riuscite con503. - Se si verificano errori di
503con X-Apigee-fault-code messages.adaptors.http.flow.ServiceUnavailable, Prendi nota dell'ID messaggio per una o più richieste di questo tipo, come mostrato nell'esempio seguente:Voce di esempio che mostra l'errore
503
Causa: il server di destinazione chiude prematuramente la connessione
Diagnosi
- Se sei un utente Public Cloud o Private Cloud:
- .
- Utilizza lo strumento Trace (come spiegato nella sezione Passaggi di diagnostica comuni)
e verifica di avere impostato entrambi i seguenti elementi nel riquadro Dati registrati di Analytics:
- X-Apigee.fault-code:
messaging.adaptors.http.flow.ServiceUnavailable - X-Apigee.fault-source:
target

- X-Apigee.fault-code:
- Utilizza lo strumento Trace (come spiegato nella sezione Passaggi di diagnostica comuni)
e verifica di aver impostato entrambi i seguenti elementi nel riquadro Errore subito dopo
la proprietà state
TARGET_REQ_FLOW:- error.class:
com.apigee.errors.http.server.ServiceUnavailableException - error.cause:
Broken pipe

- error.class:
- Vai a Utilizzare tcpdump per ulteriori indagini.
- Utilizza lo strumento Trace (come spiegato nella sezione Passaggi di diagnostica comuni)
e verifica di avere impostato entrambi i seguenti elementi nel riquadro Dati registrati di Analytics:
- Se sei un utente Private Cloud:
- .
- Stabilisci l'ID messaggio della richiesta non riuscita.
- Cerca l'ID messaggio nel log del processore di messaggi
(
/opt/apigee/var/log/edge-message-processor/logs/system.log) - Verrà visualizzata una delle seguenti eccezioni:
Eccezione 1: java.io.IOException: pipe interrotta durante la scrittura sul canale ClientOutputChannel
2021-01-30 15:31:14,693 org:anotherorg env:prod api:myproxy rev:1 messageid:myorg-opdk-test-1-30312-13747-1 NIOThread@1 INFO HTTP.SERVICE - ExceptionHandler.handleException() : Exception java.io.IOException: Broken pipe occurred while writing to channel ClientOutputChannel(ClientChannel[Connected: Remote:IP:PORT Local:0.0.0.0:42828]@8380 useCount=1 bytesRead=0 bytesWritten=76295 age=2012ms lastIO=2ms isOpen=false)
o
Eccezione 2: eccezione onExceptionWrite: {}
java.io.IOEccezione: pipeline rotta2021-01-31 15:29:37,438 org:anotherorg env:prod api:503-test rev:1 messageid:leonyoung-opdk-test-1-18604-13978-1 NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$2.onException() : ClientChannel[Connected: Remote:IP:PORT Local:0.0.0.0:57880]@8569 useCount=1 bytesRead=0 bytesWritten=76295 age=3180ms lastIO=2 ms isOpen=false.onExceptionWrite exception: {} java.io.IOException: Broken pipe
- Entrambe queste eccezioni indicano che mentre il processore di messaggi stava ancora scrivendo
la richiesta di payload al server di backend, la connessione è stata chiusa prematuramente
di backend. Pertanto, il processore di messaggi genera l'eccezione
java.io.IOException: Broken pipe. Remote:IP:PORTindica il server di backend risolto l'indirizzo IP e il numero di porta.- L'attributo
bytesWritten=76295nel messaggio di errore precedente indica che il processore di messaggi ha inviato un payload di76295byte al backend server quando la connessione è stata chiusa prematuramente. - L'attributo
bytesRead=0indica che il processore di messaggi non ha ricevuto dati (risposta) dal server di backend. - Per esaminare ulteriormente il problema, raccogli un
tcpdumpsul backend o il processore di messaggi e analizzarlo come spiegato di seguito.
Utilizzo di tcpdump
-
Acquisisci un
tcpdumpsul server di backend o sul processore di messaggi con i seguenti comandi:Comando per raccogliere
tcpdumpsul server di backend:tcpdump -i any -s 0 host MP_IP_ADDRESS -w FILE_NAME
Comando per raccogliere
tcpdumpsul processore di messaggi:tcpdump -i any -s 0 host BACKEND_HOSTNAME -w FILE_NAME
- Analizza il
tcpdumpacquisito:Esempio di output tcpdump (raccolto sul processore di messaggi):

Nei valori
tcpdumpprecedenti, puoi visualizzare quanto segue:- Nel pacchetto
4, il processore di messaggi ha inviato una richiestaPOSTal il server di backend. - Nel pacchetto
5,8,9,10,11, il processore di messaggi ha continuato a inviare il payload di richiesta al di backend. - Nel pacchetto
6e7,il server di backend ha risposto conACKper una parte del payload ricevuto dal processore di messaggi. - Tuttavia, nel pacchetto
12, invece di rispondere con unACKper i pacchetti di dati dell'applicazione ricevuti e rispondendo poi con la risposta payload, il server di backend invece risponde con unFIN ACKavviando la chiusura della connessione. - Questo mostra chiaramente che il server di backend chiude prematuramente la connessione mentre il processore di messaggi inviava ancora il payload per le richieste.
- In questo modo il processore di messaggi registra un'
IOException: Broken Pipee restituisce un503al client
- Nel pacchetto
Risoluzione
- Collabora con uno o entrambi i team delle applicazioni e del networking per analizzare e correggere a causa delle disconnessioni premature lato server di backend.
- Assicurati che l'applicazione del server di backend non stia eseguendo il timeout o reimpostando la connessione prima di ricevere l'intero payload della richiesta.
- Se hai un dispositivo o livello di networking intermedio tra Apigee e il server di backend, quindi assicurati che non si verifichino timeout prima della ricezione dell'intero payload di richiesta.
Se il problema persiste, consulta l'articolo È necessario raccogliere i dati diagnostici.
Raccogliere dati diagnostici
Se il problema persiste anche dopo aver seguito le istruzioni riportate sopra, raccogli i seguenti dati informazioni diagnostiche e contattare 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
curlper riprodurre l'errore503 - File di traccia contenente la richiesta con l'errore
503 Service Unavailable - Se al momento gli errori
503non si verificano, fornisci il periodo di tempo con le informazioni sul fuso orario quando si sono verificati503errori in passato.
Se sei un utente di Private Cloud, fornisci le seguenti informazioni:
- Messaggio di errore completo osservato per le richieste non riuscite
- Organizzazione, Nome ambiente e Nome proxy API che stai esaminando.
503errore - Bundle proxy API
- File di traccia contenente le richieste con errore
503 Service Unavailable - Log di accesso NGINX
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log - Log del processore di messaggi
/opt/apigee/var/log/edge-message-processor/logs/system.log - Il periodo di tempo con le informazioni sul fuso orario in cui si sono verificati gli errori
503 Tcpdumpsraccolti sui processori di messaggi e sul server di backend quando si è verificato un errore