502 Gateway inválido - Desligamento de soquete

Esta é a documentação do Apigee Edge.
Acesse 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 uma 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 Tempos limite de sinal de atividade configurados incorretamente entre o Edge Microgateway e o servidor de destino. Usuários de nuvem pública e privada de borda
O servidor de destino encerra a conexão prematuramente O servidor de destino fecha prematuramente a conexão enquanto o Edge Microgateway está enviando o payload da solicitação. Usuários de nuvem pública e privada 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 de 502 com o código ECONNRESET durante um período específico (se o problema tiver acontecido no passado) ou se houver alguma solicitação ainda 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 ser uma mensagem [warn] incluindo o nome do host do servidor de destino e a porta na segunda . 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 encerrou a conexão com o Edge Microgateway. Isso pode ser pesquisado 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 etapas em Etapas comuns de diagnóstico e verifique se você recebeu o Erro [socket hang up][ECONNRESET].

  2. Se sim, investigue mais com a ajuda de tcpdump, conforme explicado abaixo:

Como usar o tcpdump

  1. Capturar um tcpdump entre o Edge Microgateway e o servidor de back-end em 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 a tcpdump capturada:

    Exemplo de resposta do tcpdump: ( ver imagem maior)

    No tcpdump de exemplo acima, é possível 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 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 encerramento da conexão. Observe que são aproximadamente cinco segundos após o pacote anterior (250561).
    7. No pacote 262441, o cliente envia outro POST solicitação. No entanto, isso falhará porque o servidor já iniciou o encerramento da uma conexão com a Internet. ele responde com um RST no pacote; 262441

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

Comparar tempos limite de sinal de atividade

  1. O Edge Microgateway não tem uma propriedade de tempo limite de sinal de atividade específica. É determinado pelo sistema operacional em que é executado. Exemplos comuns são o Windows, contêineres Linux e Docker.
  2. Pode ser personalizado no sistema operacional. Verifique com sua administrador do sistema. Por padrão, os sistemas operacionais Linux têm um sinal de atividade de duas horas.
  3. Em seguida, verifique a propriedade de tempo limite de sinal de atividade configurada no servidor de back-end. Vamos 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 de sinal de atividade no sistema operacional é maior que o valor da propriedade de tempo limite de sinal de atividade no servidor de back-end, como no acima do exemplo, essa é a causa dos erros 502.

Resolução

A propriedade de tempo limite de sinal de atividade precisa estar sempre em nível inferior no sistema operacional em que o Edge está sempre atualizado. O 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. Configurar um valor apropriado para a propriedade de tempo limite de sinal de atividade no de modo que a propriedade de tempo limite de sinal de atividade seja menor que o valor definido no back-end usando as etapas aplicáveis ao seu sistema operacional.

Prática recomendada

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

  1. O tempo limite do sinal de atividade no aplicativo cliente ou no balanceador de carga deve 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 keep_alive_timeout à sua 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 destino tempo limite de sinal de atividade do servidor.
  3. Se você tiver outros saltos na frente ou atrás do Edge Microgateway, a mesma regra vai precisar ser aplicadas. Você sempre deve deixar como responsabilidade do cliente downstream o fechamento a conexão com o upstream.
.

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

Diagnóstico

  1. Siga as etapas explicadas em Etapas comuns de diagnóstico e confirme se você recebeu o erro [socket hang up][ECONNRESET].
  2. Se sim, 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 quando o Edge Microgateway estava enviando a solicitação para o servidor de back-end (destino). Ou seja, o Edge Microgateway enviou solicitação de API ao servidor de back-end e estava aguardando a resposta. No entanto, o back-end O servidor encerrou a conexão abruptamente antes de o Edge Microgateway receber uma resposta.

  3. Verifique os registros do servidor de back-end e veja se há erros ou informações que possam levaram 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. no servidor de back-end.
  4. Se você não encontrar erros ou informações no servidor de back-end, colete o Saída tcpdump no servidor Edge Microgateway: 
    tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
  5. Analise a tcpdump capturada:

    Exemplo de resposta do tcpdump: ( ver imagem maior)

    No tcpdump de exemplo acima, é possível ver o seguinte:

    1. No pacote 4, o Edge Microgateway enviou uma solicitação GET para o destino. servidor.
    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 destino servidor envia um FIN, ACK iniciando o encerramento da conexão.
    4. Nos pacotes 7 e posteriores, a conexão é fechada mutuamente. Como a conexão era fechado antes do envio da resposta, o Edge Microgateway vai retornar o erro HTTP 502 de volta para o cliente.
    5. 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 no Edge Microgateway. ou de sistemas operacionais de contêineres. Os carimbos de data/hora nos arquivos de registro e no tcpdump geralmente podem ser usada para correlacionar os erros com os pacotes reais.

    Resolução

    Corrija o problema no servidor de back-end corretamente.

    Se o problema persistir e você precisar de ajuda para resolver problemas, 502 Bad Gateway Error ou você suspeita que seja um problema no Edge Microgateway, acesse É necessário reunir 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: 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 pode ser substituída. no arquivo config.yaml principal (logging > dir parameter). É recomendado mudar log > level para info antes de fornecer os arquivos de registro para o suporte da Apigee.
    • Arquivo de configuração: a configuração principal do Edge Microgateway fica no Arquivo YAML na pasta padrão do Edge Microgateway, $HOME/.edgemicro. Há um arquivo de configuração padrão chamado default.yaml e um para cada ambiente. ORG-ENV-config.yaml. Faça upload deste arquivo da organização e do ambiente afetados.