Errore di timeout del gateway non valido (502)

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

Sintomo

L'applicazione client riceve un errore 502 Bad Gateway. Il processore di messaggi restituisce questo errore all'applicazione client quando non riceve risposta da un server di backend.

Messaggio 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":"Bad Gateway",
    "detail":{
        "errorcode":"messaging.adaptors.http.flow.BadGateway"
    }
 }
}

Possibile causa

La possibile causa di questo problema è elencata nella tabella seguente:

Causa Descrizione I passaggi per la risoluzione dei problemi possono essere eseguiti da
Timeout handshake TLS/SSL Si verifica un timeout durante l'handshake TLS/SSL tra il Message Processor e il server di backend. Utenti di Edge Private e Public Cloud

Causa: timeout dell'handshake TLS/SSL

In Apigee Edge, puoi configurare una connessione TLS/SSL al server di backend per abilitare la comunicazione TLS tra l'Edge Message Processor e un server di backend.

Un handshake TLS/SSL prevede più passaggi. Questo errore si verifica in genere quando scade il timeout della procedura di handshake TLS/SSL tra il Message Processor e un server di backend.

Diagnosi

Questa sezione spiega come diagnosticare correttamente un timeout dell'handshake TLS/SSL. Sono elencate le istruzioni per Edge Private Cloud e Public Cloud.

Analisi dell'output della sessione di Trace

I seguenti passaggi spiegano come eseguire una diagnosi preliminare del problema con lo strumento Apigee Edge Trace.

  1. Nell'interfaccia utente di Edge, abilita una sessione di tracciamento per il proxy API interessato.

  2. Se la traccia della richiesta API non riuscita mostra quanto segue, è probabile che si sia verificato un errore di timeout dell'handshake TLS/SSL. La probabile causa dell'errore è che il firewall del server di backend blocca il traffico da Apigee.

    1. Determina se l'errore 502 Gateway non valido si verifica dopo 55 secondi, è il periodo di timeout predefinito impostato nel processore di messaggi. Se noti che l'errore si è verificato dopo 55 secondi, indica che il timeout è stato la causa più probabile del problema.
    2. Determina se l'errore mostra l'errore: messaging.adaptors.http.BadGateway. Anche in questo caso, questo errore di solito indica che si è verificato un timeout.

    3. Se utilizzi Edge Private Cloud, prendi nota del valore del campo X-Apigee.Message-ID nell'output della traccia, come mostrato di seguito. Un privato L'utente cloud può utilizzare questo valore ID per eseguire ulteriori operazioni di risoluzione dei problemi, come spiegato più avanti.

      1. Fai clic sull'icona Dati registrati di Analytics nel percorso della traccia:

      2. Scorri verso il basso e prendi nota del valore del campo chiamato X-Apigee.Message-ID.

Per verificare che il timeout dell'handshake TLS/SSL sia stata la causa dell'errore, segui i passaggi descritti nelle sezioni seguenti a seconda che tu stia utilizzando Public Cloud o Private Cloud.

Ulteriori passaggi di diagnostica solo per gli utenti di Edge Private Cloud

Se utilizzi il cloud privato Apigee Edge, puoi eseguire questi passaggi per verificare la causa dell'errore di handshake. In questo passaggio, esamini il file di log di Message Processor per trovare informazioni pertinenti. Se utilizzi Edge Public Cloud, puoi saltare questa sezione e andare a Ulteriori passaggi di diagnostica per gli utenti di cloud privati e pubblici.

  1. Verifica se riesci a connetterti allo specifico server di backend direttamente da ciascuno dei processori di messaggi utilizzando il comando telnet:

    1. Se il server di backend risolve in un singolo indirizzo IP, utilizza questo comando:

      telnet BackendServer-IPaddress 443

    2. Se il server di backend si risolve in più indirizzi IP, utilizza il nome host del server di backend nel comando telnet come mostrato di seguito:

      telnet BackendServer-HostName 443

    Se riesci a connetterti al server di backend senza errori, vai al passaggio successivo.

    Se il comando telnet non va a buon fine, devi collaborare con il team di rete per controllare la connettività tra l'elaboratore dei messaggi e il server di backend.

  2. Controlla il file di log del processore di messaggi per verificare se è stato rilevato un errore di handshake. Apri il file:

    /opt/apigee/var/log/edge-message-processor/system.log

    e cerca l'ID messaggio univoco (il valore di X-Apigee.Message-ID che trovato nel file di traccia). Determina se visualizzi un messaggio di errore di handshake associato con l'ID messaggio come mostrato di seguito:

    org:xxx env:xxx api:xxx rev:x messageid:<MESSAGE_ID> NIOThread@1 ERROR HTTP.CLIENT -
HTTPClient$Context.handshakeTimeout() : SSLClientChannel[Connected: Remote:X.X.X.X:443
Local:X.X.X.X]@739028 useCount=1 bytesRead=0 bytesWritten=0 age=55221ms lastIO=55221ms
isOpen=true handshake timeout

Se viene visualizzato questo errore nel file di log del processore di messaggi, continua con ulteriori accertamenti. Vai a Ulteriori passaggi di diagnostica per gli utenti di Edge Private e Public Cloud.

Se non vedi il messaggio di handshake nel file di log, vai a Devi raccogliere informazioni di diagnostica.

