Solucionar problemas em seus Application Load Balancers

As informações a seguir podem ajudar na solução de problemas com seu Application Load Balancer.

Solucionar problemas de verificação de integridade usando o mapa de recursos

Se suas metas do Application Load Balancer estiverem falhando nas verificações de saúde, você pode usar o mapa de recursos do Elastic Load Balancing para encontrar alvos não íntegros e tomar medidas com base no código do motivo da falha.

Acessando o mapa de recursos

1. Abra o console do Amazon EC2 em https://console.aws.amazon.com/ec2/.

2. No painel de navegação, selecione Balanceador de carga.

3. Selecione o load balancer.

4. Escolha a guia Mapa de recursos para exibir uma visualização dos recursos.

Navegando pelo mapa de recursos

• Passe o mouse sobre ou selecione um quadro de recursos para destacar as relações entre ele e outros recursos.

• Selecione um quadro de recursos para ver detalhes adicionais sobre esse recurso.

• Selecione um nome de recurso em um quadro para visitar a página de detalhes desse recurso.

Usando o mapa de recursos

O mapa de recursos fornece duas visualizações: Visão geral e Mapa de alvos insalubres. A opção Visão geral é selecionada por padrão e exibe todos os recursos do seu balanceador de carga. Selecionar a visualização Unhealth Target Map exibirá somente os alvos não íntegros em cada grupo de destino associado ao Application Load Balancer.

nota

Você deve habilitar Mostrar detalhes do recurso para visualizar o resumo da verificação de saúde e as mensagens de erro no mapa de recursos. Quando não ativado, você deve selecionar cada recurso para ver seus detalhes.

A coluna Grupos-alvo exibe um resumo das metas saudáveis e não saudáveis de cada grupo-alvo. Isso pode ajudar a determinar se todos os alvos estão falhando nas verificações de saúde ou se somente alvos específicos estão falhando. Se todos os alvos em um grupo-alvo falharem nas verificações de integridade, verifique a configuração do grupo-alvo. Selecione o nome de um grupo-alvo para abrir sua página de detalhes em uma nova guia.

A coluna Metas exibe o TargetID e o status atual da verificação de saúde de cada alvo. Quando um alvo não está íntegro, o código do motivo da falha da verificação de integridade é exibido. Quando um único destino está falhando em uma verificação de integridade, verifique se o destino tem recursos suficientes e confirme se os aplicativos em execução no destino estão disponíveis. Selecione um nome de destino para abrir sua página de detalhes em uma nova guia.

Selecionar Exportar oferece a opção de exportar a visualização atual do mapa de recursos do Application Load Balancer como PDF.

Solucionando problemas de status de alvo não íntegros

• Insalubre: incompatibilidade de resposta HTTP

  • Verifique se o aplicativo em execução no destino está enviando a resposta HTTP correta às solicitações de verificação de integridade do Application Load Balancer.

  • Como alternativa, você pode atualizar a solicitação de verificação de integridade do Application Load Balancer para corresponder à resposta do aplicativo em execução no destino.

• Insalubre: a solicitação atingiu o tempo limite

  • Verifique se os grupos de segurança e as listas de controle de acesso à rede (ACL) associados aos seus alvos e ao Application Load Balancer não estão bloqueando a conectividade.

  • Verifique se o destino tem recursos suficientes disponíveis para aceitar conexões do Application Load Balancer.

  • Verifique o status de todos os aplicativos em execução no destino.

  • As respostas da verificação de integridade do Application Load Balancer podem ser visualizadas nos registros do aplicativo de cada destino. Para obter mais informações, consulte Códigos de motivo da verificação de saúde.

• Insalubre: FailedHealthChecks

  • Verifique o status de todos os aplicativos em execução no destino.

  • Verifique se o alvo está escutando o tráfego na porta de verificação de integridade.

    Ao usar um ouvinte HTTPS

    Você escolhe qual política de segurança é usada para conexões front-end. A política de segurança usada para conexões de back-end é selecionada automaticamente com base na política de segurança de front-end em uso.

    • Se seu ouvinte HTTPS estiver usando uma política de segurança TLS 1.3 para conexões front-end, a política de ELBSecurityPolicy-TLS13-1-0-2021-06 segurança será usada para conexões back-end.

    • Se seu ouvinte HTTPS não estiver usando uma política de segurança TLS 1.3 para conexões front-end, a política de ELBSecurityPolicy-2016-08 segurança será usada para conexões back-end.

    Para obter mais informações, consulte Políticas de segurança.

  • Verifique se o destino está fornecendo um certificado e uma chave de servidor no formato correto especificado pela política de segurança.

  • Para conexões TLS, verifique se o destino suporta uma ou mais cifras correspondentes e um protocolo fornecido pelo Application Load Balancer.

