Comment résoudre les problèmes liés à l’échec de la surveillance de l’état de mon Application Load Balancer ?

Résolution

Pour résoudre les problèmes liés à l'échec des surveillances de l'état de votre application Load Balancer, vous pouvez exécuter le dossier d'exploitation AWSSupport-TroubleshootELBHealthChecks. Le dossier d'exploitation automatise l'analyse des métriques de surveillance de l'état à partir de votre tableau de bord Amazon CloudWatch. Le dossier d'exploitation valide également les configurations réseau entre l’Application Load Balancer et vos cibles. Pour les cibles gérées par AWS Systems Manager, le dossier d'exploitation fournit des commandes de diagnostic avancées avec conservation facultative des journaux dans Amazon S3. La solution du dossier d'exploitation s'applique au type de cible d’instance.

Vous pouvez également utiliser la carte des ressources de l'Application Load Balancer pour afficher les ressources de l'équilibreur de charge et identifier les cibles non saines. La carte des ressources affiche toutes les ressources de l'Application Load Balancer sur une seule page.

Remarque : si la réponse HTTP cible de l'Application Load Balancer n'est pas la réponse attendue, vérifiez la réponse de votre application. Vérifiez que l'application envoie la bonne réponse à l'équilibreur de charge.

En fonction du code du motif de surveillance de l'état que vous avez trouvé, effectuez les actions de dépannage suivantes.

Elb.InitialHealthChecking

La cible doit passer la phase initiale de la surveillance de l’état avant de pouvoir recevoir des demandes de l’équilibreur de charge. Patientez jusqu’à ce que votre cible ait passé la phase initiale de la surveillance de l’état, puis vérifiez à nouveau son état.

Elb.RegistrationInProgress

L’enregistrement de la cible est en cours. Attendez que l'enregistrement soit terminé et que la cible réussisse les surveillances de l'état initiales. L'équilibreur de charge achemine automatiquement les demandes vers la cible une fois qu'il l'a enregistrée.

Target.DeregistrationInProgress

Le groupe cible supprime la cible. L'équilibreur de charge arrête les nouvelles requêtes adressées à la cible au fur et à mesure qu'il traite les requêtes en cours. Le délai de désenregistrement par défaut est de 300 secondes. Pour vérifier ou modifier la valeur du délai, consultez la section Délai de désenregistrement.

Target.FailedHealthChecks

Lancez ou utilisez une instance Amazon Elastic Compute Cloud (Amazon EC2) disponible dans le même cloud privé virtuel (VPC) que l'instance cible. Vérifiez que vous avez bien accès à cette instance. Pour les cibles accessibles au public, exécutez la commande suivante pour envoyer une requête de surveillance de l’état directement à l'adresse IP publique de l'instance cible :

curl -vkso /dev/null HealthCheck_protocol://Target_IP:HealthCheck_port/HealthCheck_path

Remarque : remplacez Target_IP par l'adresse IP de l'instance cible, HealthCheck_port par le port de surveillance de l'état et HealthCheck_path par le chemin de surveillance de l'état. La commande précédente ignore l'équilibreur de charge pour tester la réponse de la cible

Pour vérifier comment votre application répond aux requêtes de surveillance de l'état de l'équilibreur de charge, exécutez la commande suivante pour simuler une requête de surveillance de l'état :

curl -H "User-Agent: ELB-HealthChecker/2.0" -I http://localhost:PORT/HEALTH_CHECK_PATH

Remarque : remplacez PORT par le numéro de port de l’application et HEALTH_CHECK_PATH par le chemin de surveillance de l'état.

Vérifiez que la réponse inclut un code d'état HTTP qui correspond au code de réussite que vous avez configuré. Le code de réussite par défaut est 200. Si vous ne pouvez pas utiliser curl, vérifiez que les journaux de l’application ne contiennent pas de requêtes provenant de l'agent utilisateur ELB-HealthChecker/2.0.

L'exemple suivant est une requête de surveillance de l'état type provenant de l'Application Load Balancer avec une réponse HTTP valide :

GET / HTTP/1.1
Host: 10.0.0.1:80
Connection: close
User-Agent: ELB-HealthChecker/2.0
Accept-Encoding: gzip, compressed

Remarque : dans l'exemple présenté ci-dessus, la valeur d'en-tête Host contient l'adresse IP privée de la cible, suivie du port de surveillance de l'état. Le paramètre User-agent est défini sur ELB-HealthChecker/2.0. Si votre application ne reçoit pas les requêtes de surveillance de l'état, ajoutez une entrée d'hôte virtuel par défaut qui correspond au port de surveillance de l'état.

