502 Gateway inválido - Desligamento de soquete

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

Sintoma

O aplicativo cliente recebe um código de status HTTP de 502 Bad Gateway com o código ECONNRESET como resposta para chamadas de API no Edge Microgateway.

Mensagem de erro

O cliente verá o seguinte código de resposta:

HTTP/1.1 502 Bad Gateway

A resposta incluirá a seguinte mensagem de erro:

{"message":"socket hang up","code":"ECONNRESET"}

Causas possíveis

Causa Descrição Instruções de solução de problemas aplicáveis para
Tempo limite de sinal de atividade configurado incorretamente Os tempos limite de sinal de atividade foram configurados incorretamente entre o Edge Microgateway e o servidor de destino. Usuários de nuvens públicas e privadas de borda
O servidor de destino encerra a conexão prematuramente O servidor de destino encerra a conexão prematuramente enquanto o Edge Microgateway está enviando o payload da solicitação. Usuários de nuvens públicas e privadas de borda

Etapas comuns do diagnóstico

  1. Verifique os registros do Edge Microgateway:
    /var/tmp/edgemicro-`hostname`-*.log
    
  2. Pesquise se há algum erro 502 com o código ECONNRESET durante um período específico (se o problema tiver acontecido anteriormente) ou se ainda há alguma solicitação com falha com 502.
    2021-06-23T03:52:24.110Z [error][0:8000][3][myorg][test]
    [emg_badtarget/flakey/hangup][][][6b089a00-d3d6-11eb-95aa-911f1ee6c684]
    [microgateway-core][][GET][502][socket hang up][ECONNRESET][]
    
  3. Se o nível de geração de registros estiver definido como warn ou info, também haverá uma mensagem [warn] incluindo o nome do host e a porta do servidor de destino no segundo elemento. Neste exemplo, é X.X.X.X:8080, e pode ser usado posteriormente para capturar uma tcpdump.
    2021-06-23T03:52:24.109Z
    [warn][X.X.X.X:8080][3][myorg][test][emg_badtarget/flakey/hangup]
    [][][6b089a00-d3d6-11eb-95aa-911f1ee6c684][plugins-middleware]
    [targetRequest error][GET][][socket hang up][ECONNRESET][395]
    
  4. O código de erro [socket hang up][ECONNRESET] indica que o servidor de destino fechou a conexão com o Edge Microgateway. É possível pesquisar isso nos registros para determinar com que frequência isso está acontecendo.

Causa: tempo limite de sinal de atividade configurado incorretamente

Diagnóstico

  1. Siga as instruções em Etapas comuns de diagnóstico e verifique se você recebeu o erro [socket hang up][ECONNRESET].
  2. Em caso afirmativo, investigue mais com a ajuda de tcpdump, conforme explicado abaixo:

Como usar o tcpdump

  1. Capture um tcpdump entre o Edge Microgateway e o servidor de back-end no sistema operacional do host do Edge Microgateway com o seguinte comando:
    tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
    
  2. Analise as tcpdump capturadas:

    Exemplo de saída do tcpdump: ( veja a imagem ampliada)

    No exemplo de tcpdump acima, você pode conferir o seguinte:

    1. No pacote 250288, o cliente envia uma solicitação POST.
    2. No pacote 250371, o servidor responde com 200 OK.
    3. No pacote 250559, o cliente envia uma ACK.
    4. No pacote 250560, o servidor envia a mensagem Continuation.
    5. No pacote 250561, o cliente envia uma ACK.
    6. No pacote 262436, o servidor envia um FIN, ACK ao cliente, iniciando o encerramento da conexão. Isso ocorre aproximadamente cinco segundos após o pacote anterior (250561).
    7. No pacote 262441, o cliente envia outra solicitação POST. No entanto, isso falha porque o servidor já iniciou o encerramento da conexão. Ele responde com um RST no pacote 262441.

    Neste exemplo, a mesma conexão foi reutilizada pelo menos uma vez. No entanto, na solicitação final, o servidor inicia um encerramento da conexão após cinco segundos de tempo de inatividade, que ocorre ao mesmo tempo que o cliente enviou uma nova solicitação. Isso sugere que o tempo limite de sinal de atividade do servidor de back-end provavelmente é menor ou igual ao valor definido no cliente. Para validar isso, consulte Comparar o tempo limite de sinal de atividade no Edge Microgateway e no servidor de back-end.

Comparar tempos limite de keep-alive

  1. O Edge Microgateway não tem uma propriedade de tempo limite de sinal de atividade específica. Isso é determinado pelo sistema operacional em que está sendo executado. Exemplos comuns são contêineres do Windows, Linux e Docker.
  2. Isso pode ser personalizado no sistema operacional. Consulte o administrador do sistema. Por padrão, os sistemas operacionais Linux têm um tempo limite padrão de sinal de atividade de duas horas.
  3. Em seguida, verifique a propriedade de tempo limite de sinal de atividade configurada no seu servidor de back-end. Digamos que seu servidor de back-end esteja configurado com um valor de 10 segundos.
  4. Se você determinar que o valor do tempo limite do sinal de atividade no sistema operacional é maior que o valor da propriedade de tempo limite do sinal de atividade no servidor de back-end, como no exemplo acima, essa será a causa dos erros 502.

