Como soluciono os erros HTTP 502 do Application Load Balancer?

Breve descrição

Há várias causas possíveis para os erros HTTP 502: bad gateway, e a origem pode ser do seu destino ou do seu Application Load Balancer. Para identificar a origem do erro, use métricas do Amazon CloudWatch e logs de acesso.

Antes de solucionar o erro do seu Application Load Balancer, certifique-se de ativar logs de acesso. Para entender o que cada campo significa no log de acesso, consulte Entradas do log de acesso.

Se o destino for uma função do Lambda da AWS, consulte Solucionar erros HTTP 502 quando o destino for uma função do Lambda na seção Resolução.

Resolução

Encontrar a origem dos erros HTTP 502

Usar métricas do CloudWatch

Se os pontos de dados aparecem na métrica HTTPCode_ELB_502_Count, então o balanceador de carga é a origem dos erros HTTP 502. Se eles aparecem na métrica HTTPCode_Target_5XX_Count, então o destino é a origem dos erros.

Usar logs de acesso

Se elb_status_code é “502” e target_status_code é “-”, então o balanceador de carga é a origem dos erros HTTP 502. Se elb_status_code é “502” e target_status_code é “502”, então o destino é a origem dos erros.

Solucionar erros HTTP 502

Observação: filtre os logs de acesso por elb_status_code = "502" e target_status_code para ajudar a determinar a causa. Em seguida, conclua as etapas relevantes para seu caso de uso.

O balanceador de carga recebeu um TCP RST do destino ao tentar estabelecer uma conexão

Se você receber um TCP RST do destino ao estabelecer uma conexão, o balanceador de carga não poderá estabelecer um handshake TCP de 3 vias com o destino. Como resultado, o balanceador de carga não poderá encaminhar a solicitação do usuário para o destino.

• Verifique se há pontos de dados para a métrica TargetConnectionErrorCount. Essa métrica representa o número de conexões que não foram estabelecidas com êxito entre o balanceador de carga e o destino.
• Verifique se os campos request_processing_time, target_processing_time e response_processing_time nos logs de acesso estão todos definidos com o valor -1. Esse valor significa que o balanceador de carga não pode enviar a solicitação para o destino porque precisa de uma conexão bem-sucedida.

Veja a seguir um exemplo de uma entrada de log de acesso:

http 2022-04-15T16:52:50.757968Z app/my-loadbalancer/50dc6c495c0c9188 192.168.131.39:2817 10.0.0.1:80 -1 -1 -1 502 - 86 155 "GET http://example.com:80/ HTTP/1.1"
"curl/7.51.0" - - arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/my-targets/73e2d6bc24d8a067" Root=1-58337262-36d228ad5d99923122bbe354"

Observação: nessa entrada do log de acesso, request_processing_time, target_processing_time e response_processing_time estão todos definidos como -1.

O balanceador de carga recebeu uma resposta inesperada do destino, como “Destino ICMP inacessível (Host inacessível)”, ao tentar estabelecer uma conexão

• Verifique se os campos request_processing_time, target_processing_time e response_processing_time nos logs de acesso estão todos definidos com o valor -1.
• Verifique se o tráfego é permitido das sub-redes do balanceador de carga para os destinos na porta de destino.

O destino fechou a conexão com um TCP, RST ou um TCP FIN, enquanto o balanceador de carga tinha uma solicitação pendente para o destino

O balanceador de carga recebe uma solicitação e a encaminha para o destino. O destino recebe a solicitação e começa a processá-la, mas fecha a conexão com o balanceador de carga muito cedo. Isso geralmente ocorre quando a duração do tempo limite de manutenção de atividade do destino é menor do que o valor do tempo limite de inatividade do balanceador de carga. Certifique-se de que a duração do tempo limite de manutenção de atividade seja maior do que o valor do tempo limite de inatividade.

Verifique os valores dos campos request_processing_time, target_processing_time e response_processing_time.