Si vous avez connecté plusieurs interfaces réseau élastiques à votre cible, vérifiez que l’application écoute sur l’interface réseau appropriée. Pour vérifier l'interface utilisée par votre application, exécutez la commande suivante :

netstat -an | grep LISTEN

Vérifiez que le port de l’application utilise l’adresse IP d'interface appropriée. Pour plus d'informations sur le fonctionnement des interfaces réseau avec les différents types de cibles et sur la manière de les configurer correctement, consultez la section Type de cible.

Vérifiez que la cible fournit un certificat de serveur et une clé au format que vous avez spécifié dans la stratégie de sécurité d’Elastic Load Balancing. Vérifiez que la cible prend en charge les chiffrements correspondants et le protocole fourni par l'équilibreur de charge pour établir la liaison SSL/TLS.

Pour vérifier la prise en charge du chiffrement SSL/TLS, exécutez la commande suivante sur votre cible :

openssl s_client -connect your_target:443 -servername your_target

Remarque : remplacez your_target par votre cible.

Comparez les chiffrements pris en charge dans la sortie avec ceux répertoriés dans la stratégie de sécurité de votre équilibreur de charge.

Cibles Linux

Pour les cibles Linux, exécutez la commande suivante pour vérifier si votre service est actif et en cours d'exécution :

service httpd status

Remarque : remplacez httpd par le nom du service.

Recherchez actif dans la sortie.

Exemple de sortie :

Redirecting to /bin/systemctl status httpd.service
httpd.service - The Apache HTTP Server    
Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; preset: disabled)
Active: active (running) since Fri 2025-06-13 07:00:35 UTC; 16s ago ------------------------------------------------> server status
Docs: man:httpd.service(8)
Main PID: 10146 (httpd)
Status: "Total requests: 0; Idle/Busy workers 100/0;Requests/sec: 0; Bytes served/sec: 0 B/sec"
Tasks: 177 (limit: 9486)
Memory: 17.9M
CPU: 90ms
CGroup: /system.slice/httpd.service
├─10146 /usr/sbin/httpd -DFOREGROUND
├─10147 /usr/sbin/httpd -DFOREGROUND
├─10148 /usr/sbin/httpd -DFOREGROUND
├─10149 /usr/sbin/httpd -DFOREGROUND
└─10150 /usr/sbin/httpd -DFOREGROUND

Jun 13 07:00:35 ip-172-16-1-59.ec2.internal systemd[1]: Starting httpd.service - The Apache HTTP Server...
Jun 13 07:00:35 ip-172-16-1-59.ec2.internal systemd[1]: Started httpd.service - The Apache HTTP Server.
Jun 13 07:00:35 ip-172-16-1-59.ec2.internal httpd[10146]: Server configured, listening on: port 80 ---------------->listening port

Si le service s'affiche comme inactif ou défaillant, exécutez la commande suivante pour lancer le service :

service httpd start

Remarque : remplacez httpd par le nom du service.

Pour vérifier que les cibles Linux écoutent le trafic sur le port de surveillance de l'état, exécutez la commande suivante :

ss -nral | grep PORT_NUMBER

Remarque : remplacez PORT_NUMBER par le port de surveillance de l'état. Par exemple, utilisez 80 pour HTTP.

Exemple de sortie :

tcp LISTEN 0 511 * :80 * :*

Cibles Windows

Pour les cibles Windows, consultez l’onglet Services du Gestionnaire de tâches Windows. Si le service est arrêté, démarrez-le. Si Windows ne reconnaît pas le service, vérifiez si vous l'avez installé.

Pour vérifier que les cibles Windows écoutent le trafic sur le port de surveillance de l'état, exécutez la commande suivante :

netstat -an | findstr LISTEN | findstr :PORT_NUMBER

Remarque : remplacez PORT_NUMBER par le port de surveillance de l'état.

Target.InvalidState

Si la cible est une instance Amazon EC2, utilisez la console Amazon EC2 pour vérifier que l'instance est en cours d'exécution. Si l'instance n'est pas en cours d'exécution, démarrez-la manuellement. Si la cible n'est pas une instance EC2, vérifiez le statut de votre cible dans la console de gestion AWS pour le service.

Target.IpUnusable

Si votre cible est de type ip, vous ne devez pas choisir une adresse IP déjà utilisée par un équilibreur de charge. Pour confirmer votre adresse IP, procédez comme suit :

