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
- Verifique os registros do Edge Microgateway:
/var/tmp/edgemicro-`hostname`-*.log
- Pesquise se há algum erro
502
com o códigoECONNRESET
durante um período específico (se o problema tiver acontecido anteriormente) ou se ainda há alguma solicitação com falha com502
.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][]
- Se o nível de geração de registros estiver definido como
warn
ouinfo
, 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 umatcpdump
.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]
- 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
- Siga as instruções em Etapas comuns de diagnóstico e verifique se você recebeu o
erro
[socket hang up][ECONNRESET]
. Em caso afirmativo, investigue mais com a ajuda de
tcpdump
, conforme explicado abaixo:
Como usar o tcpdump
- 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
- Analise as
tcpdump
capturadas:Exemplo de saída do tcpdump: ( veja a imagem ampliada)
No exemplo de
tcpdump
acima, você pode conferir o seguinte:- No pacote 250288, o cliente envia uma solicitação
POST
. - No pacote 250371, o servidor responde com
200 OK
. - No pacote 250559, o cliente envia uma
ACK.
- No pacote 250560, o servidor envia a mensagem
Continuation
. - No pacote 250561, o cliente envia uma
ACK.
- 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). - 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 umRST
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.
- No pacote 250288, o cliente envia uma solicitação
Comparar tempos limite de keep-alive
- 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.
- 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.
- 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.
- 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.
- Determine o valor definido para o tempo limite de sinal de atividade no servidor de back-end.
- 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:
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
- 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.
- 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
- Use as etapas explicadas em Etapas comuns de diagnóstico e verifique se você
recebeu o erro
[socket hang up][ECONNRESET]
. - 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. - 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.
- 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
- Analise as
tcpdump
capturadas:Exemplo de saída do tcpdump: ( veja a imagem ampliada)
No exemplo de
tcpdump
acima, você pode conferir o seguinte:- No pacote 4, o Edge Microgateway enviou uma solicitação
GET
para o servidor de destino. - No pacote 5, o servidor de destino respondeu com
ACK
para confirmar a solicitação. - 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. - 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. - 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 notcpdump
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 arquivoconfig.yaml
principal (logging > dir parameter
). É recomendável alterarlog > level
parainfo
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 chamadodefault.yaml
e, em seguida, um para cada ambienteORG-ENV-config.yaml
. Faça upload do arquivo completo para a organização e o ambiente afetados.
- No pacote 4, o Edge Microgateway enviou uma solicitação