EOF imprevista del gateway non valido (502)

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

Sintomo

L'applicazione client riceve un codice di stato HTTP 502 con il messaggio Bad Gateway come risposta per le chiamate API.

Il codice di stato HTTP 502 indica che il client non riceve una risposta valida dai server di backend che dovrebbero effettivamente soddisfare la richiesta.

Messaggi di errore

L'applicazione client riceve il seguente codice di risposta:

HTTP/1.1 502 Bad Gateway

Inoltre, potresti visualizzare il seguente messaggio di errore:

{
   "fault": {
      "faultstring": "Unexpected EOF at target",
      "detail": {
           "errorcode": "messaging.adaptors.http.UnexpectedEOFAtTarget"
       }
    }
}

Possibili cause

Una delle cause tipiche di 502 Bad Gateway Error è l'errore Unexpected EOF, che può essere causato dai seguenti motivi:

Causa	Dettagli	Passi indicati per
Server di destinazione configurato in modo errato	Il server di destinazione non è configurato correttamente per supportare le connessioni TLS/SSL.	Utenti di cloud pubblico e privato perimetrale
EOFEccezione dal server di backend	Il server di backend potrebbe inviare EOF in modo improvviso.	Solo utenti Edge Private Cloud
Timeout di keep-alive configurato in modo errato	Mantieni i timeout attivi configurati in modo errato su Apigee e sul server di backend.	Utenti di cloud pubblico e privato perimetrale

Passaggi di diagnosi più comuni

Per diagnosticare l'errore, puoi utilizzare uno dei seguenti metodi:

• Monitoraggio delle API
• Strumento Traccia
• Log degli accessi NGINX

Causa: server di destinazione configurato in modo errato

Il server di destinazione non è configurato correttamente per supportare le connessioni TLS/SSL.

Diagnostica

1. Usa il monitoraggio delle API, lo strumento Trace o i log di accesso NGINX per determinare l'ID messaggio, il codice di errore e l'origine dell'errore per l'errore 502.
2. Abilita la traccia nell'interfaccia utente per l'API interessata.
3. Se la traccia della richiesta API in errore mostra quanto segue:
   1. L'errore 502 Bad Gateway viene visualizzato non appena viene avviata la richiesta del flusso di destinazione.
   2. L'error.class mostra messaging.adaptors.http.UnexpectedEOF.

      Quindi è molto probabile che il problema sia causato da una configurazione errata del server di destinazione.

4. Ottieni la definizione del server di destinazione utilizzando la chiamata API Edge Management:
   1. Se sei un utente del cloud pubblico, utilizza questa API:

      curl -v https://api.enterprise.apigee.com/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>
      

   2. Se sei un utente Private Cloud, utilizza questa API:

      curl -v http://<management-server-host>:<port #>/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>
      

      Esempio di definizione di TargetServer errata:

      <TargetServer  name="target1">
        <Host>mocktarget.apigee.net</Host>
        <Port>443</Port>
        <IsEnabled>true</IsEnabled>
      </TargetServer >
      

5. La definizione illustrata di TargetServer è un esempio di uno degli errori di configurazione tipici, spiegato come segue:

   Supponiamo che il server di destinazione mocktarget.apigee.net sia configurato per accettare connessioni protette (HTTPS) sulla porta 443. Tuttavia, se guardi la definizione del server di destinazione, non ci sono altri attributi/flag che indicano che è destinato a connessioni sicure. In questo modo Edge tratta le richieste API che arrivano al server di destinazione specifico come richieste HTTP (non sicure). Di conseguenza, Edge non avvierà il processo di handshake SSL con questo server di destinazione.

   Poiché il server di destinazione è configurato per accettare solo richieste HTTPS (SSL) su 443, rifiuterà la richiesta da Edge o chiuderà la connessione. Di conseguenza, viene visualizzato un errore UnexpectedEOFAtTarget nel processore di messaggi. Il processore di messaggi invierà 502 Bad Gateway in risposta al client.

Risoluzione

Assicurati sempre che il server di destinazione sia configurato correttamente in base ai tuoi requisiti.

Per l'esempio illustrato sopra, se vuoi effettuare richieste a un server di destinazione sicuro (HTTPS/SSL), devi includere gli attributi SSLInfo con il flag enabled impostato su true. Anche se è consentito aggiungere gli attributi SSLInfo per un server di destinazione nella definizione stessa dell'endpoint di destinazione, è consigliabile aggiungere gli attributi SSLInfo come parte della definizione del server di destinazione per evitare confusione.