Um destino registrado não está em serviço

Se um destino estiver levando mais tempo que o esperado para entrar no estado InService, ele pode estar falhando nas verificações de integridade. O destino não entrará em serviço até ser aprovado em uma verificação de integridade. Para ter mais informações, consulte Verificações de integridade para os grupos de destino.

Verifique se a sua instância está falhando nas verificações de integridade e verifique os seguintes problemas:

Um security group não permite o tráfego

O security group associado a uma instância deve permitir tráfego do load balancer usando a porta de verificação de integridade e o protocolo de verificação de integridade. Você pode adicionar uma regra ao security group da instância para permitir todo o tráfego do security group do load balancer. Além disso, o security group para seu load balancer deve permitir o tráfego para as instâncias.

Uma lista de controle de acesso (ACL) à rede não permite o tráfego

A Network ACL associada às sub-redes para suas instâncias deve permitir tráfego de entrada na porta de verificação de integridade e tráfego de saída nas portas efêmeras (1024-65535). A Network ACL associada às sub-redes para os nós do seu load balancer devem permitir tráfego de entrada nas portas efêmeras e tráfego de saída na verificação de integridade e nas portas efêmeras.

O caminho de ping não existe

Crie uma página de destino para a verificação de integridade e especifique seu caminho como caminho de ping.

A conexão expira

Primeiro, verifique se você pode se conectar ao destino diretamente de dentro da rede usando o endereço IP privado do destino e o protocolo de verificação de integridade. Se você não conseguir se conectar, verifique se a instância está superutilizada e adicione mais destinos ao seu grupo de destino se estiver muito ocupado para responder. Se você puder se conectar, é possível que a página de destino não esteja respondendo antes do período do tempo limite da verificação de integridade. Escolha uma página de destino mais simples para a verificação de integridade ou ajuste as configurações de verificação de integridade.

O destino não retorna um código de resposta bem-sucedido

Por padrão, o código de sucesso é 200, mas você também pode especificar códigos de sucesso adicionais ao configurar as verificações de integridade. Confirme os códigos de sucesso que o load balancer está esperando e se seu aplicativo está configurada para retornar esses códigos com sucesso.

O código de resposta do destino estava mal formado ou houve um erro na conexão com o destino

Verifique se a aplicação responde às solicitações de verificação de integridade do balanceador de carga. Algumas aplicações exigem configuração adicional para responder às verificações de integridade, como uma configuração de host virtual para responder ao cabeçalho do host HTTP enviado pelo balanceador de carga. O valor do cabeçalho do host contém o endereço IP privado do destino, seguido pela porta de verificação de integridade quando não estiver usando uma porta padrão. Se o destino usar uma porta de verificação de integridade padrão, o valor do cabeçalho do host conterá somente o endereço IP privado do destino. Por exemplo, se o endereço IP privado do seu destino for 10.0.0.10 e sua porta de verificação de integridade for8080, o cabeçalho HTTP Host enviado pelo balanceador de carga nas verificações de saúde seráHost: 10.0.0.10:8080. Se o endereço IP privado do seu destino for 10.0.0.10 e sua porta de verificação de integridade 80 for, o cabeçalho HTTP Host enviado pelo balanceador de carga nas verificações de saúde seráHost: 10.0.0.10. Pode ser necessário realizar uma configuração de host virtual para responder a esse host ou uma configuração padrão para verificar a integridade da aplicação com sucesso. As solicitações de verificação de integridade têm os seguintes atributos: User-Agent é definido como ELB-HealthChecker/2.0, o terminador de linha para campos de cabeçalho de mensagem é a sequência CRLF e o cabeçalho termina na primeira linha vazia seguida por um CRLF.

Os clientes não conseguem se conectar a um balanceador de carga voltado para a Internet

Se o balanceador de carga não estiver respondendo às solicitações, verifique os seguintes problemas possíveis:

Seu balanceador de carga voltado para a Internet está anexado a uma sub-rede privada

É necessário que você especifique sub-redes públicas para o seu balanceador de carga. Uma sub-rede pública tem uma rota para o Internet Gateway para sua Virtual Private Cloud (VPC).

Um security group ou Network ACL não permite o tráfego

O security group para o load balancer e quaisquer Network ACLs para as sub-redes do load balancer devem permitir tráfego de entrada dos clientes e de saída para os clientes nas portas do listener.

As solicitações enviadas para um domínio personalizado não são recebidas pelo balanceador de carga.

Se o balanceador de carga não estiver recebendo solicitações enviadas para um domínio personalizado, verifique os seguintes problemas:

O nome de domínio personalizado não corresponde ao endereço IP do balanceador de carga.

• Confirme para qual endereço IP o nome de domínio personalizado é resolvido usando uma interface da linha de comando.

  • Linux, macOS ou Unix: você pode usar o comando dig no Terminal. Ex.dig example.com

  • Windows: você pode usar o comando nslookup no Prompt de comando. Ex.nslookup example.com

• Confirme para qual endereço IP o nome DNS dos balanceadores de carga é resolvido usando uma interface da linha de comando.

• Compare os resultados das duas saídas. É necessário que os endereços IP correspondam.

Se estiver usando o Route 53 para hospedar seu domínio personalizado, consulte Meu domínio não está disponível na Internet no Guia do desenvolvedor do Amazon Route 53.

As solicitações HTTPS enviadas ao balanceador de carga retornam “NET::ERR_CERT_COMMON_NAME_INVALID”

Se as solicitações HTTPS estiverem recebendo NET::ERR_CERT_COMMON_NAME_INVALID do balanceador de carga, verifique as seguintes causas possíveis:

• O nome de domínio usado na solicitação HTTPS não corresponde ao nome alternativo especificado no certificado do ACM associado aos receptores.

• O nome DNS padrão dos balanceadores de carga está em uso. Não é possível usar o nome DNS padrão para fazer solicitações HTTPS, pois um certificado público não pode ser solicitado para o domínio *.amazonaws.com.

O balanceador de carga mostra tempos elevados de processamento

O balanceador de carga conta os tempos de processamento de maneira diferente com base na configuração.

• Se AWS WAF estiver associado ao seu Application Load Balancer e um cliente enviar uma solicitação HTTP POST, o tempo de envio dos dados para solicitações POST será refletido no request_processing_time campo nos registros de acesso do balanceador de carga. Espera-se esse comportamento para solicitações HTTP POST.

• Se não AWS WAF estiver associado ao seu Application Load Balancer e um cliente enviar uma solicitação HTTP POST, o tempo de envio dos dados para solicitações POST será refletido no target_processing_time campo nos registros de acesso do balanceador de carga. Espera-se esse comportamento para solicitações HTTP POST.

O load balancer envia um código de resposta de 000

Com conexões HTTP/2, se o tamanho comprimido de qualquer um dos cabeçalhos exceder 8 K ou se o número de solicitações enviado atendido por meio de uma conexão ultrapassar 10.000, o balanceador de carga enviará um quadro GOAWAY e fechará a conexão com um TCP FIN.

O load balancer gera um erro de HTTP

Os seguintes erros de HTTP são gerados pelo load balancer. O load balancer envia o código HTTP para o cliente, salva a solicitação no log de acesso e incrementa a métrica HTTPCode_ELB_4XX_Count ou HTTPCode_ELB_5XX_Count.

Erros

• HTTP 400: solicitação inválida
• HTTP 401: Não autorizado
• HTTP 403: negado
• HTTP 405: método não permitido
• HTTP 408: Request Timeout (HTTP 408: limite de tempo de solicitação)
• HTTP 413: carga útil muito grande
• HTTP 414: URI muito longo
• HTTP 460
• HTTP 463
• HTTP 464
• HTTP 500: erro interno do servidor
• HTTP 501: não implementado
• HTTP 502: Bad Gateway (HTTP 502: gateway incorreto)
• HTTP 503: Service Unavailable (HTTP 503: serviço indisponível)
• HTTP 504: Gateway Timeout (HTTP 504: limite de tempo do gateway)
• HTTP 505: versão incompatível
• HTTP 507: Armazenamento insuficiente
• HTTP 561: Não autorizado

