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 Message Processor restituisce questo errore all'applicazione client quando non riceve una risposta da un server di backend.

Messaggio 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":"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 del handshake TLS/SSL Si verifica un timeout durante l'handshake TLS/SSL tra il processore di messaggi 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.

Esaminare l'output della sessione di traccia

I passaggi riportati di seguito spiegano come eseguire una diagnosi preliminare del problema utilizzando 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 Bad Gateway si verifica dopo 55 secondi, che è il periodo di timeout predefinito impostato nel Message Processor. Se viene visualizzato l'errore dopo 55 secondi, significa che un timeout è stato la probabile causa del problema.
    2. Determina se l'errore mostra l'errore: messaging.adaptors.http.BadGateway. Anche in questo caso, di solito questo errore 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 utente di Private Cloud può utilizzare questo valore ID per eseguire ulteriori operazioni di risoluzione dei problemi, come spiegato di seguito.

      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.

Passaggi di diagnostica aggiuntivi solo per gli utenti di Edge Private Cloud

Se utilizzi Apigee Edge Private Cloud, puoi eseguire i seguenti passaggi per verificare la causa dell'errore di handshake. In questo passaggio, ispezionirai il file di log del processore di messaggi per trovare le informazioni pertinenti. Se utilizzi il cloud pubblico perimetrale, puoi saltare questa sezione e andare a Ulteriori passaggi diagnostici per gli utenti del cloud privato e pubblico.

  1. Verifica se riesci a connetterti al server di backend specifico 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 verificare la connettività tra l'elaboratore dei messaggi e il server di backend.

  2. Controlla il file di log del Message Processor per verificare la presenza di prove di 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 trovato nel file di traccia). Determina se viene visualizzato un messaggio di errore di handshake associato all'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 dell'elaboratore dei messaggi, continua la ricerca. Vai a Ulteriori passaggi di diagnostica per gli utenti Edge di cloud privato e pubblico.

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 processore di messaggi. È preferibile acquisirli sul server di backend, perché i pacchetti vengono decriptati sul server di backend.
  2. Se sei un utente di Public Cloud, non hai accesso a Message Processor. Tuttavia, l'acquisizione dei pacchetti TCP/IP sul server di backend può aiutarti 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 ricevi i pacchetti TCP/IP sul server di backend, utilizza l'indirizzo IP pubblico dell'Elaboratore di messaggi nel comando tcpdump. Per assistenza sull'utilizzo del comando per esaminare il traffico del server di backend, consulta tcpdump.

    • Se ricevi i pacchetti TCP/IP nell'Elaboratore di 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 esistono più indirizzi IP per il server di backend/il processore di messaggi, devi provare un altro utilizzo del comando tcpdump. Per ulteriori informazioni su questo strumento e per altre varianti di questo comando, consulta la pagina tcpdump.

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

  5. Nell'output di Wireshark, nota che la stretta di mano TCP a tre vie viene completata correttamente nei primi 3 pacchetti.

  6. Il processore di messaggi invia quindi il messaggio "Client Hello" nel pacchetto 4.

  7. In assenza di conferma da parte del server di backend, il processore di messaggi ritrasmette più volte il messaggio "Client Hello" 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 nell'esempio di sessione Wireshark, la connessione al backend è riuscita (passaggio 1), ma l'handshake SSL ha superato il tempo di attesa perché il server di backend non ha mai risposto.

Se hai eseguito i passaggi per la risoluzione dei problemi descritti in questo playbook e hai stabilito che un timeout 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 delle restrizioni del firewall sul server di backend che blocca 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 limitazioni 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 del proxy API
    4. Comando curl completo 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 Message Processor /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 altri approfondimenti che ci aiuteranno a risolvere rapidamente il problema.