EOF imprevista del gateway non valido (502)

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

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 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:

Passaggi di diagnostica comuni

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

• Monitoraggio delle API
• Strumento Trace
• Log di accesso NGINX

Causa: server di destinazione configurato in modo errato

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

Diagnosi

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

      In questo caso, è molto probabile che il problema sia causato da una configurazione errata del server di destinazione.

4. Recupera la definizione del server di destinazione utilizzando la chiamata API di gestione Edge:
   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 di 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 una delle tipiche configurazioni errate, spiegata come segue:

   Supponiamo che il server di destinazione mocktarget.apigee.net sia configurato per accettare connessioni sicure (HTTPS) sulla porta 443. Tuttavia, se esamini la definizione del server di destinazione, non sono presenti altri attributi/flag che indicano che è destinato a connessioni sicure. In questo modo, Edge tratta le richieste API inviate al server di destinazione specifico come richieste HTTP (non sicure). Pertanto, 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 come 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), <x0A> devi includere gli attributi SSLInfo con il flag enabled impostato su true. Sebbene sia consentito aggiungere gli attributi SSLInfo per un server di destinazione nella definizione 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 la comunicazione SSL unidirezionale:
   1. Devi attivare TLS/SSL nella definizione 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 anche includere il truststore (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 la comunicazione SSL bidirezionale, allora:
   1. Devi avere attributi SSLInfo con i flag ClientAuthEnabled, Keystore, KeyAlias e Truststore impostati in modo appropriato, 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 dal server di backend

Il server di backend potrebbe inviare EOF (End of File) bruscamente.

Diagnosi

1. Utilizza API Monitoring, lo strumento Trace o i log di accesso NGINX per determinare l'ID messaggio, il codice di errore e l'origine dell'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 messageid univoco per la richiesta API, quindi puoi cercarlo.

   Esempio di analisi dello stack delle 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 notare che l'errore java.io.EOFException: eof unexpected si è verificato mentre il processore di messaggi tenta di leggere una risposta dal server di backend. Questa eccezione indica che la fine del file (EOF) o dello stream è stata raggiunta in modo imprevisto.

   ovvero il processore di messaggi ha inviato la richiesta API al server di backend e stava aspettando o leggendo la risposta. Tuttavia, il server di backend ha interrotto 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 la presenza di errori o informazioni che potrebbero aver portato il server di backend a interrompere bruscamente la connessione. Se trovi errori/informazioni, vai a Risoluzione e correggi il problema in modo appropriato nel server di backend.
4. Se non trovi errori o informazioni nel server di backend, raccogli l'output tcpdump sui Message Processor:
   1. Se l'host del server di backend ha un solo 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.

   Campione tcpdump acquisito quando si è verificato 502 Bad Gateway Error (UnexpectedEOFAtTarget)

   

6. Dall'output di TCPDump, noti 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 le connessioni vengono chiuse con [ACK] e [RST] da entrambe le parti.
   5. Poiché il server di backend invia [FIN,ACK], ricevi l'eccezione java.io.EOFException: eof unexpected sul processore di messaggi.
7. Ciò può verificarsi se si verifica un problema di rete nel server di backend. Contatta il team operativo della tua rete per ulteriori indagini.

Risoluzione

Risolvi il problema sul server di backend in modo appropriato.

Se il problema persiste e hai bisogno di assistenza per la risoluzione dei problemi di 502 Bad Gateway Error o se sospetti che si tratti di un problema all'interno di 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 (e in conformità allo standard HTTP/1.1), Apigee utilizza connessioni permanenti quando comunica con il server di backend di destinazione. Le connessioni permanenti possono migliorare le prestazioni consentendo il riutilizzo di una connessione TCP e (se applicabile) TLS/SSL già stabilita, il che riduce gli overhead di latenza. La durata per cui una connessione deve essere mantenuta è controllata tramite una proprietà keep alive timeout (keepalive.timeout.millis).

Sia il server di backend sia Apigee processore di messaggi utilizzano i timeout keep-alive per mantenere aperte le connessioni tra loro. Una volta che non vengono ricevuti dati entro il timeout keep-alive, il server di backend o il processore di messaggi può chiudere la connessione con l'altro.

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

Implicazioni di una configurazione errata del timeout keep-alive

Se Apigee o il server di backend sono configurati con timeout keep-alive errati, si verifica una race condition 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 keep-alive è configurato all'interno del proxy API o del processore di messaggi con un valore maggiore o uguale al timeout del server di backend upstream, può verificarsi la seguente race condition. ovvero, se il processore di messaggi non riceve dati fino a quando non si avvicina molto alla soglia del timeout keep-alive del server di backend, viene inviata una richiesta al server di backend utilizzando la connessione esistente. Ciò può comportare 502 Bad Gateway a causa dell'errore Unexpected EOF, come spiegato di seguito:

1. Supponiamo che il timeout 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 gestita dal processore di messaggi specifico.
2. Il processore di messaggi procede all'elaborazione della richiesta arrivata al 59° secondo utilizzando la connessione esistente (poiché il timeout 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 di una risorsa da parte del processore di messaggi è 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'FIN imprevisto e la connessione viene terminata.
6. Il risultato è un Unexpected EOF e successivamente un 502 viene restituito al client dal processore di messaggi.

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

Diagnosi

1. Se sei un utente del cloud pubblico:
   1. Utilizza lo strumento API Monitoring o Trace (come spiegato in Passaggi comuni per la diagnosi) e verifica di aver configurato entrambe le seguenti impostazioni:
      • Codice di errore: messaging.adaptors.http.flow.UnexpectedEOFAtTarget
      • Origine del guasto: target
   2. Per ulteriori accertamenti, consulta Utilizzo di tcpdump.
2. Se sei un utente di Private Cloud:
   1. Utilizza lo strumento di tracciamento 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 EOF mentre era ancora in attesa di leggere una risposta dal server di backend.
   5. L'attributo useCount=7 nel messaggio di errore precedente indica che il processore di messaggi aveva riutilizzato questa connessione circa sette volte e l'attributo bytesWritten=159 indica che il processore di messaggi aveva inviato il payload della richiesta di 159 byte al server di backend. Tuttavia, ha ricevuto zero byte quando si è verificato l'errore imprevisto EOF.

   6. Ciò dimostra che il processore di messaggi aveva riutilizzato più volte la stessa connessione e in questa occasione ha inviato dati, ma poco dopo ha ricevuto un EOF prima di ricevere dati. Ciò significa che esiste un'alta probabilità che il timeout keep-alive del server di backend sia inferiore o uguale a quello impostato nel proxy API.

      Puoi approfondire l'argomento con l'aiuto di tcpdump, come spiegato di seguito.

Utilizzo di tcpdump

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

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

2. Analizza i tcpdump acquisiti:

   Ecco un output di tcpdump di esempio:

   

   Nell'esempio tcpdump riportato 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 correttamente, ma alla terza richiesta, il server di backend avvia la chiusura della connessione, mentre il processore di messaggi è in attesa dei dati dal server di backend. Ciò suggerisce che il timeout keep-alive del server di backend è molto probabilmente inferiore o uguale al valore impostato nel proxy API. Per convalidare questo, vedi Confrontare il timeout keep-alive su Apigee e sul server di backend.

Confrontare 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 sostituito il valore predefinito nel proxy API. Puoi verificarlo controllando la definizione specifica di TargetEndpoint nel proxy API non riuscito che genera errori 502.

   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. Dopodiché, controlla la proprietà di timeout keep-alive configurata sul server di backend. Supponiamo che il 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, allora questa è la causa degli errori 502.

Risoluzione

Assicurati che la proprietà di timeout keep-alive sia sempre inferiore su Apigee (nel proxy API e nel componente del 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 Configurazione del timeout keep-alive sui processori di messaggi.

Se il problema persiste, vai a Informazioni di diagnostica da raccogliere.

Best practice

È vivamente consigliato che i componenti downstream abbiano sempre una soglia di timeout keep-alive inferiore rispetto a quella configurata sui server upstream per evitare questo tipo di race condition ed 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 keepalive del client deve essere inferiore al timeout keepalive del router di Edge.
2. Il timeout keep-alive del router Edge deve essere inferiore al timeout keep-alive del processore di messaggi.
3. Il timeout keep-alive del processore di messaggi deve essere inferiore al timeout keep-alive del server di destinazione.
4. Se hai altri hop prima o dopo Apigee, deve essere applicata la stessa regola. Dovresti sempre lasciare al client downstream la responsabilità di chiudere la connessione con l'upstream.

Deve raccogliere informazioni diagnostiche

Se il problema persiste anche dopo aver seguito le istruzioni riportate sopra, raccogli le seguenti informazioni diagnostiche e poi contatta l'assistenza Apigee Edge.

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

• Nome organizzazione
• Nome ambiente
• Nome del proxy API
• Completa il comando curl per riprodurre l'errore 502
• File di traccia contenente le richieste con errore 502 Bad Gateway - Unexpected EOF
• Se gli errori 502 non si verificano attualmente, fornisci il periodo di tempo con le informazioni sul fuso orario in cui si sono verificati gli errori 502 in passato.

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

• Messaggio di errore completo osservato per le richieste non riuscite
• Nome dell'organizzazione, dell'ambiente e del proxy API per cui stai osservando errori 502
• Bundle proxy API
• File di traccia contenente le richieste con errore 502 Bad Gateway - Unexpected EOF
• 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 502
• Tcpdumps raccolti sui processori di messaggi o sul server di backend oppure su entrambi quando si è verificato l'errore