Resolução

Verifique se a propriedade de tempo limite de sinal de atividade é sempre menor no sistema operacional em que o Edge Microgateway está em execução em comparação com o servidor de back-end.

  1. Determine o valor definido para o tempo limite de sinal de atividade no servidor de back-end.
  2. Configure um valor apropriado para a propriedade de tempo limite do sinal de atividade no sistema operacional, de modo que essa propriedade seja menor que o valor definido no servidor de back-end, usando as etapas aplicáveis ao seu sistema operacional.

Prática recomendada

É altamente recomendável que os componentes downstream sempre tenham um limite de tempo limite de sinal de atividade menor do que o configurado nos servidores upstream para evitar esses tipos de disputas e erros de 502. Cada salto downstream precisa ser menor que cada salto upstream. No Edge Microgateway, é recomendável usar as seguintes diretrizes:

  1. O tempo limite de sinal de atividade no aplicativo cliente ou no balanceador de carga precisa ser menor que o tempo limite de sinal de atividade do Edge Microgateway.

    Para configurar o tempo limite do sinal de atividade no Edge Microgateway, adicione o valor keep_alive_timeout ao seu arquivo ~/.edgemicro/org-env-config.yaml.

    edgemicro:
      keep_alive_timeout: 65000
    
  2. O tempo limite de sinal de atividade do sistema operacional Edge Microgateway precisa ser menor que o tempo limite de sinal de atividade do servidor de destino.
  3. Se você tiver outros saltos na frente ou atrás do Edge Microgateway, a mesma regra deverá ser aplicada. Sempre deixe que o cliente downstream seja responsável pelo encerramento da conexão com o upstream.

Causa: o servidor de destino encerra a conexão prematuramente

Diagnóstico

  1. Use as etapas explicadas em Etapas comuns de diagnóstico e verifique se você recebeu o erro [socket hang up][ECONNRESET].
  2. Em caso afirmativo, investigue mais com a ajuda de tcpdump, conforme explicado abaixo.

    A mensagem de erro [targetRequest error][GET][][socket hang up][ECONNRESET] no exemplo acima indica que esse erro ocorreu enquanto o Edge Microgateway estava enviando a solicitação para o servidor de back-end (de destino). Ou seja, o Edge Microgateway enviou a solicitação de API para o servidor de back-end e estava aguardando a resposta. No entanto, o servidor de back-end encerrou a conexão abruptamente antes do Edge Microgateway receber uma resposta.

  3. Verifique os registros do servidor de back-end e veja se há erros ou informações que possam ter levado o servidor de back-end a encerrar a conexão abruptamente. Se você encontrar erros ou informações, acesse Resolução e corrija o problema corretamente no servidor de back-end.
  4. Se você não encontrar erros ou informações no servidor de back-end, colete a saída tcpdump no servidor Edge Microgateway:
    tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
    
  5. Analise as tcpdump capturadas:

    Exemplo de saída do tcpdump: ( veja a imagem ampliada)

    No exemplo de tcpdump acima, você pode conferir o seguinte:

    1. No pacote 4, o Edge Microgateway enviou uma solicitação GET para o servidor de destino.
    2. No pacote 5, o servidor de destino respondeu com ACK para confirmar a solicitação.
    3. No entanto, no pacote 6, em vez de responder com um payload de resposta, o servidor de destino envia um FIN, ACK iniciando o encerramento da conexão.
    4. Nos pacotes 7 em diante, a conexão é fechada mutuamente. Como a conexão foi encerrada antes do envio da resposta, o Edge Microgateway retornará o erro HTTP 502 de volta ao cliente.
    5. Observe que o carimbo de data/hora do pacote 8, 2021-06-23T03:52:24.110Z , corresponde ao carimbo de data/hora em que o erro foi registrado nos registros do Edge Microgateway. Os carimbos de data/hora nos arquivos de registros e no tcpdump geralmente podem ser usados para correlacionar os erros com os pacotes reais.

    Resolução

    Corrija o problema no servidor de back-end adequadamente.

    Se o problema persistir e você precisar de ajuda para solucionar problemas 502 Bad Gateway Error ou suspeitar que é um problema no Edge Microgateway, acesse Precisa coletar 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 e entre em contato com o suporte do Apigee Edge:

    • Arquivos de registros: a pasta padrão é /var/tmp, mas ela pode ser substituída no arquivo config.yaml principal (logging > dir parameter). É recomendável alterar log > level para info antes de fornecer os arquivos de registros ao suporte da Apigee.
    • Arquivo de configuração: a configuração principal do Edge Microgateway está no arquivo YAML na pasta padrão do Edge Microgateway, $HOME/.edgemicro. Há um arquivo de configuração padrão chamado default.yaml e, em seguida, um para cada ambiente ORG-ENV-config.yaml. Faça upload do arquivo completo para a organização e o ambiente afetados.