1. Se il servizio di backend richiede una comunicazione SSL unidirezionale:
   1. Devi attivare TLS/SSL nella definizione di TargetServer includendo gli attributi SSLInfo in cui il flag enabled è impostato su true, come mostrato di seguito:

      <TargetServer name="mocktarget">
        <Host>mocktarget.apigee.net</Host>
        <Port>443</Port>
        <IsEnabled>true</IsEnabled>
        <SSLInfo>
            <Enabled>true</Enabled>
        </SSLInfo>
      </TargetServer>
      

   2. Se vuoi convalidare il certificato del server di destinazione in Edge, dobbiamo includere anche l'archivio attendibilità (contenente il certificato del server di destinazione) come mostrato di seguito:

      <TargetServer  name="mocktarget">
          <Host>mocktarget.apigee.net</Host>
          <Port>443</Port>
          <IsEnabled>true</IsEnabled>
          <SSLInfo>
              <Ciphers/>
              <ClientAuthEnabled>false</ClientAuthEnabled>
              <Enabled>true</Enabled>
              <IgnoreValidationErrors>false</IgnoreValidationErrors>
              <Protocols/>
              <TrustStore>mocktarget-truststore</TrustStore>
          </SSLInfo>
      </TargetServer>
      

2. Se il servizio di backend richiede una comunicazione SSL bidirezionale:
   1. Gli attributi SSLInfo con i flag ClientAuthEnabled, Keystore, KeyAlias e Truststore devono essere impostati correttamente, come mostrato di seguito:

      <TargetServer  name="mocktarget">
           <IsEnabled>true</IsEnabled>
           <Host>www.example.com</Host>
           <Port>443</Port>
           <SSLInfo>
               <Ciphers/>
               <ClientAuthEnabled>true</ClientAuthEnabled>
               <Enabled>true</Enabled>
               <IgnoreValidationErrors>false</IgnoreValidationErrors>
               <KeyAlias>keystore-alias</KeyAlias>
               <KeyStore>keystore-name</KeyStore>
               <Protocols/>
               <TrustStore>truststore-name</TrustStore>
           </SSLInfo>
        </TargetServer >
      

Riferimenti

Bilanciamento del carico tra server di backend

Causa: EOFException del server di backend

Il server di backend potrebbe inviare all'improvviso EOF (End of File).

Diagnostica

1. Usa il monitoraggio delle API, lo strumento Trace o i log di accesso NGINX per determinare l'ID messaggio, il codice di errore e l'origine dell'errore per l'errore 502.
2. Controlla i log del processore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log) e cerca per vedere se hai eof unexpected per l'API specifica o se hai il messageid univoco per la richiesta API, puoi cercarlo.

   Esempio di analisi dello stack di eccezioni dal log del processore di messaggi

   "message": "org:myorg env:test api:api-v1 rev:10 messageid:rrt-1-14707-63403485-19 NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() : SSLClientChannel[C:193.35.250.192:8443 Remote host:0.0.0.0:50100]@459069 useCount=6 bytesRead=0 bytesWritten=755 age=40107ms lastIO=12832ms .onExceptionRead exception: {}
   java.io.EOFException: eof unexpected
   at com.apigee.nio.channels.PatternInputChannel.doRead(PatternInputChannel.java:45) ~[nio-1.0.0.jar:na]
   at com.apigee.nio.channels.InputChannel.read(InputChannel.java:103) ~[nio-1.0.0.jar:na]
   at com.apigee.protocol.http.io.MessageReader.onRead(MessageReader.java:79) ~[http-1.0.0.jar:na]
   at com.apigee.nio.channels.DefaultNIOSupport$DefaultIOChannelHandler.onIO(NIOSupport.java:51) [nio-1.0.0.jar:na]
   at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:123) [nio-1.0.0.jar:na]"
   

   Nell'esempio precedente, puoi vedere che si è verificato l'errore java.io.EOFException: eof unexpected mentre il processore di messaggi sta tentando di leggere una risposta dal server di backend. Questa eccezione indica la fine del file (EOF) o è stata raggiunta inaspettatamente la fine del flusso.

   In altre parole, il processore di messaggi ha inviato la richiesta API al server di backend ed era in attesa o lettura della risposta. Tuttavia, il server di backend ha terminato bruscamente la connessione prima che il processore di messaggi ricevesse la risposta o potesse leggere la risposta completa.

