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. informações

Sintoma

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

Mensagem de erro

O aplicativo cliente recebe este código de resposta:

HTTP/1.1 502 Bad Gateway

Além disso, talvez você veja a seguinte mensagem de erro:

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

Possível causa

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

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

Causa: tempo limite de handshake de 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 Edge Message Processor e um servidor de back-end.

Um handshake de TLS/SSL envolve várias etapas. Esse erro geralmente 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 de TLS/SSL. As instruções para a nuvem privada do Edge e a nuvem pública estão listadas.

Investigar a saída da sessão do Trace

Nas etapas a seguir, explicamos 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 trace da solicitação de API com falha mostrar o seguinte, é provável que tenha ocorrido um erro de tempo limite de handshake de 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ê vir que o erro ocorreu após 55 segundos, isso vai informar 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 ocorreu um tempo limite.

    3. Se você estiver na nuvem privada de borda, anote o valor do campo X-Apigee.Message-ID na saída de rastreamento, conforme mostrado abaixo. Um usuário da nuvem privada pode usar esse valor de ID para resolver outros problemas, conforme explicado posteriormente.

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

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

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

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

Se você estiver na nuvem privada do Apigee Edge, poderá executar as etapas a seguir 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 de borda, pule esta seção e acesse Outras etapas de diagnóstico para usuários de nuvem privada e pública.

  1. Verifique se você pode 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 resolver para vários endereços IP, use o nome do host do servidor de back-end no comando telnet, como mostrado abaixo:

      telnet BackendServer-HostName 443

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

    Se o comando telnet falhar, fale com sua 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 ver 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ê recebe 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 você encontrar esse erro no arquivo de registro do processador de mensagens, continue investigando. Acesse Outras etapas de diagnóstico para usuários da nuvem privada e pública do Edge.

Se você não vir a mensagem de handshake no arquivo de registros, acesse Needs Gather Diagnostic Information.

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

Para identificar o problema com mais precisão, use a ferramenta tcpdump, que analisa os pacotes TCP/IP para confirmar se o tempo limite foi atingido durante o handshake de TLS/SSL.

  1. Se você for um usuário da nuvem privada, 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ê é um usuário da nuvem pública, não tem acesso ao processador de mensagens. No entanto, capturar os 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 seguinte comando tcpdump para capturar pacotes TCP/IP.

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

    • Se você estiver recebendo os pacotes TCP/IP no servidor de back-end, use o endereço IP público do processador de mensagens no comando tcpdump. Se precisar de ajuda para 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. Se você precisar de ajuda para 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, será necessário tentar outro uso do 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 de TCP de três vias é concluído com sucesso nos três primeiros pacotes.

  6. Em seguida, o processador de mensagens envia a mensagem "Client Hello" no pacote no 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 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 no exemplo de sessão do Wireshark, a conexão com o back-end foi bem-sucedida (etapa 1). No entanto, o handshake de SSL expirou porque o servidor de back-end nunca respondeu.

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

Como usar o monitoramento de APIs para identificar um problema

O Monitoramento de API permite isolar as áreas de problema rapidamente para diagnosticar erros, desempenho e latência e a origem, como apps de desenvolvedores, proxies de API, destinos de back-end ou a plataforma da API.

Consulte um exemplo de cenário que demonstra como resolver problemas 5xx com suas APIs usando o monitoramento de APIs. Por exemplo, configure um alerta para receber uma notificação quando o número de falhas de messaging.adaptors.http.BadGateway exceder um determinado limite.

Resolução

Normalmente, os tempos limite de handshake de SSL ocorrem devido a restrições de firewall no servidor de back-end que bloqueiam o tráfego do Apigee Edge. Se você tiver seguido as etapas de diagnóstico e determinado que a causa do erro de handshake é um tempo limite, precisará entrar em contato com sua equipe de rede para identificar a causa e corrigir as restrições de firewall.

As restrições de firewall podem ser impostas em diferentes camadas de rede. É importante remover as restrições em todas as camadas de rede relacionadas 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 de nuvem pública, forneça as seguintes informações:
    1. Nome da organização
    2. Nome do ambiente
    3. Nome de proxy da API
    4. Concluir o comando curl para reproduzir o erro
    5. Arquivo de rastreamento mostrando o erro
    6. Pacotes TCP/IP capturados no servidor de back-end
  2. Se você é um usuário da nuvem privada, forneça as seguintes informações:
    1. Mensagem de erro concluída observada
    2. Pacote de proxy de 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 Manual você experimentou e quaisquer outras informações que nos ajudarão a agilizar a resolução deste problema.