HTTP 400: solicitação inválida

Causas possíveis:

• O cliente enviou uma solicitação malformada que não atende às especificações de HTTP.

• O cabeçalho de solicitação excedeu 16 K por linha de solicitação, 16 K por cabeçalho único ou 64 K para o cabeçalho da solicitação inteira.

• O cliente fechou a conexão antes de enviar o corpo completo da solicitação.

HTTP 401: Não autorizado

Você configurou uma regra de listener para autenticar usuários, mas uma das seguintes afirmações é verdadeira:

• Você configurou OnUnauthenticatedRequest para rejeitar usuários não autenticados ou o IdP negou acesso.

• O tamanho das solicitações retornadas pelo IdP excedeu o tamanho máximo permitido pelo load balancer.

• Um cliente enviou uma solicitação HTTP/1.0 sem um cabeçalho de host e o load balancer não conseguiu gerar uma URL de redirecionamento.

• O escopo solicitado não retorna um token de ID.

• Você não conclui o processo de login antes da expiração do tempo limite de login do cliente. Para obter mais informações, consulte Tempo limite de login do cliente.

HTTP 403: negado

Você configurou uma lista de controle de acesso à AWS WAF web (web ACL) para monitorar solicitações ao seu Application Load Balancer e ela bloqueou uma solicitação.

HTTP 405: método não permitido

O cliente usou o método TRACE, que não é compatível com Application Load Balancers.

HTTP 408: Request Timeout (HTTP 408: limite de tempo de solicitação)

O cliente não enviou dados antes que o tempo limite de inatividade expirasse. Enviar um keep-alive do TCP. não impede esse limite. Envie pelo menos 1 byte de dados antes que transcorra cada período de tempo limite de inatividade. Aumente a duração do período do tempo limite de inatividade conforme o necessário.

HTTP 413: carga útil muito grande

Causas possíveis:

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

• O cabeçalho de solicitação excedeu 16 K por linha de solicitação, 16 K por cabeçalho único ou 64 K para o cabeçalho da solicitação inteira.

HTTP 414: URI muito longo

A URL da solicitação ou os parâmetros da string de consulta são muito grandes.

HTTP 460

O load balancer recebeu uma solicitação de um cliente, mas o cliente encerrou a conexão com ele antes de decorrido o tempo limite de inatividade.

Verifique se o período de tempo de espera do cliente é maior do que o período de tempo limite de inatividade para o load balancer. Verifique se seu destino fornece uma resposta ao cliente antes do fim do tempo limite do cliente ou aumente o período do tempo limite do cliente de acordo com o tempo limite de inatividade do load balancer, se o cliente for compatível com este.

HTTP 463

O balanceador de carga recebeu um cabeçalho de solicitação X-Forwarded-For com muitos endereços IP. O limite superior para endereços IP é 30.

HTTP 464

O balanceador de carga recebeu um protocolo de solicitação de entrada que é incompatível com a configuração da versão do protocolo do grupo de destino.

Causas possíveis:

• O protocolo de solicitação é HTTP/1.1, enquanto a versão do protocolo do grupo de destino é gRPC ou HTTP/2.

• O protocolo de solicitação é gRPC, enquanto a versão do protocolo do grupo de destino é HTTP/1.1.

• O protocolo de solicitação é HTTP/2 e a solicitação não é POST, enquanto a versão do protocolo do grupo de destino é gRPC.

HTTP 500: erro interno do servidor

Causas possíveis:

• Você configurou uma lista de controle de acesso à AWS WAF web (Web ACL) e houve um erro ao executar as regras da Web ACL.

• O load balancer não consegue se comunicar com o endpoint de token do IdP ou o endpoint de informações do usuário do IdP.

  • Verifique se é possível resolver o DNS do IdP publicamente.

  • Verifique se os security groups para seu load balancer e as ACLs de rede para a VPC permitem que acesso de saída a esses endpoints.

  • Verifique se a VPC tem acesso à Internet. Se você tiver um load balancer interno, use um gateway NAT para permitir acesso à internet.

• A reivindicação do usuário recebida do IdP tem tamanho superior a 11 KB.

HTTP 501: não implementado

O load balancer recebeu um cabeçalho Transfer-Encoding (Codificação de transferência) com um valor não compatível. Os valores compatíveis para Transfer-Encoding (Codificação de transferência) são chunked e identity. Como alternativa, você pode usar o cabeçalho Content-Encoding.

