503 Servizio non disponibile - Chiusura prematura da parte del server di backend

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

Sintomo

L'applicazione client riceve uno stato di risposta HTTP 503 con il messaggio Service Unavailable dopo una chiamata proxy API.

Messaggio di errore

L'applicazione client riceve il seguente codice di risposta:

HTTP/1.1 503 Service Unavailable

Inoltre, potresti visualizzare il seguente messaggio di errore:

{
   "fault": {
      "faultstring": "The Service is temporarily unavailable",
      "detail": {
           "errorcode": "messaging.adaptors.http.flow.ServiceUnavailable"
       }
    }
}

Possibili cause

Causa	Descrizione	Istruzioni per la risoluzione dei problemi applicabili a
Il server di destinazione chiude la connessione prematuramente	Il server di destinazione termina prematuramente la connessione mentre il processore di messaggi continua a inviare il payload della richiesta.	Utenti di cloud pubblico e privato perimetrale

Passaggi di diagnosi più comuni

Determinare l'ID messaggio della richiesta non riuscita

Causa: il server di destinazione chiude la connessione prematuramente

Diagnostica

1. Se sei un utente Public Cloud o Private Cloud:
   1. Utilizza lo strumento Trace (come spiegato nella sezione Passaggi comuni di diagnosi) e verifica di avere impostato entrambi i seguenti valori nel riquadro Dati registrati di Analytics:
      • X-Apigee.fault-code: messaging.adaptors.http.flow.ServiceUnavailable
      • X-Apigee.fault-source: target

      

   2. Utilizza lo strumento Trace (come spiegato nella sezione Passaggi comuni di diagnosi) e verifica di avere impostato entrambi i seguenti valori nel riquadro Errore subito dopo la proprietà state TARGET_REQ_FLOW:
      • error.class: com.apigee.errors.http.server.ServiceUnavailableException
      • error.cause: Broken pipe

      

   3. Vai a Utilizzare tcpdump per ulteriori indagini.
2. Se sei un utente Private Cloud:
   • Determina 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).
   • Troverai una delle seguenti eccezioni:

     Eccezione n. 1: java.io.IOEccezione: si è verificata una pipeline interrotta durante la scrittura nel 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.IOException: Broken pipe

     2021-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 il payload della richiesta nel server di backend, la connessione è stata chiusa prematuramente dal server di backend. Pertanto, il processore di messaggi genera l'eccezione java.io.IOException: Broken pipe.
   • Remote:IP:PORT indica l'indirizzo IP e il numero di porta del server di backend risolto.
   • L'attributo bytesWritten=76295 nel messaggio di errore riportato sopra indica che il processore di messaggi ha inviato un payload di 76295 byte al server di backend quando la connessione è stata chiusa prematuramente.
   • L'attributo bytesRead=0 indica che il processore di messaggi non ha ricevuto dati (risposta) dal server di backend.
   • Per esaminare ulteriormente il problema, raccogli un codice tcpdump sul server di backend o sul processore di messaggi e analizzalo come spiegato di seguito.

Utilizzo di tcpdump

1. Acquisisci un tcpdump sul server di backend o sul processore di messaggi con i seguenti comandi:

   Comando per raccogliere tcpdump sul server di backend:

   tcpdump -i any -s 0 host MP_IP_ADDRESS -w FILE_NAME
   

   Comando per raccogliere tcpdump nell'elaboratore dei messaggi:

   tcpdump -i any -s 0 host BACKEND_HOSTNAME -w FILE_NAME
   

2. Analizza gli tcpdump acquisiti:

   Esempio di output tcpdump (raccolto sul processore di messaggi):

   

   In tcpdump qui sopra, puoi vedere quanto segue:

   1. Nel pacchetto 4, il processore di messaggi ha inviato una richiesta POST al server di backend.
   2. Nel pacchetto 5, 8, 9, 10, 11, il processore di messaggi ha continuato a inviare il payload della richiesta al server di backend.
   3. Nel pacchetto 6 e 7,il server di backend ha risposto con ACK per una parte del payload della richiesta ricevuta dal processore di messaggi.
   4. Tuttavia, nel pacchetto 12, invece di rispondere con un ACK per i pacchetti di dati dell'applicazione ricevuti e successivamente rispondere con il payload di risposta, il server di backend risponde con un FIN ACK avviando la chiusura della connessione.
   5. Questo mostra chiaramente che il server di backend chiude la connessione prematuramente mentre il processore di messaggi continuava a inviare il payload della richiesta.
   6. In questo modo il processore di messaggi registra un IOException: Broken Pipe errore e restituisce un 503 al client

Risoluzione

1. Collabora con uno o entrambi i team applicativi e di networking per analizzare e risolvere il problema delle disconnessioni premature sul lato server di backend.
2. Assicurati che l'applicazione del server di backend non stia eseguendo il timeout o la reimpostazione della connessione prima di ricevere l'intero payload della richiesta.
3. Se disponi di un dispositivo o livello di networking intermedio tra Apigee e il server di backend, assicurati che il timeout non venga eseguito prima che venga ricevuto l'intero payload della richiesta.

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

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:

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

• Nome dell'organizzazione.
• Nome ambiente
• Nome proxy API
• Completa il comando curl per riprodurre l'errore 503
• File di traccia contenente la richiesta con l'errore 503 Service Unavailable
• Se al momento gli errori 503 non si verificano, fornisci il periodo di tempo con le informazioni sul fuso orario in cui si sono verificati 503 errori in passato.

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

• Messaggio di errore completo osservato per le richieste non riuscite
• Organizzazione, nome dell'ambiente e nome del proxy API per cui stai osservando 503 errori
• Bundle del proxy API
• File di traccia contenente le richieste con l'errore 503 Service Unavailable
• Log degli accessi a 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 è verificato l'errore 503
• Tcpdumps raccolto sui processori di messaggi e sul server di backend quando si è verificato l'errore