502 Erro de tempo limite de gateway inválido

Você está vendo a documentação do Apigee Edge.
Acesse a documentação da Apigee X. info

Sintoma

O aplicativo cliente recebe um erro 502 Bad Gateway. O processador de mensagens retorna esse erro ao aplicativo cliente quando ele não recebe uma resposta de um servidor de back-end.

Mensagem de erro

O aplicativo cliente recebe o seguinte código de resposta:

HTTP/1.1 502 Bad Gateway

Além disso, você pode observar a seguinte mensagem de erro:

{
 "fault": {
    "faultstring":"Bad Gateway",
    "detail":{
        "errorcode":"messaging.adaptors.http.flow.BadGateway"
    }
 }
}

Possível causa

A possível causa do problema está listada na tabela a seguir:

Causa Descrição As etapas de solução de problemas podem ser executadas
Tempo limite de handshake de TLS/SSL Um tempo limite ocorre durante o handshake TLS/SSL entre o processador de mensagens e o servidor de back-end. Usuários da nuvem pública e privada do Edge

Causa: Timeout do handshake TLS/SSL

No Apigee Edge, é possível configurar uma conexão TLS/SSL com o servidor de back-end para ativar a comunicação TLS entre o processador de mensagens do Edge e um servidor de back-end.

Um handshake TLS/SSL envolve várias etapas. Esse erro normalmente acontece quando o handshake de TLS/SSL entre o processador de mensagens e um servidor de back-end expira.

Diagnóstico

Esta seção explica como diagnosticar corretamente um tempo limite de handshake TLS/SSL. As instruções para a nuvem privada e pública do Edge são listadas.

Investigar a saída da sessão de rastreamento

As etapas a seguir explicam como fazer um diagnóstico preliminar do problema usando a ferramenta Apigee Edge Trace.

  1. Na interface do Edge, ative uma sessão de rastreamento para o proxy de API afetado.

  2. Se o rastreamento da solicitação de API com falha mostrar o seguinte, é provável que tenha ocorrido um erro de tempo limite de handshake TLS/SSL. A causa provável do erro é que o firewall do servidor de back-end está bloqueando o tráfego da Apigee.

    1. Determine se o erro 502 Bad Gateway ocorre após 55 segundos, que é o tempo limite padrão definido no processador de mensagens. Se você notar que o erro ocorreu após 55 segundos, isso indica que um tempo limite foi a causa provável do problema.
    2. Determine se o erro mostra a falha: messaging.adaptors.http.BadGateway. Novamente, esse erro geralmente indica que o tempo limite foi atingido.

    3. Se você estiver na Edge Private Cloud, observe o valor do campo X-Apigee.Message-ID na saída do rastreamento, conforme mostrado abaixo. Um usuário do Private Cloud pode usar esse valor de ID para resolver outros problemas, conforme explicado mais adiante.

      1. Clique no ícone Dados do Analytics registrados no caminho do trace:

      2. Role para baixo e anote o valor do campo chamado X-Apigee.Message-ID.

Para confirmar que o tempo limite de handshake TLS/SSL foi a causa do erro, siga as etapas nas seções a seguir, dependendo se você está na nuvem pública ou privada.

Etapas de diagnóstico adicionais somente para usuários da nuvem privada do Edge

Se você estiver na nuvem privada do Apigee Edge, siga as etapas abaixo para verificar a causa do erro de handshake. Nesta etapa, você vai inspecionar o arquivo de registro do processador de mensagens em busca de informações relevantes. Se você estiver na nuvem pública do Edge, pule esta seção e acesse Outras etapas de diagnóstico para usuários de nuvens públicas e privadas.

  1. Verifique se você consegue se conectar ao servidor de back-end específico diretamente de cada um dos processadores de mensagens usando o comando telnet:

    1. Se o servidor de back-end for resolvido para um único endereço IP, use este comando:

      telnet BackendServer-IPaddress 443

    2. Se o servidor de back-end for resolvido para vários endereços IP, use o nome do host do servidor de back-end no comando telnet, conforme mostrado abaixo:

      telnet BackendServer-HostName 443

    Se você conseguir se conectar ao servidor de back-end sem erros, vá para a próxima etapa.

    Se o comando telnet falhar, você vai precisar trabalhar com a equipe de rede para verificar a conectividade entre o processador de mensagens e o servidor de back-end.

  2. Verifique o arquivo de registro do processador de mensagens para encontrar evidências de uma falha de handshake. Abra o arquivo:

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

    e procure o ID da mensagem exclusivo (o valor de X-Apigee.Message-ID encontrado no arquivo de rastreamento). Determine se você vê uma mensagem de erro de handshake associada ao ID da mensagem, conforme mostrado abaixo:

    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 esse erro aparecer no arquivo de registro do processador de mensagens, continue a investigação. Acesse Outras etapas de diagnóstico para usuários da nuvem pública e privada do Edge.

Se a mensagem de handshake não aparecer no arquivo de registro, acesse Precisa de informações de diagnóstico

Outras etapas de diagnóstico para usuários da nuvem pública e privada do Edge

