502 Gateway inválido - Desligamento de soquete

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

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 vai encontrar o seguinte código de resposta:

HTTP/1.1 502 Bad Gateway

A resposta vai incluir a seguinte mensagem de erro:

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

Causas possíveis

Etapas comuns do diagnóstico

1. Verifique os registros do Edge Microgateway:

   /var/tmp/edgemicro-`hostname`-*.log

2. Pesquise para ver se há erros 502 com o código ECONNRESET durante um período específico (se o problema ocorreu no passado) ou se ainda há solicitações com falha 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 você tiver o nível de registro 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 isso pode ser usado mais tarde para capturar um 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. Isso pode ser pesquisado nos registros para determinar a frequência com que ocorre.

Causa: tempo limite do sinal de atividade configurado incorretamente

Diagnóstico

1. Siga as etapas em Etapas comuns do diagnóstico e verifique se você recebeu o [socket hang up][ECONNRESET] erro.

2. Se sim, investigue mais a fundo 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 o 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 o tcpdump capturado:

   Exemplo de saída do tcpdump: ( ver imagem maior)

   

   No exemplo tcpdump acima, você pode ver 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 um ACK.
   4. No pacote 250560, o servidor envia a Continuation mensagem.
   5. No pacote 250561, o cliente envia um ACK.
   6. No pacote 262436, o servidor envia um FIN, ACK para o cliente, iniciando o fechamento da conexão. Observe que isso ocorre aproximadamente cinco segundos após o pacote anterior (250561).
   7. No pacote 262441, o cliente envia outra POST solicitação. No entanto, isso falha porque o servidor já iniciou o fechamento da conexão. Ele responde com um RST no pacote 262441.

   A mesma conexão foi reutilizada pelo menos uma vez com sucesso neste exemplo, mas on a solicitação final, o servidor inicia um fechamento da conexão após cinco segundos de tempo ocioso, que ocorre ao mesmo tempo em que o cliente enviou uma nova solicitação. Isto sugere que o tempo limite do sinal de atividade do servidor de back-end é provavelmente menor ou igual a o valor definido no cliente. Para validar isso, consulte Comparar o tempo limite do sinal de atividade no Edge Microgateway e no servidor de back-end.

Comparar tempos limite do sinal de atividade

1. O Edge Microgateway não tem uma propriedade de tempo limite do sinal de atividade específica. Ela é determinada pelo sistema operacional em que está em execução. Exemplos comuns são contêineres do Windows, Linux e Docker.
2. É possível que isso seja personalizado no sistema operacional. Consulte o administrador do sistema. Por padrão, os sistemas operacionais Linux têm um tempo limite do sinal de atividade padrão de duas horas.
3. Em seguida, verifique a propriedade de tempo limite do sinal de atividade configurada no servidor de back-end. Digamos que o 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 do 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 do 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 a propriedade de tempo limite do sinal de atividade seja menor que o valor definido no servidor de back-end, usando as etapas aplicáveis ao seu sistema operacional.

Prática recomendada

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

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

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

   edgemicro:
     keep_alive_timeout: 65000

2. O tempo limite do sinal de atividade do sistema operacional do Edge Microgateway precisa ser menor que o tempo limite do sinal de atividade do servidor de destino.
3. Se você tiver outros saltos na frente ou atrás do Edge Microgateway, a mesma regra será aplicada. Você sempre precisa deixar como responsabilidade do cliente downstream fechar a conexão com o upstream.

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

Diagnóstico

1. Siga as etapas explicadas em Etapas comuns do diagnóstico e verifique se você recebeu o [socket hang up][ECONNRESET] erro.
2. Se sim, investigue mais a fundo 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 (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 que o Edge Microgateway recebesse 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 adequadamente no servidor de back-end.
4. Se você não encontrar erros ou informações no servidor de back-end, colete a tcpdump saída no servidor do Edge Microgateway:

   tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
   

5. Analise o tcpdump capturado:

   Exemplo de saída do tcpdump: ( ver imagem maior)

   

   No exemplo tcpdump acima, você pode ver 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 fechamento da conexão.
   4. Nos pacotes 7 em diante, a conexão é fechada mutuamente. Como a conexão foi fechada antes do envio da resposta, o Edge Microgateway vai retornar o erro HTTP 502 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 registro e no tcpdump podem ser usados com frequência para correlacionar os erros com os pacotes reais.

   Resolução

   Corrija o problema no servidor de back-end de maneira adequada.

   Se o problema persistir e você precisar de ajuda para resolver o 502 Bad Gateway Error ou suspeitar que seja um problema no Edge Microgateway, 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, reúna as seguintes informações de diagnóstico e entre em contato com o Suporte do Apigee Edge:

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