HTTP 502: Bad Gateway (HTTP 502: gateway incorreto)

Causas possíveis:

• O load balancer recebeu um TCP RST do destino ao tentar estabelecer uma conexão.

• O load balancer recebeu uma resposta inesperada do destino, como "ICMP Destination unreachable (Host unreachable)" (Destino ICMP inacessível (Host inacessível)), ao tentar estabelecer uma conexão. Verifique se o tráfego é permitido das sub-redes do load balancer para os destinos na porta de destino.

• O destino fechou a conexão com um TCP RST ou TCP FIN enquanto o load balancer tinha uma solicitação pendente para o destino. Verifique se a duração de keep-alive do destino é mais curta que o valor do tempo limite de inatividade do load balancer.

• A resposta de destino é malformada ou contém cabeçalhos HTTP inválidos.

• O cabeçalho de resposta de destino excedeu 32 K para o cabeçalho de resposta inteiro.

• O período de atraso no cancelamento do registro decorrido para uma solicitação processada por um destino que foi cancelado. Aumente o período de atraso para que operações demoradas possam ser concluídas.

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

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

• O destino é uma função do Lambda que retornou um erro ou a função passou por controle de utilização pelo serviço Lambda.

• O balanceador de carga encontrou um erro de handshake SSL ao se conectar a um destino.

Para obter mais informações, consulte Como solucionar erros HTTP 502 do Application Load Balancer no AWS Support Knowledge Center.

HTTP 503: Service Unavailable (HTTP 503: serviço indisponível)

Os grupos de destino para o load balancer não têm destinos registrados.

HTTP 504: Gateway Timeout (HTTP 504: limite de tempo do gateway)

Causas possíveis:

• O load balancer não conseguiu estabelecer uma conexão com o destino antes da expiração do tempo limite de conexão (10 segundos).

• O load balancer estabeleceu uma conexão com o destino, mas o destino não respondeu antes de decorrido o tempo limite de inatividade.

• A Network ACL para a sub-rede não permite tráfego dos destinos para os nós do load balancer nas portas efêmeras (1024-65535).

• O destino retorna um cabeçalho content-length maior do que o corpo da entidade. O load balancer atingiu o tempo limite enquanto aguardava pelos bytes faltantes.

• O destino é uma função do Lambda e o serviço do Lambda não respondeu antes da expiração do tempo limite da conexão.

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

HTTP 505: versão incompatível

O balanceador de carga recebeu uma solicitação inesperada de versão HTTP. Por exemplo, o balanceador de carga estabeleceu uma conexão HTTP/1, mas recebeu uma solicitação HTTP/2.

HTTP 507: Armazenamento insuficiente

O URL de redirecionamento é muito longo.

HTTP 561: Não autorizado

Você configurou uma regra do listener para autenticar usuários, mas o IdP retornou um código de erro ao autenticar o usuário. Verifique seus logs de acesso para ver o código do motivo do erro relacionado.

Um destino gera um erro HTTP

O load balancer encaminhará respostas HTTP válidas dos destinos para o cliente, incluindo erros de HTTP. Os erros HTTP gerados por um destino são registrados nas métricas HTTPCode_Target_4XX_Count e HTTPCode_Target_5XX_Count.

Um AWS Certificate Manager certificado não está disponível para uso

Ao decidir usar um ouvinte HTTPS com seu Application Load Balancer AWS Certificate Manager , é necessário validar a propriedade do domínio antes de emitir um certificado. Se essa etapa for omitida durante a configuração, o certificado permanecerá no estado Pending Validation e não estará disponível para uso até que seja validado.

• Se estiver usando a validação de e-mail, consulte Validação de e-mail no Guia do usuário do AWS Certificate Manager .

• Se estiver usando a validação de DNS, consulte Validação de DNS no Guia do usuário do AWS Certificate Manager .

Não há compatibilidade com cabeçalhos de várias linhas.

Os Application Load Balancers não são compatíveis com cabeçalhos de várias linhas, incluindo o cabeçalho do tipo de mídia message/http. Quando um cabeçalho de várias linhas é fornecido, o Application Load Balancer acrescenta um caractere de dois pontos, “:”, antes de transmiti-lo para o destino.