Para identificar ainda mais o problema, use a ferramenta tcpdump para analisar os pacotes TCP/IP e confirmar se o tempo limite ocorreu durante o handshake de TLS/SSL.

  1. Se você for um usuário da nuvem particular, poderá capturar os pacotes TCP/IP no servidor de back-end ou no processador de mensagens. De preferência, capture-os no servidor de back-end, porque os pacotes são descriptografados no servidor de back-end.
  2. Se você for um usuário da Public Cloud, não terá acesso ao processador de mensagens. No entanto, a captura dos pacotes TCP/IP no servidor de back-end pode ajudar a identificar um problema.

  3. Depois de decidir onde capturar os pacotes TCP/IP, use o comando tcpdump a seguir para capturar pacotes TCP/IP.

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

    • Se você estiver usando os pacotes TCP/IP no servidor de back-end, use o endereço IP público do processador de mensagens no comando tcpdump. Para saber como usar o comando para examinar o tráfego do servidor de back-end, consulte tcpdump.

    • Se você estiver recebendo os pacotes TCP/IP no processador de mensagens, use o endereço IP público do servidor de back-end no comando tcpdump. Para receber ajuda sobre como usar o comando para examinar o tráfego do processador de mensagens, consulte tcpdump.

    • Se houver vários endereços IP para o servidor de back-end/processador de mensagens, tente usar outro comando tcpdump. Consulte tcpdump para mais informações sobre essa ferramenta e outras variantes desse comando.

  4. Analise os pacotes TCP/IP usando a ferramenta Wireshark ou uma ferramenta semelhante. A captura de tela a seguir mostra pacotes TCP/IP no Wireshark.

  5. Observe na saída do Wireshark que o handshake TCP de três vias é concluído com sucesso nos três primeiros pacotes.

  6. O processador de mensagens envia a mensagem "Client Hello" no pacote 4.

  7. Como não há confirmação do servidor de back-end, o processador de mensagens retransmite a mensagem "Client Hello" várias vezes nos pacotes 5, 6 e 7 depois de aguardar um intervalo de tempo predefinido.

  8. Quando o processador de mensagens não recebe nenhuma confirmação após três tentativas, ele envia a mensagem FIN, ACK para o servidor de back-end para indicar que está encerrando a conexão.

  9. Conforme mostrado na sessão de exemplo do Wireshark, a conexão com o back-end foi bem-sucedida (etapa 1). No entanto, o tempo limite do handshake SSL expirou porque o servidor de back-end nunca respondeu.

Se você executou as etapas de solução de problemas neste playbook e determinou que um tempo limite causou o erro de handshake TLS/SSL, acesse a seção Solução.

Como usar o Monitoramento de API para identificar um problema

O monitoramento de APIs permite isolar as áreas problemáticas rapidamente para diagnosticar problemas de erro, desempenho e latência e a origem delas, como apps de desenvolvedor, proxies de API, destinos de back-end ou a plataforma de API.

Siga um cenário de exemplo que demonstra como resolver problemas 5xx com suas APIs usando o monitoramento de API. Por exemplo, você pode configurar um alerta para receber uma notificação quando o número de falhas de messaging.adaptors.http.BadGateway exceder um limite específico.

Resolução

Normalmente, os tempos limite de handshake do SSL ocorrem devido a restrições de firewall no servidor de back-end que bloqueiam o tráfego do Apigee Edge. Se você seguiu as etapas de diagnóstico e determinou que a causa do erro de handshake é um tempo limite, é necessário envolver a equipe de rede para identificar a causa e corrigir as restrições do firewall.

As restrições de firewall podem ser impostas em diferentes camadas de rede. É importante garantir que as restrições em todas as camadas da rede sejam removidas em relação aos IPs do processador de mensagens para garantir um fluxo de tráfego tranquilo entre o Apigee Edge e o servidor de back-end.

Se não houver restrições de firewall e/ou o problema persistir, acesse Precisa de informações de diagnóstico.

É necessário coletar informações de diagnóstico

Se o problema persistir mesmo depois de seguir as instruções acima, colete as seguintes informações de diagnóstico. Entre em contato e compartilhe com o suporte do Apigee Edge:

  1. Se você for usuário da Public Cloud, forneça as seguintes informações:
    1. Nome da organização
    2. Nome do ambiente
    3. Nome do proxy da API
    4. Comando curl completo para reproduzir o erro
    5. Arquivo de rastreamento mostrando o erro
    6. Pacotes TCP/IP capturados no servidor de back-end
  2. Se você for usuário da nuvem particular, forneça as seguintes informações:
    1. Mensagem de erro completa observada
    2. Pacote de proxy da API
    3. Arquivo de rastreamento mostrando o erro
    4. Registros do processador de mensagens /opt/apigee/var/log/edge-message-processor/logs/system.log
    5. Pacotes TCP/IP capturados no servidor de back-end ou no processador de mensagens.
  3. Detalhes sobre quais seções deste Playbook você tentou e outros insights que vão ajudar a resolver o problema rapidamente.