Veja o exemplo de entrada de log de acesso a seguir:

http 2022-04-15T16:52:50.757968Z app/my-loadbalancer/50dc6c495c0c9188 192.168.131.39:2817 10.0.0.1:80 0.001 4.205 -1 502 - 94 326 "GET http://example.com:80 HTTP/1.1" "curl/7.51.0" - - arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/my-targets/73e2d6bc24d8a067 "Root=1-58337262-36d228ad5d99923122bbe354"

Observação: nessa entrada do log de acesso, request_processing_time é 0.001, target_processing_time é 4.205 e response_processing_time é -1.

A resposta de destino está malformada ou contém cabeçalhos HTTP que não são válidos

Execute uma captura de pacote no destino durante o período do problema para entender a resposta do destino.

O balanceador de carga encontrou um erro de handshake SSL ou tempo limite de handshake SSL (10 segundos) ao se conectar a um destino

A conexão TCP do balanceador de carga com o receptor HTTPS do destino foi bem-sucedida, mas o handshake SSL subsequente expira. Como resultado, o balanceador de carga não pode encaminhar a solicitação para o destino.

Verifique se o grupo de destino usa o protocolo HTTPS. Se ele não usar o protocolo HTTPS, o tempo limite do handshake SSL não é a causa do problema. Se o grupo de destino estiver usando o protocolo HTTPS, verifique os seguintes pontos:

• Verifique se os campos request_processing_time, target_processing_time e response_processing_time nos logs de acesso estão todos definidos com o valor -1.
• Verifique se há pontos de dados para a métrica TargetTLSNegotiationErrorCount.
• Execute uma captura de pacote no destino durante o período do problema para validar se ele está relacionado a um handshake SSL. Se estiver, conclua as etapas na seção Executar uma captura de pacote.
• Verifique se as cifras ou protocolos são incompatíveis.

O período de atraso do cancelamento de registro decorrido para uma solicitação tratada por um destino que teve seu registro cancelado

Em seus eventos do CloudTrail, verifique se há uma chamada de API com a ação DeregisterTargets durante o período do problema. Se uma chamada de API com DeregisterTargets ocorreu durante o período do problema, o erro é causado por um destino que teve seu registro cancelado muito cedo. Para resolver esse problema, aumente o período de atraso no cancelamento do registro para que operações demoradas possam ser concluídas sem falhar.

Solucionar os erros HTTP 502 quando o destino é uma função do Lambda

Observação: para solicitações a uma função do Lambda que falham, o balanceador de carga armazena códigos de motivo de erro específicos do Lambda no campo error_reason dos logs de acesso.

O destino é uma função do Lambda e o corpo da resposta excede 1 MB

• Verifique se há um ponto de dados para a métrica LambdaUserError.
• Verifique se o campo error_reason no log de acesso do balanceador de carga está definido como LambdaResponseTooLarge.

O destino é uma função do Lambda que não respondeu antes que seu tempo limite configurado fosse atingido

• Verifique a configuração do tempo limite da função do Lambda.
• Verifique se há um ponto de dados para a métrica LambdaUserError.
• Verifique se o campo error_reason no log de acesso do balanceador de carga está definido como LambdaUnhandled.

O destino é uma função do Lambda que retornou um erro ou a função foi limitada pelo serviço do Lambda

Entre em contato com o AWS Support para obter orientação sobre o controle de utilização de serviços.

Executar uma captura de pacote

Para Linux, use o seguinte comando:

sudo tcpdump -i any -w filename.pcap

Para o Microsoft Windows, baixe e use o aplicativo Wireshark (do site da Wireshark).

Para obter mais detalhes, consulte Como soluciono problemas de desempenho de rede entre instâncias do EC2 no Linux ou Windows em uma VPC e um host on-premises pelo gateway da Internet? Consulte as seções Testar amostras de captura de pacote usando tcpdump e Realizar uma captura de pacote.