1. Ouvrez la console Amazon EC2.
2. Dans le volet de navigation, sélectionnez Instances.
3. Choisissez Action, puis sélectionnez Mise en réseau.
4. Sélectionnez Gérer les adresses IP.
5. Modifiez l'adresse IP privée principale.
6. Sélectionnez Enregistrer.
7. Redémarrez l'instance.

Target.NotInUse

Pour vérifier si vous avez configuré le groupe cible pour recevoir le trafic provenant de l'équilibreur de charge, procédez comme suit :

1. Ouvrez la console Amazon EC2.
2. Dans le volet de navigation, choisissez Équilibreurs de charge.
3. Sélectionnez votre équilibreur de charge.
4. Choisissez Action, puis sélectionnez Gérer les écouteurs.
5. Vérifiez que vous avez associé votre groupe cible à au moins un écouteur actif.

Pour mettre à jour une zone de disponibilité pour votre équilibreur de charge, consultez la section Mettre à jour les zones de disponibilité de votre Application Load Balancer.

Target.NotRegistered

Assurez-vous d'avoir enregistré la cible dans le groupe cible.

Target.ResponseCodeMismatch

Pour vérifier les codes de réussite, examinez la configuration de la surveillance de l'état afin d'identifier les codes de réussite attendus par votre équilibreur de charge. Ouvrez ensuite les journaux d'accès de votre serveur Web et vérifiez les codes de statut HTTP que votre application renvoie à l'équilibreur de charge. Assurez-vous que les codes correspondent aux codes de réussite configurés. Le code de réussite par défaut est 200, mais vous pouvez configurer un code de réussite personnalisé compris entre 200 et 499.

Vérifiez également que votre chemin ping existe et qu'il utilise un URI valide. La valeur par défaut est /.

Si les codes ne correspondent pas ou si le chemin ping n'est pas valide, mettez à jour les paramètres de votre application ou de votre surveillance de l'état avec les informations correctes.

Target.Timeout

Si vous parvenez à vous connecter, il est possible que la page cible ne réponde pas avant le délai imparti pour la surveillance de l’état. Pour les serveurs Web tels que NGINX et Internet Information Services (IIS), vous pouvez enregistrer le temps nécessaire au serveur pour répondre. Pour en savoir plus, consultez les pages Configuration de la journalisation sur le site Web de NGINX et Configurer la journalisation dans IIS sur le site Web de Microsoft.

Si vos requêtes de surveillance de l'état prennent plus de temps que le délai d'expiration configuré, utilisez une page cible contenant un contenu dynamique minimal. Pour modifier le chemin de surveillance de l’état, consultez la section Mettre à jour les paramètres de surveillance de l'état d'un groupe cible de l'Application Load Balancer.

Si vous ne parvenez pas à vous connecter, effectuez les actions suivantes :

• Utilisez le port de surveillance de l'état et le protocole de surveillance de l'état pour vérifier que le groupe de sécurité de l’instance cible autorise le trafic provenant de l'équilibreur de charge. Vous pouvez ajouter une règle au groupe de sécurité pour autoriser tout le trafic provenant du groupe de sécurité de l’équilibreur de charge.
• Assurez-vous que le groupe de sécurité de votre application Load Balancer autorise le trafic vers l'instance cible.
• Vérifiez que la liste de contrôle d'accès au réseau (ACL réseau) de l'instance cible autorise le trafic entrant sur le port de surveillance de l'état et le trafic sortant sur les ports éphémères (1024-65535).
• Vérifiez que l'ACL réseau du sous-réseau du nœud autorise le trafic entrant sur les ports éphémères et le trafic sortant sur la surveillance de l'état et les ports éphémères.
• Vérifiez si les pare-feux du système d'exploitation (OS) de la cible autorisent le trafic entrant et sortant.
• Vérifiez que la table de routage des sous-réseaux de la cible contient une entrée qui permet au trafic de surveillance de l’état de revenir vers l’équilibreur de charge.
• Vérifiez l'utilisation de la mémoire et du processeur de votre cible. Si l’utilisation de la mémoire ou du processeur est trop élevée, vous pouvez ajouter des cibles ou augmenter la capacité de votre groupe Auto Scaling Amazon EC2. Si votre cible est une instance Amazon EC2, remplacez-la par un type d'instance plus important.

Informations connexes

Résoudre les problèmes liés à vos Application Load Balancers