EOF imprevista del gateway non valido (502)

Stai visualizzando la documentazione di Apigee Edge.
Vai alla sezione Documentazione di Apigee X. Informazioni

Sintomo

L'applicazione client riceve un codice di stato HTTP di 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 dall' di backend che devono effettivamente soddisfare la richiesta.

Messaggi di errore

L'applicazione client riceve il seguente codice di risposta:

HTTP/1.1 502 Bad Gateway

Potresti inoltre 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 è Unexpected EOF che può essere causato dai seguenti motivi:

Causa	Dettagli	Passaggi indicati per
Server di destinazione configurato in modo errato	Il server di destinazione non è configurato correttamente per supportare le connessioni TLS/SSL.	Utenti perimetrali di cloud pubblici e privati
EOFEccezione dal server di backend	Il server di backend potrebbe inviare EOF bruscamente.	Solo utenti Edge Private Cloud
Timeout keepalive configurato in modo errato	Mantieni i timeout attivi configurati in modo errato su Apigee e sul server di backend.	Utenti perimetrali di cloud pubblici e privati

Passaggi diagnostici comuni

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

• Monitoraggio delle API
• Strumento Tracce
• 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. Utilizzare il monitoraggio delle API, lo strumento Trace oppure Log di accesso NGINX per determinare l'ID messaggio. e origine per l'errore 502.
2. Abilita la traccia nella UI 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 viene avviata la richiesta del flusso target.
   2. error.class mostra messaging.adaptors.http.UnexpectedEOF.

      In tal caso, è molto probabile che il problema sia causato da un server di destinazione errato configurazione.

4. Ottieni 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 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 di TargetServer illustrata è un esempio per una delle definizioni tipiche e gli errori di configurazione, spiegati come segue:

   Supponiamo che il server di destinazione mocktarget.apigee.net sia configurato per accettare connessioni protette (HTTPS) sulla porta 443. Tuttavia, se si considerano definizione del server di destinazione, non esistono altri attributi/flag che indichino pensato per ottenere connessioni sicure. In questo modo Edge tratti le richieste API che vengono indirizzate un server di destinazione specifico come richieste HTTP (non sicure). Quindi Edge non avvia il processo di handshake SSL con questo server di destinazione.

   Poiché il server di destinazione è configurato per accettare solo richieste HTTPS (SSL) su 443, rifiuta la richiesta da Edge o chiudi la connessione. Il risultato è un UnexpectedEOFAtTarget errore sul 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.

Nell'esempio illustrato sopra, se vuoi effettuare richieste a una destinazione sicura (HTTPS/SSL) devi includere gli attributi SSLInfo con il flag enabled impostato a true. È consentito aggiungere attributi SSLInfo per un server di destinazione nel server di destinazione. della definizione dell'endpoint stesso, si consiglia di aggiungere gli attributi SSLInfo come parte del target la definizione del server per evitare confusione.

1. Se il servizio di backend richiede la comunicazione SSL unidirezionale:
   .
   1. Devi attivare il protocollo TLS/SSL nella definizione di TargetServer includendo il valore 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 includi 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 la comunicazione SSL bidirezionale:
   .
   1. Devi disporre degli attributi SSLInfo con ClientAuthEnabled, Keystore, KeyAlias e Truststore flag 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 i server di backend

Causa: eccezione EOF del server di backend

Il server di backend potrebbe inviare improvvisamente (fine del file).

Diagnosi

1. Utilizzare il monitoraggio delle API, lo strumento Trace oppure Log di accesso NGINX per determinare l'ID messaggio. e origine per l'errore 502.
2. Controllare 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 l'unico messageid per l'API richiesta, puoi cercarla.

   Esempio di analisi dello stack di eccezioni nel 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 si è verificato l'errore java.io.EOFException: eof unexpected mentre il processore di messaggi tentava di leggere una risposta da il server di backend. Questa eccezione indica la fine del file (EOF) o la fine del flusso raggiunto in modo imprevisto.

   In altre parole, il processore di messaggi ha inviato la richiesta API al server di backend ed era in attesa o leggere la 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 hanno portato il server di backend a interrompere bruscamente la connessione. Se trovi errori/informazioni, poi 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 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.

   Esempio di tcpdump rilevato quando 502 Bad Gateway Error (UnexpectedEOFAtTarget) si è verificato

   

6. Dall'output TCPDump, puoi notare 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 backend server web.
   4. Alla fine le connessioni vengono chiuse con [ACK] e [RST] da entrambi i lati.
   5. Poiché il server di backend invia [FIN,ACK], ricevi l'eccezione Eccezione java.io.EOFException: eof unexpected per il messaggio Processore.
7. Ciò può accadere se c'è un problema di rete a livello di server di backend. Coinvolgi la tua rete operativo per esaminare ulteriormente il problema.

Risoluzione

Risolvi correttamente il problema sul server di backend.

Se il problema persiste e hai bisogno di assistenza per risolvere eventuali problemi con 502 Bad Gateway Error o tu 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 attentamente i seguenti concetti.

Connessioni permanenti in Apigee

