Solucionar problemas nos Application Load Balancers - Elastic Load Balancing

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Solucionar problemas nos Application Load Balancers

As informações a seguir podem ajudá-lo a solucionar problemas com seu 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 obter 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 de destino foi malformado ou houve um erro ao se conectar ao destino

Verifique se o aplicativo responde às solicitações de verificação de integridade do balanceador de carga. Alguns aplicativos requerem configuração adicional para responder a 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. Por exemplo, se o endereço IP privado do destino for10.0.0.10E a porta de verificação de integridade é8080, o cabeçalho Host HTTP enviado pelo balanceador de carga em verificações de integridade éHost: 10.0.0.10:8080. Uma configuração de host virtual para responder a esse host, ou a uma configuração padrão, pode ser necessária para verificar a integridade do aplicativo com êxito. As solicitações de verificação de Health têm os seguintes atributos: oUser-Agenté definido comoELB-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 podem se conectar a um load balancer voltado para a Internet

Se o load balancer não estiver respondendo as solicitações, verifique os seguintes problemas:

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

Você deve especificar sub-redes públicas para seu load balancer. 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.

O load balancer envia solicitações a destinos não íntegros

Se houver pelo menos um destino íntegro em um grupo de destino, o load balancer roteará as solicitações somente aos destinos íntegros. Se um grupo de destino contiver apenas destinos não íntegros, o load balancer roteará as solicitações aos destinos não íntegros.

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 bytes ou se o número de solicitações atendidas por uma conexão exceder 10.000, o load balancer enviará um quadro GOAWAY e fechará a conexão com um FIN TCP.

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.

HTTP 400: Pedido inválido

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 16K por linha de solicitação, 16K por um cabeçalho único ou 64K para o cabeçalho inteiro.

HTTP 401: Não autorizado

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

  • Você configurouOnUnauthenticatedRequestPara recusar 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 que o tempo limite de login do cliente expire. Para obter mais informações, consulteTempo limite de login do cliente.

HTTP 403: Proibido

Você configurou umAWS WAFLista de controle de acesso da Web (ACL da Web) para monitorar as solicitações do 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: Tempo limite da 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

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

HTTP 414: Um 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 umX-Forwarded-Forcabeçalho de solicitação 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 incompatível com a configuração de versão do protocolo do grupo de destino.

Causas possíveis:

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

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

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

HTTP 500: Erro interno do servidor

Causas possíveis:

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

  • 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 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.

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: Pico inválido

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 load balancer encontrou um erro ou um tempo limite do handshake do SSL (10 segundos) ao se conectar a um destino.

  • 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 foi limitada pelo serviço do Lambda.

HTTP 503: Serviço indisponível

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

HTTP 504: Tempo limite 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.

HTTP 505: Versão não compatível

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

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.

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.