3. Controlla i log del server di backend e verifica se sono presenti errori o informazioni che potrebbero aver portato il server di backend a terminare improvvisamente la connessione. Se trovi errori/informazioni, vai a Risoluzione e correggi il problema in modo appropriato nel tuo server di backend.
4. Se non trovi errori o informazioni nel tuo server di backend, raccogli l'output tcpdump nei processori di messaggi:
   1. Se l'host del server di backend ha un singolo indirizzo IP, utilizza il seguente comando:

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

   2. Se l'host del server di backend ha più indirizzi IP, utilizza il seguente comando:

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

      In genere, questo errore è causato dal fatto che il server di backend risponde con [FIN,ACK] non appena il processore di messaggi invia la richiesta al server di backend.

5. Considera il seguente esempio di tcpdump.

   Esempio di tcpdump acquisito quando si è verificato il problema 502 Bad Gateway Error (UnexpectedEOFAtTarget)

   

6. Nell'output TCPDump, noterai la seguente sequenza di eventi:
   1. Nel pacchetto 985, il processore di messaggi invia la richiesta API al server di backend.
   2. Nel pacchetto 986, il server di backend risponde immediatamente con [FIN,ACK].
   3. Nel pacchetto 987, il processore di messaggi risponde con [FIN,ACK] al server di backend.
   4. Alla fine i collegamenti vengono chiusi con [ACK] e [RST] da entrambi i lati.
   5. Poiché il server di backend invia [FIN,ACK], ricevi l'eccezione java.io.EOFException: eof unexpected sul processore di messaggi.
7. Questo può accadere se si verifica un problema di rete a livello di server di backend. Coinvolgi il team delle operazioni di rete per esaminare ulteriormente il problema.

Risoluzione

Risolvi il problema sul server di backend in modo appropriato.

Se il problema persiste e hai bisogno di aiuto per risolvere 502 Bad Gateway Error o se sospetti che si tratti di un problema in Edge, contatta l'assistenza Apigee Edge.

Causa: timeout keep-alive configurato in modo errato

Prima di diagnosticare se questa è la causa degli errori 502, leggi i seguenti concetti.

Connessioni permanenti in Apigee

Per impostazione predefinita, Apigee (e in seguito con lo standard HTTP/1.1) utilizza connessioni permanenti durante la comunicazione con il server di backend di destinazione. Le connessioni permanenti possono aumentare le prestazioni consentendo il riutilizzo di una connessione TCP e (se applicabile) TLS/SSL già stabilita, riducendo in questo modo i costi di latenza. La durata per cui una connessione deve essere persistente viene controllata tramite un timeout keep-alive (keepalive.timeout.millis) della proprietà.

Sia il server di backend che il processore di messaggi Apigee utilizzano i timeout keep-alive per mantenere aperte le connessioni l'una con l'altra. Se non vengono ricevuti dati entro il periodo di timeout keep-alive, il server di backend o il Elaboratore dei messaggi può chiudere la connessione con l'altro.

Per impostazione predefinita, per i proxy API di cui è stato eseguito il deployment in un processore di messaggi in Apigee, il timeout di keep-alive è impostato su 60s, a meno che non venga eseguito l'override. Quando non vengono ricevuti dati per 60s, Apigee chiude la connessione con il server di backend. Il server di backend manterrà anche un timeout keep-alive e, una volta scaduto, il server di backend chiuderà la connessione con il processore di messaggi.

Implicazione di una configurazione errata del timeout di keep-alive

Se Apigee o il server di backend sono configurati con timeout keep-alive errati, si verifica una condizione di gara che fa sì che il server di backend invii un End Of File (FIN) imprevisto in risposta a una richiesta di una risorsa.

Ad esempio, se il timeout di keep-alive è configurato nel proxy API o nel processore di messaggi con un valore maggiore o uguale al timeout del server di backend a monte, può verificarsi la seguente race condizione. In altre parole, se il processore di messaggi non riceve dati finché non si avvicina molto alla soglia del timeout di attività del server di backend, arriva una richiesta che viene inviata al server di backend utilizzando la connessione esistente. Questo può determinare 502 Bad Gateway a causa di un errore EOF imprevisto, come spiegato di seguito:

1. Supponiamo che il timeout di keep-alive impostato sia sul processore di messaggi che sul server di backend sia di 60 secondi e che non sia arrivata alcuna nuova richiesta fino a 59 secondi dopo che la richiesta precedente è stata fornita dallo specifico processore di messaggi.
2. Il processore di messaggi elabora la richiesta pervenuta al 59° secondo utilizzando la connessione esistente (poiché il timeout di keep-alive non è ancora trascorso) e invia la richiesta al server di backend.
3. Tuttavia, prima che la richiesta arrivi al server di backend, la soglia di timeout keep-alive è stata superata sul server di backend.
4. La richiesta del processore di messaggi per una risorsa è in corso, ma il server di backend tenta di chiudere la connessione inviando un pacchetto FIN al processore di messaggi.
5. Mentre il processore di messaggi è in attesa di ricevere i dati, riceve invece l'errore FIN imprevisto e la connessione viene terminata.
6. Ne consegue un Unexpected EOF, che poi restituisce al client un 502 dal processore di messaggi.

In questo caso, abbiamo notato che si è verificato l'errore 502 perché lo stesso valore di timeout keep-alive di 60 secondi è stato configurato sia sul processore di messaggi che sul server di backend. Analogamente, questo problema può verificarsi anche se sul processore di messaggi viene configurato un valore più alto per il timeout keep-alive rispetto al server di backend.

Diagnostica

1. Se sei un utente del cloud pubblico:
   1. Utilizza lo strumento API Monitoring o Trace (come spiegato nella sezione Passaggi comuni di diagnosi) e verifica di disporre di entrambe le seguenti impostazioni:
      • Codice di errore: messaging.adaptors.http.flow.UnexpectedEOFAtTarget
      • Origine errore: target
   2. Vai a Utilizzare tcpdump per ulteriori indagini.
2. Se sei un utente Private Cloud:
   1. Usa lo strumento Traccia o i log di accesso NGINX per determinare l'ID messaggio, il codice di errore e l'origine dell'errore 502.
   2. Cerca l'ID messaggio nel log del processore di messaggi
      (/opt/apigee/var/log/edge-message-processor/logs/system.log).
   3. Vedrai java.io.EOFEXception: eof unexpected come mostrato di seguito:

      2020-11-22 14:42:39,917 org:myorg env:prod api:myproxy rev:1 messageid:myorg-opdk-dc1-node2-17812-56001-1  NIOThread@1 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() :  ClientChannel[Connected: Remote:51.254.225.9:80 Local:10.154.0.61:35326]@12972 useCount=7 bytesRead=0 bytesWritten=159 age=7872ms  lastIO=479ms  isOpen=true.onExceptionRead exception: {}
              java.io.EOFException: eof unexpected
              at com.apigee.nio.channels.PatternInputChannel.doRead(PatternInputChannel.java:45)
              at com.apigee.nio.channels.InputChannel.read(InputChannel.java:103)
              at com.apigee.protocol.http.io.MessageReader.onRead(MessageReader.java:80)
              at com.apigee.nio.channels.DefaultNIOSupport$DefaultIOChannelHandler.onIO(NIOSupport.java:51)
              at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:220)
      

   4. L'errore java.io.EOFException: eof unexpected indica che il processore di messaggi ha ricevuto un messaggio EOF mentre era ancora in attesa di leggere una risposta dal server di backend.
   5. L'attributo useCount=7 nel messaggio di errore riportato sopra indica che il processore di messaggi ha riutilizzato questa connessione circa sette volte e l'attributo bytesWritten=159 indica che il processore di messaggi ha inviato un payload della richiesta di 159 byte al server di backend. Tuttavia, ha ricevuto zero byte quando si è verificato l'errore EOF imprevisto.

   6. Ciò mostra che il Responsabile del trattamento dei messaggi ha riutilizzato la stessa connessione più volte e in questa occasione ha inviato dati, ma poco dopo ha ricevuto un EOF prima della ricezione di qualsiasi dato. Ciò significa che è molto probabile che il timeout di keep-alive del server di backend sia inferiore o uguale a quello impostato nel proxy API.

      Puoi effettuare ulteriori accertamenti con l'aiuto di tcpdump, come spiegato di seguito.

Utilizzo di tcpdump

1. Acquisisci un elemento tcpdump sul server di backend con il seguente comando:

   tcpdump -i any -s 0 host MP_IP_Address -w File_Name
   

