502 Erro de tempo limite de gateway inválido

Você está visualizando a documentação do Apigee Edge.
Acesse Documentação da Apigee X. informações

Sintoma

O aplicativo cliente recebe um 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 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 para esse 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 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: tempo limite do 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 processador de mensagens do Edge e um servidor de back-end.

Um handshake TLS/SSL envolve várias etapas. Esse erro geralmente ocorre quando o handshake 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 e pública do Edge são listadas.

Investigar a saída da sessão de trace

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 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, o que é o tempo limite padrão definido no processador de mensagens. Se você notar que ocorreu um erro após 55 segundos, isso informa que o 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 Private O usuário do Google 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, execute as etapas a seguir para verificar a causa do erro de handshake. Nesta etapa, você inspeciona 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 é possível 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, trabalhe 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 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 X-Apigee.Message-ID que você encontrados 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 melhor o problema, use a ferramenta tcpdump para analisar os pacotes TCP/IP e confirmar se ocorreu um tempo limite durante o handshake 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 back-end. no servidor, 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 tomando os pacotes TCP/IP no servidor de back-end, use o servidor Endereço IP do processador de mensagens no comando tcpdump. Para obter ajuda para usar o para examinar o tráfego do servidor de back-end, consulte tcpdump.

    • Se você estiver usando 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 para 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 servidor O processador retransmite a "Hello Client" várias vezes nos pacotes 5, 6 e 7 após 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 for bem-sucedido (etapa 1), no entanto, o handshake de SSL expirou porque o back-end servidor 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 API Monitoring permite isolar áreas problemáticas rapidamente para diagnosticar problemas de erro, desempenho e latência como apps de desenvolvedores, proxies de API, destinos de back-end ou plataforma de API.

Veja um exemplo de cenário que demonstra como resolver problemas 5xx com suas APIs usando a API Monitoring. 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 de SSL ocorrem devido a restrições de o servidor de back-end que bloqueia o tráfego da Apigee Edge. Se você acompanhou as etapas de diagnóstico e determinou que a causa do erro de handshake é uma tempo limite, você precisa envolver sua equipe de rede para identificar a causa e corrigir restrições de 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.