Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Surveillance de l’état des instances dans un groupe Auto Scaling Amazon EC2 Auto Scaling surveille en permanence l'état de santé des instances d'un groupe Auto Scaling afin de maintenir la capacité souhaitée. Toutes les instances d'un groupe Auto Scaling commencent par un `Healthy` statut. Les instances sont supposées être saines, sauf si Amazon EC2 Auto Scaling reçoit une notification indiquant qu'elles sont défectueuses. Il peut recevoir des notifications de différentes sources lorsqu'une instance devient défectueuse et doit être remplacée. Ces sources sont notamment les suivantes : + Amazon EC2 + Elastic Load Balancing + Treillis en VPC + Amazon EBS + Contrôles de santé personnalisés que vous définissez Lorsqu'Amazon EC2 Auto Scaling détermine qu'`InService`une instance n'est pas saine, il la remplace par une nouvelle instance afin de maintenir la capacité souhaitée du groupe. La nouvelle instance se lance à l'aide des paramètres actuels du groupe Auto Scaling et du modèle de lancement associé ou de la configuration du lancement. L'organigramme suivant illustre le processus de lancement d'une nouvelle instance dans un groupe Auto Scaling. Cela commence par le lancement de l'instance. Si le lancement réussit, l'instance est ajoutée au groupe Auto Scaling. Amazon EC2 Auto Scaling effectue ensuite des contrôles de santé sur l'instance à l'aide des contrôles d'état intégrés d'Amazon EC2 et, après une période de grâce, de tous les contrôles de santé facultatifs que vous avez activés pour le groupe. Ces bilans de santé se poursuivent périodiquement. Si l'un des contrôles de santé échoue, l'instance est remplacée. ![\[Un diagramme de haut niveau indiquant le début des bilans de santé.\]](http://docs.aws.amazon.com/fr_fr/autoscaling/ec2/userguide/images/how-health-checks-work.png) Des instances défectueuses peuvent également se produire lorsqu'une instance se ferme de manière inattendue, par exemple à la suite d'une interruption d'une instance Spot ou d'une résiliation manuelle par un utilisateur. Là encore, Amazon EC2 Auto Scaling lancera automatiquement une instance de remplacement dans ces cas afin de maintenir la capacité souhaitée. **Topics** + [À propos des surveillances de l’état de votre groupe Auto Scaling](health-checks-overview.md) + [Définir la période de grâce de la surveillance de l'état pour un groupe Auto Scaling](health-check-grace-period.md) + [Surveillez les instances Auto Scaling dont les volumes Amazon EBS sont altérés à l'aide de contrôles de santé](monitor-and-replace-instances-with-impaired-ebs-volumes.md) + [Configurez un bilan de santé personnalisé pour votre groupe Auto Scaling](set-up-a-custom-health-check.md) + [Afficher le motif des échecs d’une surveillance de l’état](replace-unhealthy-instance.md) + [Résoudre les problèmes liés aux instances défectueuses dans Amazon EC2 Auto Scaling](ts-as-healthchecks.md) # À propos des surveillances de l’état de votre groupe Auto Scaling Cette rubrique fournit une vue d'ensemble des types de bilans de santé disponibles et décrit les principales considérations relatives à l'intégration des contrôles de santé Amazon EC2 Auto Scaling à vos applications. **Topics** + [Type de surveillance de l'état](#available-health-checks) + [Surveillance de l'état Amazon EC2](#instance-health-detection) + [Surveillances de l'état Elastic Load Balancing](#elastic-load-balancing-health-checks) + [Surveillances de l’état de VPC Lattice](#vpc-lattice-health-checks) + [Comment Amazon EC2 Auto Scaling minimise les temps d'arrêt](#minimize-downtime) + [Contrôles de santé pour les cas dans une piscine chaude](#health-checks-for-instance-in-a-warm-pool) + [Considérations relatives à la surveillance de l'état](#health-check-considerations) ## Type de surveillance de l'état Amazon EC2 Auto Scaling peut déterminer l'état de santé d'`InService`une instance en utilisant un ou plusieurs des tests de santé suivants : **** | Type de surveillance de l'état | Ce qu'il vérifie | | --- | --- | | Vérifications de statut Amazon EC2 et événements planifiés | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/autoscaling/ec2/userguide/health-checks-overview.html) Il s'agit du type de surveillance de l'état par défaut pour un groupe Auto Scaling. | | Surveillances de l'état Elastic Load Balancing | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/autoscaling/ec2/userguide/health-checks-overview.html) Pour exécuter ce type de contrôle de santé, vous devez l'activer pour votre groupe Auto Scaling. | | Surveillances de l’état de VPC Lattice | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/autoscaling/ec2/userguide/health-checks-overview.html) Pour exécuter ce type de contrôle de santé, vous devez l'activer pour votre groupe Auto Scaling. | | Surveillances de l’état Amazon EBS | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/autoscaling/ec2/userguide/health-checks-overview.html) Pour exécuter ce type de contrôle de santé, vous devez l'activer pour votre groupe Auto Scaling. | | Surveillances d'état personnalisées | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/autoscaling/ec2/userguide/health-checks-overview.html) | ## Surveillance de l'état Amazon EC2 Après le lancement d’une instance, elle est attachée au groupe Auto Scaling et entre dans l’état `InService`. Pour plus d'informations sur les différents états de cycle de vie des instances dans un groupe Auto Scaling, consultez [Cycle de vie d'une instance Amazon EC2 Auto Scaling](ec2-auto-scaling-lifecycle.md). Amazon EC2 Auto Scaling vérifie périodiquement l'état de toutes les instances du groupe Auto Scaling pour s'assurer qu'elles fonctionnent et sont en bon état. **Contrôles des statuts** Par défaut, Amazon EC2 Auto Scaling utilise les résultats des vérifications de statut de l'instance Amazon EC2 et les vérifications de statut du système pour déterminer l'état d'une instance. Si l'instance se trouve dans un état Amazon EC2 autre que `running`, ou si son état pour les vérifications d'état passe à `impaired`, Amazon EC2 Auto Scaling considère que l'instance est défectueuse et la remplace. Même quand l'instance se trouve dans l'un des états suivants : + `stopping` + `stopped` + `shutting-down` + `terminated` Les contrôles de statut Amazon EC2 ne nécessitent aucune configuration spéciale et sont toujours activés. Pour plus d'informations, consultez la section [Types de vérifications de statut](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html#types-of-instance-status-checks) dans le guide de l'*utilisateur Amazon EC2*. **Important** Amazon EC2 Auto Scaling laisse les vérifications d'état échouer occasionnellement, sans prendre aucune mesure. Lorsqu'une vérification de statut échoue, Amazon EC2 Auto Scaling attend quelques minutes AWS pour résoudre le problème. Il ne marque pas immédiatement une instance comme `Unhealthy` lorsque son état pour les contrôles d’état devient `impaired`. En outre, EC2 Auto Scaling ne marque pas l'instance `Unhealthy` comme si une vérification `insufficient-data` de statut était renvoyée. Cependant, si Amazon EC2 Auto Scaling détecte qu'une instance n'est plus dans l'état `running`, cette situation est traitée comme un échec immédiat. Dans ce cas, il marque immédiatement l'instance comme telle `Unhealthy` et la remplace. **Événements planifiés** Amazon EC2 peut parfois planifier des événements sur vos instances pour qu'ils soient exécutés après un horodatage particulier. Pour plus d’informations, consultez [Événements planifiés pour vos instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-instances-status-check_sched.html) dans le *Guide de l’utilisateur Amazon EC2*. Si l'une de vos instances est affectée par un événement planifié, Amazon EC2 Auto Scaling considère que l'instance est défectueuse et la remplace. L'instance ne commence à s'arrêter que lorsque la date et l'heure spécifiées dans l'horodatage sont atteintes. ## Surveillances de l'état Elastic Load Balancing Lorsque vous activez les contrôles d'intégrité d'Elastic Load Balancing pour votre groupe Auto Scaling, Amazon EC2 Auto Scaling peut utiliser les résultats de ces tests pour déterminer l'état de santé d'une instance. Avant de pouvoir activer les contrôles de santé Elastic Load Balancing pour votre groupe Auto Scaling, vous devez configurer un équilibreur de charge Elastic Load Balancing et configurer un bilan de santé pour celui-ci afin de déterminer si vos instances sont saines. Pour de plus amples informations, veuillez consulter [Préparez-vous à connecter un équilibreur de charge Elastic Load Balancing](getting-started-elastic-load-balancing.md). Une fois que vous avez attaché l'équilibreur de charge à votre groupe Auto Scaling, voici ce qui se produit : + Amazon EC2 Auto Scaling enregistre les instances du groupe Auto Scaling auprès de l'équilibreur de charge. + Une fois qu'une instance a terminé son enregistrement, elle entre dans l'état `InService` et devient disponible pour une utilisation avec l'équilibreur de charge. Par défaut, Amazon EC2 Auto Scaling ignore les résultats des surveillances de l'état Elastic Load Balancing. Une fois que vous avez activé ces contrôles de santé pour votre groupe Auto Scaling, lorsqu'Elastic Load Balancing signale une instance enregistrée comme telle`Unhealthy`, Amazon EC2 Auto Scaling marque l'`Unhealthy`instance lors de son prochain contrôle de santé périodique et la remplace. Si le drainage de la connexion (délai d'annulation d'enregistrement) est activé pour votre équilibreur de charge, Amazon EC2 Auto Scaling attend soit la fin des demandes à la volée, soit l'expiration du délai maximal avant de mettre fin aux instances défectueuses. **Note** Pour obtenir des instructions sur la façon de connecter l'équilibreur de charge et d'activer les contrôles de santé d'Elastic Load Balancing pour votre groupe Auto Scaling, consultez[Associez un équilibreur de charge Elastic Load Balancing à votre groupe Auto Scaling](attach-load-balancer-asg.md). Lorsque vous activez les contrôles de santé d'Elastic Load Balancing pour un groupe, Amazon EC2 Auto Scaling peut remplacer les instances signalées par Elastic Load Balancing comme étant défectueuses, mais uniquement une fois que l'équilibreur de charge est dans `InService` cet état. Pour de plus amples informations, veuillez consulter [Vérifier l’état d’attachement de votre équilibreur de charge](load-balancer-status.md). ## Surveillances de l’état de VPC Lattice Par défaut, Amazon EC2 Auto Scaling ignore les résultats des surveillances de l’état de VPC Lattice. Vous pouvez éventuellement activer ces contrôles de santé pour votre groupe Auto Scaling. Après cette opération, lorsque VPC Lattice signale une instance enregistrée comme étant `Unhealthy`, Amazon EC2 Auto Scaling marque l’instance comme étant `Unhealthy` lors de sa prochaine surveillance de l’état périodique et la remplace. Le processus d’enregistrement des instances puis de vérification de leur état est le même que celui des surveillances de l’état Elastic Load Balancing. **Note** Pour savoir comment associer le groupe cible VPC Lattice et activer les contrôles de santé VPC Lattice pour votre groupe Auto Scaling, consultez. [Attacher un groupe cible VPC Lattice à votre groupe Auto Scaling](attach-vpc-lattice-target-group-asg.md) Lorsque vous activez les contrôles d'état de VPC Lattice pour un groupe, Amazon EC2 Auto Scaling peut remplacer les instances signalées par VPC Lattice comme étant défectueuses, mais uniquement une fois que le groupe cible est dans cet état. `InService` Pour de plus amples informations, veuillez consulter [Vérifier l’état d’attachement de votre groupe cible VPC Lattice](verify-target-group-attachment-status.md). ## Comment Amazon EC2 Auto Scaling minimise les temps d'arrêt Par défaut, les nouvelles instances sont mises en service en même temps que les instances existantes sont résiliées, ce qui peut empêcher l'acceptation de nouvelles demandes tant que les nouvelles instances ne sont pas pleinement opérationnelles. Si Amazon EC2 Auto Scaling détermine que des instances ne sont plus en cours d'exécution (ou si elles ont été `Unhealthy` marquées par [set-instance-health](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/set-instance-health.html)la commande), il les remplace immédiatement. Toutefois, si d'autres instances sont jugées défectueuses, Amazon EC2 Auto Scaling utilise l'approche suivante pour récupérer les pannes. Cette approche minimise les temps d'arrêt qui pourraient survenir en raison de problèmes temporaires ou de surveillances d'état mal configurées. + Si une activité de dimensionnement est en cours et que la capacité de votre groupe Auto Scaling est inférieure de 10 % ou plus à la capacité souhaitée, Amazon EC2 Auto Scaling attend l'activité de dimensionnement en cours avant de remplacer les instances défectueuses. + Lors de la montée en puissance, Amazon EC2 Auto Scaling attend que les instances passent une surveillance de l'état initiale. Il attend également la fin de la préparation de l'instance par défaut pour s'assurer que les nouvelles instances sont prêtes. + Une fois que le préchauffage des instances est terminé et que le groupe a atteint plus de 90 % de sa capacité souhaitée, Amazon EC2 Auto Scaling remplace les instances défectueuses comme suit : + Amazon EC2 Auto Scaling ne remplace que 10 % de la capacité souhaitée du groupe à la fois. Il le fait jusqu'à ce que toutes les instances défectueuses soient remplacées. + Lorsqu'il remplace des instances, il attend que les nouvelles instances passent une surveillance de l'état initiale. Il attend également la fin de la préparation de l'instance par défaut avant de poursuivre. **Note** Si la taille d'un groupe Auto Scaling est suffisamment petite pour que la valeur résultante de 10 % soit inférieure à un, Amazon EC2 Auto Scaling remplace les instances défectueuses une par une. Cela pourrait entraîner un certain temps d'arrêt pour le groupe. Vous pouvez modifier la valeur par défaut de 10 % en [définissant une politique de maintenance des instances](https://docs.aws.amazon.com//autoscaling/ec2/userguide/set-instance-maintenance-policy-on-group.html) afin de modifier le taux auquel Auto Scaling remplace les instances défectueuses. Cependant, Auto Scaling peut tout de même limiter le taux de signalement des instances comme étant défectueuses. Par exemple, si toutes les instances d'un groupe Auto Scaling sont signalées comme défectueuses par les bilans de santé d'Elastic Load Balancing et que l'équilibreur de charge est en bon `InService` état, Amazon EC2 Auto Scaling peut indiquer qu'un nombre moins élevé d'instances ne sont pas saines à la fois. Le nombre d'instances remplacées à la fois peut ainsi être bien inférieur aux 10 % appliqués dans d'autres scénarios. Cela vous laisse le temps de résoudre le problème sans qu'Amazon EC2 Auto Scaling ne mette automatiquement fin à l'ensemble du groupe. ## Contrôles de santé pour les cas dans une piscine chaude Amazon EC2 Auto Scaling effectue également des contrôles de santé sur les instances d'un pool chaud. Pour de plus amples informations, veuillez consulter [Afficher le statut de surveillance de l'état et les motifs des échecs de surveillances de l'état](warm-pools-health-checks-monitor-view-status.md). ## Considérations relatives à la surveillance de l'état Les points suivants sont à prendre en compte lors de l'utilisation des tests de santé Amazon EC2 Auto Scaling. + Si vous avez besoin que quelque chose se produise sur l'instance en cours de résiliation ou sur l'instance en cours de démarrage, vous pouvez utiliser des hooks de cycle de vie. Ces hooks vous permettent d'effectuer une action personnalisée quand Amazon EC2 Auto Scaling lance des instances ou les résilie. Pour de plus amples informations, veuillez consulter [Hooks de cycle de vie Amazon EC2 Auto Scaling](lifecycle-hooks.md). + Amazon EC2 Auto Scaling ne fournit pas de moyen de supprimer les contrôles d'état d'Amazon EC2 et les événements planifiés de ses surveillances de l'état. Si vous ne voulez pas que les instances soient remplacées, nous vous recommandons de suspendre le processus `ReplaceUnhealthy` et `HealthCheck` pour les groupes Auto Scaling individuels. Pour de plus amples informations, veuillez consulter [Suspendre et reprendre les processus Amazon EC2 Auto Scaling](as-suspend-resume-processes.md). + Pour rétablir manuellement l'état de santé d'une instance défectueuse`Healthy`, vous pouvez essayer d'utiliser la [set-instance-health](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/set-instance-health.html)commande. Si vous obtenez une erreur, c'est probablement parce que la résiliation de l'instance est déjà en cours. En général, le rétablissement de l'état de santé d'une instance à l'`Healthy`aide de la [set-instance-health](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/set-instance-health.html)commande n'est utile que dans les cas où le `ReplaceUnhealthy` processus ou le `Terminate` processus est suspendu. + Si vous devez dépanner une instance sans interférer avec les tests de santé, vous pouvez la mettre en `Standby` état. Amazon EC2 Auto Scaling n'effectue aucun contrôle de santé sur les instances en `Standby` état tant que vous ne les avez pas remises en service. Pour de plus amples informations, veuillez consulter [Supprimer temporairement des instances du groupe Auto Scaling](as-enter-exit-standby.md). + Lorsque l'instance est résiliée, les adresses IP Elastic associées sont dissociées et ne sont pas automatiquement associées à la nouvelle instance. Vous devez manuellement associer les adresses IP Elastic à la nouvelle instance, ou le faire automatiquement avec une solution basée sur le hook de cycle de vie. Pour plus d’informations, consultez la rubrique [Adresses IP Elastic](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html) dans le *Guide de l’utilisateur Amazon EC2*. + De la même façon, lorsque l'instance est résiliée, ses volumes EBS attachés sont détachés (ou supprimés selon l'attribut `DeleteOnTermination` du volume). Vous devez attacher manuellement ces volumes EBS à la nouvelle instance, ou le faire automatiquement avec une solution basée sur le hook de cycle de vie. Pour de plus amples informations, veuillez consulter la rubrique [Attacher un volume Amazon EBS à une instance](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-attaching-volume.html) dans le *Guide de l'utilisateur Amazon EBS*. # Définir la période de grâce de la surveillance de l'état pour un groupe Auto Scaling Lorsqu’une surveillance de l’état Amazon EC2 Auto Scaling détermine qu’une instance `InService` est défectueuse, il la remplace par une nouvelle instance. La période de grâce de la surveillance de l'état indique la durée minimale (en secondes) nécessaire pour maintenir une nouvelle instance en service avant de la résilier si elle devait être défectueuse. On peut citer comme cas d'utilisation la nécessité pour Amazon EC2 Auto Scaling de ne pas prendre de mesure si les surveillances de l'état Elastic Load Balancing échouent et que la cause réside dans le fait que l'instance est toujours en cours d'initialisation. Les surveillances de l'état Elastic Load Balancing s'exécutent en parallèle, à partir du moment où l'instance est enregistrée auprès de l'équilibreur de charge. La période de grâce empêche Amazon EC2 Auto Scaling de marquer vos `Unhealthy` instances nouvellement lancées et de les résilier inutilement si elles ne passent pas ces tests de santé immédiatement après leur entrée dans l'État. `InService` Dans la console, par défaut, la période de grâce de la surveillance de l'état est de 300 secondes lorsque vous créez un groupe Auto Scaling. Sa valeur par défaut est de 0 seconde lorsque vous créez un groupe Auto Scaling à l'aide du AWS CLI ou d'un SDK. La valeur 0 désactive la période de grâce de la surveillance de l’état. Lorsque cette valeur est trop élevée, l'efficacité des surveillances de l'état Amazon EC2 Auto Scaling est réduite. Si vous utilisez des Hooks de cycle de vie pour le lancement de l'instance, vous pouvez définir la valeur de la période de grâce de la surveillance de l'état sur 0. Grâce aux Hooks de cycle de vie, Amazon EC2 Auto Scaling permet de s'assurer que les instances sont toujours initialisées avant de passer à l'état `InService`. Pour de plus amples informations, veuillez consulter [Hooks de cycle de vie Amazon EC2 Auto Scaling](lifecycle-hooks.md). La période de grâce s'applique aux instances suivantes : + Instances récemment lancées + Instances remises en service après avoir été en veille + Instances que vous attachez manuellement au groupe **Important** Pendant la période de grâce de la surveillance de l’état, si Amazon EC2 Auto Scaling détecte qu’une instance n’est plus à l’état `running` Amazon EC2, il marque l’instance comme `Unhealthy` et la remplace. Par exemple, si vous arrêtez une instance dans un groupe Auto Scaling, elle est marquée comme `Unhealthy` et remplacée. ## Définir la période de grâce de la surveillance de l'état pour un groupe Vous pouvez définir la période de grâce de la surveillance de l'état pour des groupes Auto Scaling nouveaux et existants. ------ #### [ Console ] **Pour modifier le délai de grâce du bilan de santé d'un nouveau groupe** Lorsque vous créez le groupe Auto Scaling, entrez la durée (en secondes) sur la page **Configurer les options avancées**, **Health checks**, **Health check grace period**. Il s'agit de la durée pendant laquelle Amazon EC2 Auto Scaling doit attendre avant de vérifier l'état de santé d'une instance après son entrée dans `InService` cet état. ------ #### [ AWS CLI ] **Pour modifier le délai de grâce du bilan de santé d'un nouveau groupe** Ajoutez l'`--health-check-grace-period`option à la [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html)commande. L'exemple suivant configure la période de grâce de la surveillance de l'état avec une valeur de `60` secondes pour un nouveau groupe Auto Scaling nommé `my-asg`. ``` aws autoscaling create-auto-scaling-group --auto-scaling-group-name my-asg \ --health-check-grace-period 60 ... ``` ------ ------ #### [ Console ] **Pour modifier le délai de grâce du bilan de santé d'un groupe existant** 1. Ouvrez la console Amazon EC2 à l'adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/), puis sélectionnez **Auto Scaling Groups** dans le volet de navigation. 1. Dans la barre de navigation située en haut de l'écran, choisissez l' Région AWS dans laquelle vous avez créé votre groupe Auto Scaling. 1. Cochez la case située en regard du groupe Auto Scaling. Un volet fractionné s’ouvre en bas de la page. 1. Sous l’onglet **Détails** choisissez **Vérifications de l’états**, **Modifier**. 1. Dans le champ **Health check grace period** (Période de grâce de la surveillance de l'état), saisissez le délai en secondes. Il s'agit de la durée pendant laquelle Amazon EC2 Auto Scaling doit attendre avant de vérifier l'état de santé d'une instance après son entrée dans `InService` cet état. 1. Choisissez **Mettre à jour**. ------ #### [ AWS CLI ] **Pour modifier le délai de grâce du bilan de santé d'un groupe existant** Ajoutez l'`--health-check-grace-period`option à la [update-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/update-auto-scaling-group.html)commande. L'exemple suivant configure la période de grâce de la surveillance de l'état avec une valeur de `120` secondes pour un groupe Auto Scaling existant nommé `my-asg`. ``` aws autoscaling update-auto-scaling-group --auto-scaling-group-name my-asg \ --health-check-grace-period 120 ``` ------ **Note** Nous vous recommandons vivement de définir également le temps de préparation d'instance par défaut de votre groupe Auto Scaling. Pour de plus amples informations, veuillez consulter [Définir la préparation par défaut d'instance d'un groupe Auto Scaling](ec2-auto-scaling-default-instance-warmup.md). # Surveillez les instances Auto Scaling dont les volumes Amazon EBS sont altérés à l'aide de contrôles de santé Vous pouvez activer les contrôles de santé Amazon EBS pour votre groupe Auto Scaling afin de vous assurer qu'Amazon EC2 Auto Scaling surveille l'ensemble du système sur lequel votre application s'exécute. Une fois que vous avez activé ces contrôles de santé, Amazon EC2 Auto Scaling reçoit les résultats des contrôles d'état Amazon EC2 effectués sur les volumes EBS attachés à une instance. Si un volume n'est pas accessible ou ne passe pas les tests d' I/O état, le contrôle de santé échouera et l'instance correspondante sera considérée comme défectueuse. Lorsqu'Amazon EC2 Auto Scaling détecte une instance défectueuse, il la remplace. Cette rubrique suppose que vous connaissez les vérifications de statut EBS ci-jointes. Si ce n'est pas le cas, consultez la section [Contrôles de statut des fichiers EBS joints](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html#attached-ebs-status-checks) du guide de l'*utilisateur Amazon EC2* pour plus de détails. La rubrique suivante décrit comment activer les contrôles de santé Amazon EC2 Auto Scaling qui reposent sur les contrôles de statut EBS joints. **Note** Vous pouvez activer les contrôles de santé Amazon EBS pour tous vos groupes Auto Scaling. Toutefois, ces bilans de santé ne sont disponibles que pour les [instances basées sur le système AWS Nitro.](https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-nitro-instances.html) ## Activer les bilans de santé Amazon EBS pour un groupe Vous pouvez activer les contrôles de santé Amazon EBS pour les groupes Auto Scaling nouveaux et existants. ------ #### [ Console ] **Activer les bilans de santé Amazon EBS pour un nouveau groupe** Lorsque vous créez le groupe Auto Scaling, sur la page **Configurer les options avancées**, pour les bilans de **santé et les types de bilans** **de santé supplémentaires**, sélectionnez **Activer les bilans de santé Amazon EBS**. Ensuite, dans le champ **Période de grâce de la surveillance de l’état**, saisissez le délai en secondes. Ce délai correspond à la durée pendant laquelle Amazon EC2 Auto Scaling doit attendre avant de vérifier l'état de santé d'une instance après son entrée dans `InService` cet état. Pour de plus amples informations, veuillez consulter [Définir la période de grâce de la surveillance de l'état pour un groupe Auto Scaling](health-check-grace-period.md). ------ #### [ AWS CLI ] **Activer les bilans de santé Amazon EBS pour un nouveau groupe** Ajoutez l'`--health-check-type`option à la [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html)commande. L'exemple suivant indique **`EBS`** l'`--health-check-type`option pour un nouveau groupe Auto Scaling nommé`my-asg`. ``` aws autoscaling create-auto-scaling-group --auto-scaling-group-name my-asg \ --health-check-type "EBS" --health-check-grace-period 60 ... ``` Vous pouvez spécifier plusieurs valeurs pour l'`--health-check-type`option. Par exemple, pour ajouter à la fois les types de tests de santé Amazon EBS et Elastic Load Balancing, utilisez la commande suivante. ``` aws autoscaling create-auto-scaling-group --auto-scaling-group-name my-asg \ --health-check-type "EBS,ELB" --health-check-grace-period 60 ... ``` Les noms de valeur sont sensibles à la casse. ------ ------ #### [ Console ] **Activer les contrôles de santé Amazon EBS pour un groupe existant** 1. Ouvrez la console Amazon EC2 à l'adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/), puis sélectionnez **Auto Scaling Groups** dans le volet de navigation. 1. Dans la barre de navigation située en haut de l'écran, choisissez l' Région AWS dans laquelle vous avez créé votre groupe Auto Scaling. 1. Activez la case à cocher en regard d'un groupe existant. Un volet fractionné s'ouvre en bas de la page **Auto Scaling groups** (Groupes Auto Scaling). 1. Sous l’onglet **Détails** choisissez **Vérifications de l’états**, **Modifier**. 1. Pour les **bilans de santé** et les **types de bilans de santé supplémentaires**, sélectionnez **Activer les bilans de santé Amazon EBS**. 1. Dans le champ **Période de grâce de la surveillance de l’état**, saisissez le délai en secondes. Ce délai correspond à la durée pendant laquelle Amazon EC2 Auto Scaling doit attendre avant de vérifier l'état de santé d'une instance après son entrée dans `InService` cet état. Pour de plus amples informations, veuillez consulter [Définir la période de grâce de la surveillance de l'état pour un groupe Auto Scaling](health-check-grace-period.md). 1. Choisissez **Mettre à jour**. ------ #### [ AWS CLI ] **Activer les contrôles de santé Amazon EBS pour un groupe existant** Ajoutez l'`--health-check-type`option à la [update-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/update-auto-scaling-group.html)commande. L'exemple suivant indique `EBS` l'`--health-check-type`option pour un groupe Auto Scaling existant nommé`my-asg`. ``` aws autoscaling update-auto-scaling-group --auto-scaling-group-name my-asg \ --health-check-type "EBS" --health-check-grace-period 60 ``` Pour utiliser plusieurs types de bilans de santé, vous pouvez spécifier plusieurs valeurs (par exemple,`EBS,ELB`) pour l'`--health-check-type`option. Les noms de valeur sont sensibles à la casse. ------ # Désactiver les contrôles de santé Amazon EBS pour un groupe Auto Scaling La rubrique suivante explique comment désactiver les contrôles de santé Amazon EBS pour un groupe Auto Scaling. Si vous n'avez plus besoin des bilans de santé Amazon EBS, suivez la procédure ci-dessous pour les désactiver. ------ #### [ Console ] **Désactiver les contrôles de santé Amazon EBS pour un groupe** 1. Ouvrez la console Amazon EC2 à l'adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/), puis sélectionnez **Auto Scaling Groups** dans le volet de navigation. 1. Activez la case à cocher en regard d'un groupe existant. Un volet fractionné s'ouvre en bas de la page **Auto Scaling groups** (Groupes Auto Scaling). 1. Sous l’onglet **Détails** choisissez **Vérifications de l’états**, **Modifier**. 1. Pour les **bilans de santé** et les **types de bilans de santé supplémentaires**, désélectionnez **Activer les bilans de santé Amazon EBS**. 1. Choisissez **Mettre à jour**. ------ #### [ AWS CLI ] **Désactiver les contrôles de santé Amazon EBS pour un groupe** Pour mettre à jour les contrôles de santé d'un groupe Auto Scaling afin qu'il n'utilise plus les contrôles de santé Amazon EBS, utilisez la [update-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/update-auto-scaling-group.html)commande. Incluez l’option `--health-check-type` et une valeur de`EC2`. ``` aws autoscaling update-auto-scaling-group --auto-scaling-group-name my-asg \ --health-check-type "EC2" ``` Pour désactiver les bilans de santé d'Amazon EBS sans désactiver les autres types de contrôles de santé (tels que Elastic Load Balancing), vous devez les spécifier à la place de`EC2`. Par exemple, pour les tests de santé d'Elastic Load Balancing, spécifiez `ELB` l'`--health-check-type`option. Les noms de valeur sont sensibles à la casse. ------ # Configurez un bilan de santé personnalisé pour votre groupe Auto Scaling Vous pouvez utiliser des bilans de santé personnalisés pour compléter les options de contrôle de santé existantes proposées par Amazon EC2 Auto Scaling. En combinant des bilans de santé personnalisés avec les autres types de bilans de santé, vous pouvez créer un système complet de surveillance de l'état adapté aux besoins de votre application. Pour commencer, créez des tests personnalisés pour vérifier que les instances de votre groupe Auto Scaling fonctionnent correctement et peuvent gérer le trafic entrant. Si le bilan de santé que vous configurez détecte qu'une instance ne répond pas, marquez cette instance en particulier comme telle`Unhealthy`, ce qui oblige Amazon EC2 Auto Scaling à la remplacer immédiatement. Vous pouvez envoyer l'état de santé d'une instance directement à Amazon EC2 Auto Scaling à l'aide AWS CLI du ou d'un SDK. Les exemples suivants vous montrent comment utiliser le AWS CLI pour configurer l'état de santé d'une instance, puis vérifier l'état de santé de l'instance. Utilisez la [set-instance-health](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/set-instance-health.html)commande suivante pour définir l'état de santé de l'instance spécifiée sur`Unhealthy`. ``` aws autoscaling set-instance-health --instance-id i-1234567890abcdef0 --health-status Unhealthy ``` Par défaut, cette commande respecte la période de grâce de la surveillance de l'état. Toutefois, vous pouvez remplacer ce comportement et ne pas respecter la période de grâce en incluant l'option `--no-should-respect-grace-period`. Utilisez la [describe-auto-scaling-groups](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-auto-scaling-groups.html)commande suivante pour vérifier que l'état de santé de l'instance est correct`Unhealthy`. ``` aws autoscaling describe-auto-scaling-groups --auto-scaling-group-names my-asg ``` Voici un exemple de réponse qui indique que l'état de santé de l'instance est bon et que l'instance est `Unhealthy` sur le point de se terminer. ``` { "AutoScalingGroups": [ { .... "Instances": [ { "ProtectedFromScaleIn": false, "AvailabilityZone": "us-west-2a", "LaunchTemplate": { "LaunchTemplateName": "my-launch-template", "Version": "1", "LaunchTemplateId": "lt-1234567890abcdef0" }, "InstanceId": "i-1234567890abcdef0", "InstanceType": "t2.micro", "HealthStatus": "Unhealthy", "LifecycleState": "Terminating" }, ... ] } ] } ``` # Afficher le motif des échecs d’une surveillance de l’état À l’aide de la procédure suivante, vous pouvez consulter les informations relatives à toutes les instances remplacées à la suite d’une surveillance de l’état. Par défaut, Amazon EC2 Auto Scaling crée une nouvelle activité de mise à l’échelle pour résilier l’instance défectueuse, puis la résilie. Pendant que l'instance est résiliée, une autre activité de mise à l'échelle lance une nouvelle instance. Vous pouvez modifier ce comportement pour commencer à lancer une nouvelle instance dès que possible en utilisant une politique de maintenance des instances. Pour de plus amples informations, veuillez consulter [Politiques de maintenance des instances](ec2-auto-scaling-instance-maintenance-policy.md). ------ #### [ Console ] **Affichage de la raison des échecs du bilan de santé** 1. Ouvrez la console Amazon EC2 à l'adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/), puis sélectionnez **Auto Scaling Groups** dans le volet de navigation. 1. Cochez la case située en regard du groupe Auto Scaling. Un volet fractionné s'ouvre en bas de la page **Auto Scaling groups** (Groupes Auto Scaling). 1. Sous l'onglet **Activity** (Activité) sous **Activity history** (Historique des activités), la colonne **Status** (État) indique si votre groupe Auto Scaling a réussi à lancer ou à résilier des instances. Si des instances malsaines sont interrompues, la colonne **Cause** indique la date et l'heure de l'interruption et le motif de l'échec de la surveillance de l'état. Par exemple, `At 2022-05-14T20:11:53Z an instance was taken out of service in response to a user health-check`. Ce message indique qu'un contrôle de santé personnalisé a indiqué que l'instance était défectueuse. Pour obtenir de l'aide en cas d'échec du bilan de santé, consultez[Résoudre les problèmes liés aux instances défectueuses dans Amazon EC2 Auto Scaling](ts-as-healthchecks.md). ------ #### [ AWS CLI ] **Affichage de la raison des échecs du bilan de santé** Utilisez la commande [describe-scaling-activities](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-scaling-activities.html) suivante. ``` aws autoscaling describe-scaling-activities --auto-scaling-group-name my-asg ``` Voici un exemple de réponse `Cause` contenant la raison de l'échec du bilan de santé. ``` { "Activities": [ { "ActivityId": "4c65e23d-a35a-4e7d-b6e4-2eaa8753dc12", "AutoScalingGroupName": "my-asg", "Description": "Terminating EC2 instance: i-04925c838b6438f14", "Cause": "At 2021-04-01T21:48:35Z an instance was taken out of service in response to a user health-check.", "StartTime": "2021-04-01T21:48:35.859Z", "EndTime": "2021-04-01T21:49:18Z", "StatusCode": "Successful", "Progress": 100, "Details": "{\"Subnet ID\":\"subnet-5ea0c127\",\"Availability Zone\":\"us-west-2a\"...}", "AutoScalingGroupARN": "arn:aws:autoscaling:us-west-2:123456789012:autoScalingGroup:283179a2-f3ce-423d-93f6-66bb518232f7:autoScalingGroupName/my-asg" }, ... ] } ``` Pour obtenir une description des champs de la sortie, consultez [Activité](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_Activity.html) dans la *Référence de l'API Amazon EC2 Auto Scaling*. Pour décrire les activités de dimensionnement après la suppression du groupe Auto Scaling, ajoutez l'`--include-deleted-groups`option à la [describe-scaling-activities](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-scaling-activities.html)commande. ------ # Résoudre les problèmes liés aux instances défectueuses dans Amazon EC2 Auto Scaling Vous trouverez ci-dessous les messages d'erreur renvoyés par Amazon EC2 Auto Scaling, les causes potentielles et les mesures que vous pouvez prendre pour résoudre les problèmes. Pour récupérer un message d'erreur, consultez [Afficher le motif des échecs d’une surveillance de l’état](replace-unhealthy-instance.md). **Topics** + [Une instance a été mise hors service en réponse à un échec de surveillance de l'état de l'instance EC2](#ts-failed-status-checks) + [Une instance a été mise hors service en réponse à une surveillance de l'état EC2 qui indiquait qu'elle avait été résiliée ou arrêtée](#ts-terminated-or-stopped) + [Une instance a été mise hors service en réponse à une défaillance de la surveillance de l'état du système ELB](#ts-failed-elb-health-checks) + [Ressources supplémentaires](#troubleshoot-health-checks-additional-resources) ## Une instance a été mise hors service en réponse à un échec de surveillance de l'état de l'instance EC2 **Problème** : les instances Auto Scaling échouent aux surveillances de l'état d'Amazon EC2. **Cause 1** : Si des problèmes amènent Amazon EC2 à considérer que les instances de votre groupe Auto Scaling sont altérées, Amazon EC2 Auto Scaling remplace automatiquement les instances dans le cadre de ses bilans de santé. **Solution 1** : Lorsqu'une vérification de l'état d'une instance échoue, vous devez généralement résoudre le problème vous-même en modifiant la configuration de l'instance jusqu'à ce que votre application ne présente plus aucun problème. Pour résoudre ce problème, procédez comme suit : 1. Créez manuellement une instance Amazon EC2 qui ne fait pas partie du groupe Auto Scaling et examinez le problème. Pour obtenir de l'aide générale sur l'investigation des instances défectueuses, consultez la section [Résoudre les problèmes liés aux instances dont les vérifications de statut ont échoué](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstances.html) dans le guide de l'*utilisateur Amazon EC2*. 1. Après avoir confirmé que votre instance a été lancée avec succès et qu'elle est saine, déployez une nouvelle configuration d'instance sans erreur dans le groupe Auto Scaling. 1. Supprimez l'instance que vous avez créée pour éviter les frais continus de votre instance AWS . ## Une instance a été mise hors service en réponse à une surveillance de l'état EC2 qui indiquait qu'elle avait été résiliée ou arrêtée **Problème** : les instances Auto Scaling qui ont été arrêtées, redémarrées ou résiliées sont remplacées. **Cause 1** : un utilisateur a arrêté, redémarré ou résilié l'instance manuellement. **Solution 1** : si vous devez arrêter ou redémarrer les instances de votre groupe Auto Scaling, nous vous recommandons de les mettre d'abord en veille. Pour de plus amples informations, veuillez consulter [Supprimer temporairement des instances du groupe Auto Scaling](as-enter-exit-standby.md). **Cause 2** : Amazon EC2 Auto Scaling tente de remplacer les instances Spot après que le service Amazon EC2 Spot interrompe les instances, car le prix Spot augmente au-dessus de votre prix maximum ou capacité n'est plus disponible. **Solution 2** : il n'y a aucune garantie qu'une instance Spot existe pour répondre à la demande à un moment donné. Cependant, vous pouvez essayer l'une des actions suivantes : + Utilisez un prix maximum Spot plus élevé (éventuellement prix à la demande). En fixant votre prix maximum plus élevé, cela donne au service Amazon EC2 Spot plus de chances de lancer et de maintenir la quantité de capacité requise. + Augmentez le nombre de pools de capacités différents à partir desquels vous pouvez lancer des instances en exécutant plusieurs types d'instances dans plusieurs zones de disponibilité. Pour de plus amples informations, veuillez consulter [Groupes Auto Scaling combinant plusieurs types d'instances et options d'achat](ec2-auto-scaling-mixed-instances-groups.md). + Si vous utilisez plusieurs types d'instance, envisagez d'activer la fonction de Rééquilibrage de capacité. Ceci est utile si vous souhaitez que le service Amazon EC2 Ponctuel tente de lancer une nouvelle instance Spot avant qu'une instance en cours d'exécution ne soit résiliée. Pour de plus amples informations, veuillez consulter [Rééquilibrage des capacités dans Auto Scaling pour remplacer les instances ponctuelles à risque](ec2-auto-scaling-capacity-rebalancing.md). **Cause 3** : avec les blocs de capacité, Amazon EC2 met fin à toutes les instances encore en cours d'exécution 30 minutes avant l'heure de fin du bloc de capacité. Cette interruption abrupte pousse votre groupe Auto Scaling à essayer de lancer de nouvelles instances afin de maintenir la capacité souhaitée, même lorsque le bloc de capacité touche à sa fin. **Solution 3** : pour résoudre ce problème, essayez ce qui suit : + Diminuez la capacité souhaitée du groupe Auto Scaling pour l'empêcher d'essayer de lancer de nouvelles instances. Pour de plus amples informations, veuillez consulter [Mise à l'échelle manuelle pour Amazon EC2 Auto Scaling](ec2-auto-scaling-scaling-manually.md). + Assurez-vous de redimensionner votre groupe Auto Scaling 30 minutes avant l'heure de fin du Capacity Block afin de ne pas rencontrer cette erreur fréquemment. Assurez-vous que tous les hooks du cycle de vie sont terminés 30 minutes avant l'heure de fin du bloc de capacité. Pour de plus amples informations, veuillez consulter [Utilisation Capacity Blocks pour les charges de travail liées au machine learning](launch-template-capacity-blocks.md). ## Une instance a été mise hors service en réponse à une défaillance de la surveillance de l'état du système ELB **Problème** : les instances Auto Scaling peuvent réussir aux surveillances de l'état EC2. Cependant, elles peuvent échouer aux surveillances de l'état Elastic Load Balancing pour les groupes cibles ou les équilibreurs de charge classiques auprès desquels le groupe Auto Scaling est enregistré. **Cause 1** : si votre groupe Auto Scaling s'appuie sur les tests de santé fournis par Elastic Load Balancing, Amazon EC2 Auto Scaling détermine l'état de santé de vos instances en vérifiant les résultats des contrôles d'état EC2 et des tests de santé d'Elastic Load Balancing. L'équilibreur de charge effectue des surveillances de l'état en envoyant une requête à chaque instance et en attendant la réponse correcte, ou en établissant une connexion avec l'instance. Une instance peut ne pas réussir la surveillance de l'état Elastic Load Balancing, parce qu'une application s'exécutant sur l'instance connaît des problèmes faisant que l'équilibreur de charge considère l'instance comme étant hors service. **Solution 1** : pour réussir les surveillances de l'état Elastic Load Balancing : + Vérifiez que les paramètres de surveillance de l'état de vos groupes cibles sont correctement configurés. Vous définissez des paramètres de surveillance de l'état de votre équilibreur de charge pour chaque groupe cible. Pour de plus amples informations, veuillez consulter [Configuration des contrôles de santé pour les cibles](getting-started-elastic-load-balancing.md#elb-health-checks-for-targets). + Notez les codes de réussite attendus par l'équilibreur de charge et si votre application est configurée correctement pour renvoyer ces codes lorsque la surveillance de l'état est concluante. + Vérifiez que les groupes de sécurité de votre équilibreur de charge et de votre groupe Auto Scaling sont correctement configurés. + Vérifiez que l'équilibreur de charge est configuré dans les mêmes zones de disponibilité que votre groupe Auto Scaling. **Solution 2** : mettez à jour le groupe Auto Scaling pour désactiver les contrôles de santé d'Elastic Load Balancing. Pour savoir comment désactiver ces contrôles de santé, consultez [Detach a target group ou Classic Load Balancer](https://docs.aws.amazon.com//autoscaling/ec2/userguide/attach-load-balancer-asg.html#as-remove-load-balancer). **Cause 2** : il y a une discordance entre la période de grâce de surveillance de l'état et l'heure de démarrage de l'instance. **Solution 3** : modifier le délai de grâce du bilan de santé de votre groupe Auto Scaling. Définissez la période de grâce sur une période suffisamment longue pour prendre en charge le nombre de tests de santé réussis consécutifs requis avant qu'Elastic Load Balancing considère qu'une instance nouvellement lancée est saine. Pour de plus amples informations, veuillez consulter [Définir la période de grâce de la surveillance de l'état pour un groupe Auto Scaling](health-check-grace-period.md). ## Ressources supplémentaires Si vous rencontrez un autre problème, consultez les AWS re:Post articles suivants pour obtenir une aide supplémentaire en matière de résolution des problèmes : + [Pourquoi Amazon EC2 Auto Scaling a-t-il résilié une instance ?](https://repost.aws/knowledge-center/auto-scaling-instance-how-terminated) + [Pourquoi Amazon EC2 Auto Scaling n'a-t-il pas mis fin à une instance défectueuse ?](https://repost.aws/knowledge-center/auto-scaling-terminate-instance)