Apigee per impostazione predefinita (e successivamente 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, riduce i costi di latenza. È controllata la durata della permanenza di una connessione attraverso un keep alive timeout (keepalive.timeout.millis) della proprietà.

Sia il server di backend che il processore di messaggi Apigee utilizzano i timeout keep-alive per mantenere connessioni aperte l'una con l'altra. Una volta che non sono stati ricevuti dati entro il timeout keep-alive , il server di backend o il processore di messaggi possono 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 di keep alive impostato su 60s se non viene eseguito l'override. Quando non vengono ricevuti dati per 60s, Apigee la connessione con il server di backend. Il server di backend manterrà inoltre un timeout di keep alive, e, alla scadenza, il server di backend chiuderà la connessione con il processore di messaggi.

Implicazione di una configurazione errata del timeout keep-alive

Se Apigee o il server di backend sono configurati con timeout di mantenimento attivi errati, provoca 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 keep-alive è configurato nel proxy API o nel campo un processore con un valore maggiore o uguale al timeout del server di backend upstream, quindi può verificarsi la seguente condizione di gara. Vale a dire, se il processore di messaggi non riceve i dati fino a molto vicino alla soglia del server di backend manteni il timeout in tempo reale, quindi viene inviata passa attraverso e viene inviato 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 keepalive impostato sia sul processore di messaggi e sul server di backend è di 60 secondi e nessun nuovo è arrivata fino a 59 secondi dopo che la richiesta precedente era stata fornita dal Processore di messaggi.
2. Il processore di messaggi procede ed elabora la richiesta pervenuta al 59° secondo utilizzando la connessione esistente (perché il timeout keep alive non è ancora trascorso) e invia richiesta al server di backend.
3. Tuttavia, prima che la richiesta arrivi al server di backend, il 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 messaggio Processore.
5. Mentre il processore di messaggi attende che i dati vengano ricevuti, riceve FIN imprevisto e la connessione viene terminata.
6. Questo determina un Unexpected EOF e successivamente un 502 restituito al client dal processore di messaggi.

In questo caso, abbiamo notato che si è verificato l'errore 502 a causa dello stesso 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 viene configurato un valore più alto per il timeout keepalive sul rispetto al server di backend.

Diagnosi

1. Se sei un utente del cloud pubblico:
   .
   1. Usare lo strumento Monitoraggio delle API o Trace (come spiegato in passaggi di diagnosi comuni) e verifica di soddisfare entrambi i seguenti requisiti: 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 di Private Cloud:
   .
   1. Usa lo strumento Tracce oppure Log di accesso NGINX per determinare l'ID messaggio. e origine per l'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 un la risposta desiderata dal server di backend.
   5. L'attributo useCount=7 nel messaggio di errore riportato sopra indica che la proprietà Il processore di messaggi ha riutilizzato questa connessione circa sette volte e l'attributo bytesWritten=159 indica che il processore di messaggi ha inviato la richiesta payload di 159 byte al server di backend. Tuttavia, ha ricevuto zero byte quando si è verificato l'evento EOF imprevisto.

   6. Questo dimostra che il processore di 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 dati. Ciò significa che c'è un'alta probabilità che il backend il timeout keepalive del server è più breve 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 valore tcpdump sul server di backend con il seguente comando:

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

2. Analizza il tcpdump acquisito:

   Ecco un output di esempio tcpdump:

   

   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 nella terza richiesta il server di backend avvia una chiusura della connessione, mentre il processore di messaggi in attesa dei dati dal server di backend. Questo suggerisce che i dati del server Molto probabilmente il timeout attivo è più breve o uguale al valore impostato nel proxy API. Per la convalida vedi Confrontare il timeout keep alive su Apigee e sul server di backend.

Confronta il timeout keepalive 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 con errore 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à del timeout keep alive viene ignorata con un valore di 30 secondi (30000 millisecondi).

3. Quindi, controlla la proprietà del timeout keep-alive configurata sul server di backend. Diciamo il tuo server di backend è configurato con il valore 25 seconds.
4. Se si determina che il valore della proprietà di timeout keep alive su Apigee è più elevato del valore della proprietà di timeout keep alive sul server di backend come sopra questa è la causa degli errori di tipo 502.

Risoluzione

Assicurati che la proprietà di timeout keepalive sia sempre più bassa su Apigee (nel proxy API Message Processor) rispetto a quello sul server di backend.

1. Determina il valore impostato per il timeout keepalive sul server di backend.
2. Configurare un valore appropriato per la proprietà di timeout keep alive nel proxy API oppure Processore di messaggi, in modo che la proprietà di timeout keep alive sia inferiore al valore impostato nella utilizzando i passaggi descritti in Configurazione del timeout keepalive sui processori di messaggi.

Se il problema persiste, vai a Devi raccogliere dati diagnostici.

Best practice

È vivamente consigliato che i componenti downstream abbiano sempre un timeout keep-alive inferiore soglia minima rispetto a quella configurata sui server upstream per evitare questo tipo di condizioni di gara e 502 errore. Ogni hop downstream deve essere inferiore a ogni hop upstream. In Apigee Edge, ti consigliamo di utilizzare le seguenti linee guida:

1. Il timeout di keep-alive del client deve essere inferiore al timeout di keep-alive del router Edge.
2. Il timeout di keep-alive del router perimetrale deve essere inferiore al timeout di keep-alive del processore di messaggi.
3. Il timeout keep-alive del processore di messaggi deve essere inferiore al timeout di keep-alive del server di destinazione.
4. Per qualsiasi altro hop davanti o dietro ad Apigee, deve essere applicata la stessa regola. Dovresti sempre lasciare che sia il client downstream a chiudere connessione con l'upstream.

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 502
• File di traccia contenente le richieste con 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 quando si sono verificati 502 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. 502 errore
• 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 si è verificato