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

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

Causa: il server di destinazione chiude prematuramente la connessione

Diagnosi

1. Se sei un utente Public Cloud o Private Cloud:
   .
   1. 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

      

   2. 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

      

   3. Vai a Utilizzare tcpdump per ulteriori indagini.
2. 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 rotta

     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 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:PORT indica il server di backend risolto l'indirizzo IP e il numero di porta.
   • L'attributo bytesWritten=76295 nel messaggio di errore precedente indica che il processore di messaggi ha inviato un payload di 76295 byte al backend server 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 tcpdump sul backend o il processore di messaggi e analizzarlo 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 sul processore di messaggi:

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

2. Analizza il tcpdump acquisito:

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

   

   Nei valori tcpdump precedenti, puoi visualizzare quanto segue:

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

Risoluzione

1. 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.
2. 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.
3. 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 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 quando si sono verificati 503 errori 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. 503 errore
• 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
• Tcpdumps raccolti sui processori di messaggi e sul server di backend quando si è verificato un errore