Ulteriori passaggi di diagnostica per gli utenti di Edge Private e Public Cloud

Per individuare ulteriormente il problema, puoi utilizzare lo strumento tcpdump per analizzare i pacchetti TCP/IP e verificare se si è verificato un timeout durante l'handshake TLS/SSL.

  1. Se sei un utente di Private Cloud, puoi acquisire i pacchetti TCP/IP sul server di backend o sul Message Processor. Preferibilmente, acquisiscile nel backend poiché i pacchetti sono stati decriptati sul server di backend.
  2. Se sei un utente del cloud pubblico, non hai accesso al messaggio Responsabile; tuttavia, l'acquisizione dei pacchetti TCP/IP sul server di backend a individuare un problema.

  3. Dopo aver deciso dove acquisire i pacchetti TCP/IP, utilizza il seguente comando tcpdump per acquisirli.

    tcpdump -i any -s 0 host <IP address> -w <File name>

    • Se stai trasferendo i pacchetti TCP/IP sul server di backend, utilizza il protocollo Indirizzo IP del processore di messaggi nel comando tcpdump. Per assistenza sull'utilizzo del per esaminare il traffico del server di backend, consulta tcpdump.

    • Se ricevi i pacchetti TCP/IP nell'Elaboratore messaggi, utilizza l'indirizzo IP pubblico del server di backend nel comando tcpdump. Per assistenza sull'utilizzo del comando per esaminare il traffico del Message Processor, consulta tcpdump.

    • Se sono presenti più indirizzi IP per il server di backend o il processore di messaggi: devi provare a usare un altro comando tcpdump. Per ulteriori informazioni su questo strumento e su altre varianti di questo comando, consulta tcpdump.

  4. Analizza i pacchetti TCP/IP utilizzando lo strumento Wireshark o uno strumento simile. Il seguente screenshot mostra i pacchetti TCP/IP in Wireshark.

  5. Nota nell'output di Wireshark che l'handshake TCP a tre vie viene completato nei primi 3 pacchetti.

  6. Il Message Processor invia quindi il messaggio "Client Hello" nel pacchetto 4.

  7. Poiché non viene ricevuto alcun conferma dal server di backend, il Message Processor ritrasmette il messaggio "Client Hello" più volte nei pacchetti 5, 6 e 7 dopo aver atteso un intervallo di tempo predefinito.

  8. Quando il Message Processor non riceve alcun ACK dopo tre tentativi, invia il messaggio FIN, ACK al server di backend per indicare che sta chiudendo la connessione.

  9. Come mostrato nella sessione di Wireshark di esempio, la connessione è riuscita (passaggio 1), tuttavia, l'handshake SSL è scaduto perché il backend server non ha mai risposto.

Se hai eseguito i passaggi per la risoluzione dei problemi di questo playbook e hai stabilito che che ha causato l'errore di handshake TLS/SSL, vai alla sezione Risoluzione.

Utilizzare il monitoraggio delle API per identificare un problema

API Monitoring ti consente di isolare rapidamente le aree problematiche per diagnosticare i problemi di errori, prestazioni e latenza e la relativa origine, ad esempio app per sviluppatori, proxy API, target di backend o la piattaforma API.

Esegui uno scenario di esempio che mostra come risolvere i problemi 5xx relativi alle API utilizzando il monitoraggio delle API. Ad esempio, potresti voler configurare un avviso per ricevere una notifica quando il numero di errori messaging.adaptors.http.BadGateway supera una determinata soglia.

Risoluzione

In genere i timeout dell'handshake SSL si verificano a causa di limitazioni del firewall sul server di backend che bloccano il traffico da Apigee Edge. Se hai seguito i passaggi di diagnostica e hai stabilito che la causa dell'errore di handshake è un timeout, devi contattare il team di rete per identificare la causa e correggere le limitazioni del firewall.

Tieni presente che le restrizioni del firewall potrebbero essere imposte a diversi livelli di rete. È importante assicurarsi che le limitazioni relative agli IP dei processori di messaggi vengano rimosse a tutti i livelli di rete per garantire un flusso di traffico regolare tra Apigee Edge e il server di backend.

Se non ci sono limitazioni del firewall e/o il problema persiste, vai a Devi raccogliere informazioni di diagnostica.

È necessario raccogliere informazioni di diagnostica

Se il problema persiste anche dopo aver seguito le istruzioni riportate sopra, raccogli le seguenti informazioni di diagnostica. Contatta e condividili con l'assistenza Apigee Edge:

  1. Se sei un utente del cloud pubblico, fornisci le seguenti informazioni:
    1. Nome dell'organizzazione
    2. Nome ambiente
    3. Nome proxy API
    4. Completa il comando curl per riprodurre l'errore
    5. File di traccia che mostra l'errore
    6. Pacchetti TCP/IP acquisiti sul server di backend
  2. Se sei un utente di Private Cloud, fornisci le seguenti informazioni:
    1. Messaggio di errore completo osservato
    2. Bundle proxy API
    3. File di traccia che mostra l'errore
    4. Log del processore di messaggi /opt/apigee/var/log/edge-message-processor/logs/system.log
    5. Pacchetti TCP/IP acquisiti sul server di backend o sul Message Processor.
  3. Dettagli sulle sezioni di questo Playbook che hai provato ed eventuali altre informazioni che ci aiuteranno a risolvere rapidamente il problema.