Como soluciono falhas de verificação de integridade do Application Load Balancer para tarefas do Amazon ECS no Fargate?

7 minuto de leitura
0

Quero resolver falhas na verificação de integridade do Application Load Balancer ao executar tarefas do Amazon Elastic Container Service (Amazon ECS) no AWS Fargate.

Breve descrição

Quando as tarefas do Amazon ECS falham nas verificações de integridade do Application Load Balancer, você pode receber um dos seguintes erros da mensagem de evento do serviço do Amazon ECS:

  • A solicitação atingiu o tempo limite
  • As verificações de integridade falharam sem códigos de erro
  • As verificações de integridade falharam com códigos de erro 404 ou 5xx
  • O destino está em uma zona de disponibilidade que não está ativada para o balanceador de carga

Para falhas nas verificações de integridade do contêiner, consulte How do I troubleshoot the container health check failures for Amazon ECS tasks? (Como soluciono as falhas na verificação de integridade do contêiner para tarefas do Amazon ECS?)

Se você estiver usando o Amazon ECS com instâncias de contêiner do Amazon Elastic Compute Cloud (Amazon EC2), consulte a seguinte documentação:

Resolução

Observação: Se você receber erros ao executar comandos da AWS Command Line Interface (AWS CLI), confirme se está executando uma versão recente da AWS CLI. Nos seguintes comandos da AWS CLI, substitua os valores de exemplo pelos seus valores.

Erro de tempo limite da solicitação

Verifique os grupos de segurança para garantir que o balanceador de carga possa fazer solicitações de verificação de integridade para a tarefa do Fargate. O grupo de segurança de tarefas do Fargate deve permitir tráfego de entrada e saída na porta do contêiner especificada na definição da tarefa. A origem deve ser o grupo de segurança do Application Load Balancer. O grupo de segurança do Application Load Balancer deve permitir tráfego de saída para o grupo de segurança de tarefas do Fargate.

Observação: É uma prática recomendada configurar diferentes grupos de segurança para a tarefa do Fargate e o balanceador de carga a fim de permitir o tráfego entre eles.

Se os grupos de segurança permitirem a comunicação entre sua tarefa do Fargate e o Application Load Balancer, verifique seu HealthCheckTimeoutSeconds nas configurações de verificação de integridade. Aumente o tempo limite em alguns segundos, se necessário.

Observação: Aumente HealthCheckTimeoutSeconds somente se seu aplicativo demorar muito para responder a uma verificação de integridade.

Para verificar o tempo médio de resposta, execute o seguinte comando:

$ time curl -Iv http://<example-task-pvt-ip>:<example-port>/<example_healthcheck_path>

Observação: A alta utilização de recursos nas tarefas pode causar lentidão ou paralisação do processo e resultar em uma falha na verificação de integridade.

As verificações de integridade falharam sem códigos de erro

Exemplo de mensagem de erro de falha na verificação de integridade:

(service AWS-service) (port 80) is unhealthy in (target-group arn:aws:elasticloadbalancing:us-east-1:111111111111:targetgroup/aws-targetgroup/123456789) due to (reason Health checks failed)

Se você receber uma mensagem de erro semelhante, verifique se a tarefa responde rapidamente após o início no Amazon ECS. Além disso, verifique se o aplicativo responde com o código de resposta correto.

Certifique-se de que a tarefa tenha tempo para responder depois de iniciar no Amazon ECS

Para garantir que a tarefa tenha tempo suficiente para responder após o início, aumente healthCheckGracePeriodSeconds. Isso permite que o Amazon ECS retenha a tarefa por um período mais longo e ignore as verificações de integridade não íntegras do destino do Elastic Load Balancing.

Observação: Se você estiver criando um novo serviço, poderá configurar o período de carência da verificação de integridade na página de configuração do balanceador de carga.

Para atualizar healthCheckGracePeriodSeconds para seu serviço Amazon ECS existente, execute o seguinte comando:

$ aws ecs update-service --cluster <EXAMPLE-CLUSTER-NAME> --service <EXAMPLE-SERVICE-NAME> --region <EXAMPLE-REGION> --health-check-grace-period-seconds <example-value-in-seconds>