2. Analizza gli tcpdump acquisiti:

   Ecco un output di tcpdump di esempio:

   

   Nell'esempio tcpdump sopra, puoi vedere quanto segue:

   1. Nel pacchetto 5992, il server di backend ha ricevuto una richiesta GET.
   2. Nel pacchetto 6064, risponde con 200 OK.
   3. Nel pacchetto 6084, il server di backend ha ricevuto un'altra richiesta GET.
   4. Nel pacchetto 6154, risponde con 200 OK.
   5. Nel pacchetto 6228, il server di backend ha ricevuto una terza richiesta GET.
   6. Questa volta, il server di backend restituisce un FIN, ACK al processore di messaggi (pacchetto 6285) che avvia la chiusura della connessione.

   In questo esempio, la stessa connessione è stata riutilizzata due volte con esito positivo, ma nella terza richiesta il server di backend avvia una chiusura della connessione, mentre il processore di messaggi attende i dati dal server di backend. Questo suggerisce che il timeout di keep-alive del server di backend è molto probabilmente più breve o uguale al valore impostato nel proxy API. Per convalidare ciò, consulta Confronta il timeout di keep-alive su Apigee e sul server di backend.

Confronta il timeout keep-alive su Apigee e sul server di backend

1. Per impostazione predefinita, Apigee utilizza un valore di 60 secondi per la proprietà di timeout keep-alive.

2. Tuttavia, è possibile che tu abbia ignorato il valore predefinito nel proxy API. Puoi verificare controllando la definizione specifica di TargetEndpoint nel proxy API con errori che restituisce 502 errori.

   Esempio di configurazione di TargetEndpoint:

   <TargetEndpoint name="default">
     <HTTPTargetConnection>
       <URL>https://mocktarget.apigee.net/json</URL>
       <Properties>
         <Property name="keepalive.timeout.millis">30000</Property>
       </Properties>
     </HTTPTargetConnection>
   </TargetEndpoint>
   

   Nell'esempio precedente, la proprietà di timeout keep-alive viene sostituita con un valore di 30 secondi (30000 millisecondi).

3. Successivamente, verifica la proprietà di timeout keep-alive configurata sul tuo server di backend. Supponiamo che il tuo server di backend sia configurato con un valore di 25 seconds.
4. Se determini che il valore della proprietà di timeout keep-alive su Apigee è superiore al valore della proprietà di timeout keep-alive sul server di backend come nell'esempio precedente, questa è la causa degli errori 502.

Risoluzione

Assicurati che la proprietà di timeout keep-alive sia sempre inferiore su Apigee (nel componente proxy API e processore di messaggi) rispetto a quella sul server di backend.

1. Determina il valore impostato per il timeout keep-alive sul server di backend.
2. Configura un valore appropriato per la proprietà di timeout keep-alive nel proxy API o nel processore di messaggi, in modo che la proprietà di timeout keep-alive sia inferiore al valore impostato sul server di backend, seguendo i passaggi descritti in Configurare il timeout di keep-alive sui processori di messaggi.

Se il problema persiste, vai alla pagina Devi raccogliere dati diagnostici.

Best practice

Consigliamo vivamente che i componenti downstream abbiano sempre una soglia di timeout di keep-alive inferiore rispetto a quella configurata sui server upstream per evitare questo tipo di condizioni di gara e errori 502. Ogni hop downstream deve essere inferiore a ogni hop upstream. In Apigee Edge, è buona norma utilizzare le seguenti linee guida:

1. Il timeout keep-alive del client deve essere inferiore al timeout keep-alive del router Edge.
2. Il timeout di keep-alive del router Edge deve essere inferiore al timeout di keep-alive del processore di messaggi.
3. Il timeout di keep-alive del processore di messaggi deve essere inferiore al timeout di keep-alive del server di destinazione.
4. Se sono presenti altri hop prima o dopo Apigee, deve essere applicata la stessa regola. Dovresti lasciare sempre la responsabilità del client downstream di chiudere la connessione con l'upstream.

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 502
• File di traccia contenente le richieste con l'errore 502 Bad Gateway - Unexpected EOF
• Se al momento gli errori 502 non si verificano, fornisci il periodo di tempo con le informazioni sul fuso orario in cui si sono verificati 502 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 502 errori
• Bundle del proxy API
• File di traccia contenente le richieste con l'errore 502 Bad Gateway - Unexpected EOF
• Log degli accessi 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 502
• Tcpdumps raccolto sui processori di messaggi, sul server di backend o su entrambi quando si è verificato l'errore