Verifique se o aplicativo responde com o código de resposta correto

Para confirmar o código de resposta que seu aplicativo enviou no caminho da verificação de integridade, use os métodos a seguir.

Se você configurou o log de acesso em seu aplicativo, use ELB-HealthChecker/2.0 para verificar a resposta. Se você estiver usando AWS CloudWatch Logs, use CloudWatch Logs Insights e execute o seguinte comando:

fields @timestamp, @message
  | sort @timestamp desc
  | filter @message like /ELB-HealthChecker/

Para instâncias do Amazon EC2 na mesma Amazon Virtual Private Cloud (Amazon VPC), execute os seguintes comandos para confirmar se suas tarefas respondem às verificações manuais. Para iniciar uma nova instância do Amazon EC2, consulte o Tutorial: Comece a usar as instâncias Linux do Amazon EC2.

Verificações de integridade HTTP

$ curl -Iv http://<example-task-pvt-ip>:<example-port>/<example_healthcheck_path>

Verificações de integridade de HTTPS

$ curl -Iv https://<example-task-pvt-ip>:<example-port>/<example_healthcheck_path>

Se as tarefas pararem rapidamente e você não conseguir obter os endereços IP privados, inicie uma tarefa independente fora do Amazon ECS para solucionar o problema. Use a mesma definição de tarefa e execute um comando curl em seu endereço IP para iniciar a tarefa. A tarefa não para devido a uma falha na verificação de integridade.

Além disso, use Amazon ECS Exec para verificar as portas de escuta no nível do contêiner. Usando netstat, confirme se o aplicativo está escutando na porta apropriada:

$ netstat -tulpn | grep LISTEN

As verificações de integridade falharam com códigos de erro 404 ou 5xx

O recebimento de falhas na verificação de integridade com códigos de erro 404 ou 5xx indica que a solicitação de verificação de integridade foi confirmada, mas recebeu um código de resposta inválido. Os códigos também indicam que o código de resposta enviado pelo aplicativo não corresponde ao código de sucesso configurado no nível do grupo de destino (parâmetro: Matcher).

Um código de erro 404 pode ocorrer quando um caminho de verificação de integridade não existe ou há um erro de digitação na configuração desse caminho. Um código de erro 5xx pode ocorrer quando o aplicativo que está dentro da tarefa não está respondendo corretamente à solicitação ou quando há um erro de processamento.

Para determinar se o aplicativo está sendo iniciado com êxito, verifique os logs do aplicativo.

O destino está em uma zona de disponibilidade que não está ativada para o balanceador de carga

Quando uma zona de disponibilidade é ativada para seu balanceador de carga, o balanceamento de carga elástico cria um nó de balanceador de carga na zona de disponibilidade. Se você registrar destinos em uma zona de disponibilidade e não ativar a zona de disponibilidade, os destinos registrados não receberão tráfego. Para mais informações, consulte Zonas de disponibilidade e nós do balanceador de carga.

Para identificar as zonas de disponibilidade para as quais seu balanceador de carga está configurado, execute o seguinte comando:

aws elbv2 describe-load-balancers --load-balancer-arns <EXAMPLE-ALB-ARN> --query 'LoadBalancers[*].AvailabilityZones[].{Subnet:SubnetId}'

Para identificar as zonas de disponibilidade para as quais sua tarefa do Fargate está configurada, execute o seguinte comando:

aws ecs describe-services --cluster <EXAMPLE-CLUSTER-NAME> --service <EXAMPLE-SERVICE-NAME> --query 'services[*].deployments[].networkConfiguration[].awsvpcConfiguration.{Subnets:subnets}'

Observação: Use o comando update-service da AWS CLI para alterar a configuração da sub-rede de um serviço do Amazon ECS. Use o comando enable-availability-zones-for-load-balancer da AWS CLI para adicionar uma zona de disponibilidade a um Application Load Balancer existente.

Informações relacionadas

Solução de problemas de balanceadores de carga de serviço

Verificações de integridade para seus grupos de destino

AWS OFICIAL
AWS OFICIALAtualizada há um ano