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 et création de rapports d'intégrité améliorée

La création de rapports d'état de santé amélioré est une fonction que vous pouvez activer sur votre environnement pour autoriser AWS Elastic Beanstalk à collecter des informations complémentaires sur les ressources de votre environnement. Elastic Beanstalk analyse les informations recueillies pour fournir un meilleur aperçu de l'état global de l'environnement et permettre l'identification des problèmes pouvant entraîner une indisponibilité de votre application.

En plus des modifications dans le mode de fonctionnement des couleurs d'état, l'état amélioré ajoute un descripteur statut qui fournit un indicateur de la gravité des problèmes observés lorsqu'un environnement est jaune ou rouge. Lorsque davantage d'informations sont disponibles sur l'état actuel, vous pouvez choisir le bouton Causes pour afficher des informations d'état détaillées sur la page d'état.

Pour fournir des informations détaillées sur l'état des instances Amazon EC2 s'exécutant dans votre environnement, Elastic Beanstalk inclut un agent de vérification de l'état dans l'AMI (Amazon Machine Image) pour chaque version de plateforme qui prend en charge les rapports améliorés sur l'état. L'agent de vérification de l'état surveille les journaux de serveur web et les métriques système et les transmet au service Elastic Beanstalk. Elastic Beanstalk analyse ces métriques et ces données issues d'Elastic Load Balancing et d'Amazon EC2 Auto Scaling pour fournir un aperçu global de l'état d'un environnement.

Outre la collecte et la présentation des informations relatives aux ressources de votre environnement, Elastic Beanstalk surveille les ressources de votre environnement pour plusieurs conditions d'erreur et fournit des notifications pour vous aider à éviter les défaillances et à résoudre les problèmes de configuration. Les facteurs susceptibles d'influer sur l'état de votre environnement incluent les résultats de chaque demande de votre application, les métriques du système d'exploitation de vos instances et l'état du déploiement le plus récent.

Vous pouvez afficher l'état de santé en temps réel en utilisant la page de présentation de l'environnement de la console Elastic Beanstalk ou la commande eb health de l'interface de ligne de commande Elastic Beanstalk. Pour enregistrer et suivre l'état de l'environnement et des instances sur la durée, vous pouvez configurer votre environnement de sorte à publier dans Amazon CloudWatch les informations recueillies par Elastic Beanstalk pour les rapports améliorés sur l'état en tant que métriques personnalisées. Les frais CloudWatch relatifs aux métriques personnalisées s'appliquent à toutes les métriques autres que EnvironmentHealth : ils sont donc gratuits.

Les rapports améliorés sur l'état de santé nécessitent une version 2 ou ultérieure pour la version de plateforme. Pour surveiller les ressources et publier des métriques, votre environnement doit avoir à la fois un rôle de profil d'instance et de service. La plateforme Docker multi-conteneurs n'inclut pas de serveur web par défaut, mais elle peut être utilisée avec les rapports améliorés sur l'état de santé si vous configurez votre serveur web pour fournir des journaux au format approprié.

L'intégrité améliorée nécessite que l'environnement dispose d'un profil d'instance. Le profil d'instance doit avoir des rôles qui permettent à vos instances d'environnement de collecter et de signaler des informations d'intégrité améliorée. La première fois que vous créez un environnement avec une plateforme v2 dans la console Elastic Beanstalk, Elastic Beanstalk vous invite à créer les rôles requis et active par défaut les rapports améliorés sur l'état. Poursuivez votre lecture pour en savoir plus sur le fonctionnement des rapports améliorés sur l'état, ou consultez Activation des rapports améliorés sur l'état Elastic Beanstalk pour commencer à utiliser immédiatement ces rapports.

Pour pouvoir prendre en charge les rapports améliorés sur l'état sans condition, les plateformes Amazon Linux 2 exigent des profils d'instance. Lorsque vous créez un environnement à l'aide d'une plateforme Amazon Linux 2, Elastic Beanstalk active toujours les rapports améliorés sur l'état, quelle que soit la façon dont vous créez l'environnement (à l'aide de la console Elastic Beanstalk, de l'interface de ligne de commande (CLI) EB, de la AWS CLI ou de l'API).

Agent de vérification de l'état Elastic Beanstalk

L'agent de vérification de l'état Elastic Beanstalk est un processus démon (ou un service, dans les environnements Windows) qui s'exécute sur chaque instance Amazon EC2 de votre environnement, en surveillant les métriques d'état au niveau de l'application et du système d'exploitation et en signalant les problèmes à Elastic Beanstalk. L'agent d'état est inclus dans toutes les versions de plateforme Linux à partir de la version 2.0 de chaque plateforme.

L'agent de vérification de l'état rapporte des métriques similaires à celles publiées sur CloudWatch par Amazon EC2 Auto Scaling et Elastic Load Balancing dans le cadre des rapports de base sur l'état, y compris la charge de l'UC, les codes HTTP et la latence. Toutefois, l'agent de vérification de l'état rapporte les métriques directement à Elastic Beanstalk, avec une granularité et une fréquence supérieures aux rapports de base sur l'état.

Pour l'intégrité de base, ces métriques sont publiées toutes les cinq minutes et peuvent être contrôlées avec des graphiques dans la console de gestion d'environnement. Avec les rapports améliorés sur l'état, l'agent de vérification de l'état Elastic Beanstalk rapporte des métriques à Elastic Beanstalk toutes les 10 secondes. Elastic Beanstalk utilise les métriques fournies par l'agent de vérification de l'état pour déterminer l'état de santé de chaque instance dans l'environnement et, combinées à d'autres facteurs, pour déterminer l'état global de l'environnement.

L'état global de l'environnement peut être affiché en temps réel sur la page de présentation de l'environnement de la console Elastic Beanstalk. Il est également publié dans CloudWatch par Elastic Beanstalk toutes les 60 secondes. Vous pouvez consulter en temps réel les métriques détaillées indiquées par l'agent d'état en utilisant la commande eb health dans l'interface de ligne de commande EB.

En payant un petit supplément, vous pouvez choisir de publier des métriques individuelles au niveau de l'instance et de l'environnement dans CloudWatch toutes les 60 secondes. Les métriques publiées dans CloudWatch peuvent ensuite être utilisées pour créer des graphiques de surveillance dans la console de gestion de l'environnement.

Les rapports améliorés sur l'état n'impliquent un coût que si vous choisissez de publier des métriques améliorées sur l'état dans CloudWatch. Lorsque vous utilisez l'intégrité améliorée, vous obtenez encore les métriques d'intégrité de base publiées gratuitement, même si vous ne choisissez pas de publier des métriques d'intégrité améliorée.

Pour obtenir des détails sur les métriques rapportées par l'agent de vérification de l'état, veuillez consulter Métriques des instances. Pour de plus amples informations sur la publication de métriques améliorées sur l'état dans CloudWatch, veuillez consulter Publication de métriques personnalisées Amazon CloudWatch pour un environnement.

Facteurs de détermination de l'intégrité de l'environnement et de l'instance

Outre les vérifications système des rapports de base sur l'état, notamment les Vérifications de l'état Elastic Load Balancing et la surveillance des ressources, les rapports améliorés sur l'état Elastic Beanstalk collectent des données supplémentaires sur l'état des instances de votre environnement. Sont incluses les métriques du système d'exploitation, les journaux de serveur et l'état des opérations d'environnement en cours, telles que les déploiements et les mises à jour. Le service de rapports sur l'état Elastic Beanstalk associe des informations issues de toutes les sources disponibles et les analyse pour évaluer l'état global de l'environnement.

Opérations et commandes

Lorsque vous effectuez une opération dans votre environnement, telle que le déploiement d'une nouvelle version d'une application, Elastic Beanstalk apporte plusieurs modifications qui affectent l'état de santé de l'environnement.

Par exemple, lorsque vous déployez une nouvelle version d'une application dans un environnement qui exécute plusieurs instances, des messages similaires au suivant s'affichent lorsque vous surveillez l'état de santé de l'environnement avec l'interface de ligne de commande EB.

  id             status     cause
    Overall      Info       Command is executing on 3 out of 5 instances
  i-bb65c145     Pending    91 % of CPU is in use. 24 % in I/O wait
                            Performing application deployment (running for 31 seconds)
  i-ba65c144     Pending    Performing initialization (running for 12 seconds)
  i-f6a2d525     Ok         Application deployment completed 23 seconds ago and took 26 seconds
  i-e8a2d53b     Pending    94 % of CPU is in use. 52 % in I/O wait
                            Performing application deployment (running for 33 seconds)
  i-e81cca40     Ok

Dans cet exemple, l'état général de l'environnement est Ok et la cause de cet état est que la commande s'exécute sur 3 des 5 instances. Trois des instances dans l'environnement ont le statut Pending, indiquant qu'une opération est en cours.

Lorsqu'une opération est terminée, Elastic Beanstalk rapporte des informations complémentaires sur l'opération. A titre d'exemple, Elastic Beanstalk affiche les informations suivantes sur une instance qui a déjà été mise à jour avec la nouvelle version de l'application :

i-f6a2d525     Ok         Application deployment completed 23 seconds ago and took 26 seconds

Les informations sur l'intégrité de l'instance incluent également des détails sur le déploiement le plus récent sur chaque instance dans votre environnement. Chaque instance indique un état et un ID de déploiement. L'ID de déploiement est un nombre entier qui augmente d'un niveau chaque fois que vous déployez une nouvelle version de votre application ou que vous modifiez les paramètres des options de configuration des instances, telles que les variables d'environnement. Vous pouvez utiliser les informations de déploiement pour identifier les instances qui exécutent la mauvaise version de votre application après un échec de déploiement propagé.

Dans la colonne de cause, Elastic Beanstalk inclut des messages d'information sur la réussite des opérations et d'autres états sains pour différentes vérifications de l'état. Ces messages ne sont toutefois pas conservés indéfiniment. Les causes des statuts d'environnement défectueux sont conservées jusqu'à ce que l'environnement renvoie un état sain.

Expiration de commande

Elastic Beanstalk applique un délai d'expiration de commande à partir du moment où une opération commence à autoriser une instance à effectuer la transition vers un état sain. Cette expiration de la commande est définie dans la configuration de déploiement et de mise à jour de votre environnement (dans l'espace de noms aws:elasticbeanstalk:command) et est paramétrée par défaut sur 10 minutes.

Les mises à jour propagées sont l'occasion pour Elastic Beanstalk d'appliquer un délai d'expiration distinct à chaque lot dans l'opération. Cette expiration est définie dans le cadre de la configuration des mises à jour propagées de l'environnement (dans l'espace de noms aws:autoscaling:updatepolicy:rollingupdate). Si toutes les instances dans le lot sont saines dans le délai de mise à jour continue, l'opération se poursuit et passe au lot suivant. Dans le cas contraire, l'opération échoue.

Pour qu'un environnement de serveur web soit considéré comme sain, chaque instance dans l'environnement ou le lot chaque instance doit réussir 12 vérifications de l'état consécutives en deux minutes. Dans un environnement de travail, chaque instance doit réussir 18 vérifications de l'état. Avant l'expiration de la commande, Elastic Beanstalk n'abaisse pas l'état de santé d'un environnement lorsque les vérifications de l'état échouent. Si les instances de l'environnement deviennent saines avant l'expiration de la commande, l'opération réussit.

Requêtes HTTP

Lorsqu'aucune opération n'est en cours sur un environnement, la source principale d'informations sur l'intégrité de l'instance et de l'environnement repose sur les journaux de serveur web pour chaque instance. Pour déterminer l'état d'une instance et l'état global de l'environnement, Elastic Beanstalk prend en compte le nombre de demandes, le résultat de chaque demande et la vitesse à laquelle chaque demande a été résolue.

Sur les plateformes Linux, Elastic Beanstalk lit et analyse les journaux des serveurs web pour obtenir des informations sur les demandes HTTP. Sur la plateforme Windows Server, Elastic Beanstalk reçoit directement ces informations du serveur web IIS.

Votre environnement peut ne pas avoir de serveur web actif. Par exemple, la plateforme Docker multi-conteneurs n'inclut pas de serveur web. Les autres plateformes comprennent un serveur web, et votre application peut le désactiver. Dans ces cas-là, votre environnement exige une configuration supplémentaire pour fournir à l'agent de vérification de l'état Elastic Beanstalk les journaux au format dont il a besoin pour transmettre les informations d'état au service Elastic Beanstalk. Consultez Format de journal d'intégrité améliorée pour plus de détails.

Métriques du système d'exploitation

Elastic Beanstalk surveille les métriques du système d'exploitation rapportées par l'agent de vérification de l'état pour identifier les instances qui sont constamment à court de ressources système.

Pour obtenir des détails sur les métriques rapportées par l'agent de vérification de l'état, veuillez consulter Métriques des instances.

Personnalisation d'une règle de vérification de l'état

Le rapport sur l'intégrité améliorée d’Elastic Beanstalk s'appuie sur un ensemble de règles qui déterminent l'intégrité de votre environnement. Certaines de ces règles peuvent ne pas être adaptées à votre application. Un cas courant est une application qui renvoie de fréquence erreurs HTTP 4xx en raison de sa conception. Elastic Beanstalk utilise l'une de ses règles par défaut pour conclure que quelque chose ne fonctionne pas correctement, puis modifie l'état de santé de votre environnement de OK à Avertissement, Dégradé ou Grave, en fonction du taux d'erreur. Pour gérer ce cas correctement, Elastic Beanstalk vous permet de configurer cette règle et d'ignorer les erreurs HTTP 4xx de l'application. Pour plus d'informations, consultez Configuration de règles d'intégrité améliorée pour un environnement.

Rôles d'intégrité améliorée

Les rapports améliorés sur l'état exigent deux rôles : un rôle de service pour Elastic Beanstalk et un profil d'instance pour l'environnement. La fonction du service permet à Elastic Beanstalk d'interagir avec d'autres services AWS en votre nom afin de recueillir des informations sur les ressources de votre environnement. Le profil d'instance permet aux instances de votre environnement d'écrire des journaux dans Amazon S3 et de communiquer des informations améliorées sur l'état au service Elastic Beanstalk.

Lorsque vous créez un environnement Elastic Beanstalk à l'aide de la console Elastic Beanstalk ou de l'interface de ligne de commande EB, Elastic Beanstalk crée un rôle de service par défaut et attache les stratégies gérées requises à un profil d'instance par défaut pour votre environnement.

Si vous utilisez l'API, un kit SDK ou la AWS CLI pour créer des environnements, vous devez créer ces rôles à l'avance et les spécifier lors de la création de l'environnement pour utiliser les rapports améliorés sur l'état de santé. Pour obtenir des instructions sur la création de rôles appropriés pour vos environnements, veuillez consulter Rôles de service, profils d'instance et stratégies utilisateur.

Nous vous recommandons d'utiliser des stratégies gérées pour votre profil d'instance et votre rôle de service. Les stratégies gérées sont des stratégies AWS Identity and Access Management (IAM) gérées par Elastic Beanstalk. L'utilisation de stratégies gérées garantit que votre environnement dispose de toutes les autorisations nécessaires pour fonctionner correctement.

Pour le profil d'instance, vous pouvez utiliser la stratégie AWSElasticBeanstalkWebTier ou AWSElasticBeanstalkWorkerTier gérée, pour un environnement de niveau serveur web ou de niveau de travail, respectivement. Pour de plus amples informations sur ces deux stratégies de profil d'instance gérées, veuillez consulter Gestion des profils d'instance Elastic Beanstalk.

Autorisation de santé améliorée

Les stratégies gérées du profil d'instance Elastic Beanstalk contiennent des autorisations pour l'action elasticbeanstalk:PutInstanceStatistics. Cette action ne fait pas partie de l'API Elastic Beanstalk. Elle fait partie d'une autre API que les instances d'environnement utilisent en interne pour communiquer des informations améliorées sur l'état au service Elastic Beanstalk. Vous n'appelez pas cette API directement.

Lorsque vous créez un environnement, l'autorisation de l'action elasticbeanstalk:PutInstanceStatistics est activée par défaut. Pour renforcer la sécurité de votre environnement et prévenir l'usurpation des données d'état de santé en votre nom, nous vous recommandons de garder l’autorisation de cette action activée. Si vous utilisez des stratégies gérées pour votre profil d'instance, cette fonction est disponible pour votre nouvel environnement sans aucune autre configuration. Si vous utilisez un profil d'instance personnalisé au lieu d'une stratégie gérée, votre environnement peut afficher un état de santé Aucune donnée. Cela se produit car les instances ne sont pas autorisées pour l'action qui communique des données d'intégrité améliorées au service.

Pour autoriser l'action, incluez l'instruction suivante dans votre profil d'instance.

    {
      "Sid": "ElasticBeanstalkHealthAccess",
      "Action": [
        "elasticbeanstalk:PutInstanceStatistics"
      ],
      "Effect": "Allow",
      "Resource": [
        "arn:aws:elasticbeanstalk:*:*:application/*",
        "arn:aws:elasticbeanstalk:*:*:environment/*"
      ]
    }

Si vous ne souhaitez pas utiliser l'autorisation d'état de santé améliorée pour le moment, désactivez-la en définissant l'option EnhancedHealthAuthEnabled dans l'espace de noms aws:elasticbeanstalk:healthreporting:system sur false. Si cette option est désactivée, les autorisations décrites précédemment ne sont pas requises. Vous pouvez les supprimer du profil d'instance pour accorder un accès sur la base du moindre privilège à vos applications et environnements.

Événements d'intégrité améliorée

Le système d'intégrité améliorée génère des événements lorsqu'un environnement effectue la transition entre différents états. L'exemple suivant illustre la sortie d'événements provenant d'un environnement effectuant une transition entre les états Infos, OK et Grave.

Lors du passage à un état dégradé, l'événement de rapport amélioré sur l'état de santé inclut un message indiquant la cause de la transition.

Les changements de statut au niveau de l'instance ne conduisent pas tous Elastic Beanstalk à émettre un événement. Pour éviter les fausses alarmes, Elastic Beanstalk ne génère d'événement d'état que si un problème persiste dans plusieurs vérifications.

Des informations d'état au niveau de l'environnement en temps réel, y compris le statut, la couleur et la cause, sont disponibles sur la page de présentation de l'environnement de la console Elastic Beanstalk et de l'interface de ligne de commande EB. En associant l'interface de ligne de commande EB à votre environnement et en exécutant la commande eb health, vous pouvez aussi afficher les statuts en temps réel de chacune des instances dans votre environnement.

Comportement de la création de rapports d'intégrité améliorée au cours des mises à jour, des déploiements et de la mise à l'échelle

Activer la création de rapports d'intégrité améliorée peut affecter le comportement de votre environnement au cours des déploiements et des mises à jour de configuration. Elastic Beanstalk ne termine pas un lot de mises à jour tant que toutes les instances n'ont pas réussi les vérifications de l'état. Par ailleurs, étant donné que les rapports améliorés sur l'état de santé appliquent un standard supérieur et surveille plusieurs facteurs, les instances qui réussissent la vérification de l'état ELB des rapports basiques sur l'état de santé ne réussissent pas forcément dans les rapports améliorés sur l'état de santé. Consultez les rubriques sur rolling configuration updates et rolling deployments pour plus d'informations sur la façon dont les vérifications de l'état affectent le processus de mise à jour.

Les rapports améliorés sur l'état peuvent également mettre en évidence la nécessité de définir une URL de vérification de l'état correcte pour Elastic Load Balancing. Lorsque votre environnement s'adapte pour répondre à la demande, de nouvelles instances commencent à accepter des demandes dès qu'elles réussissent suffisamment de vérifications de l'état ELB. Si aucune URL de vérification de l'état n'est configurée, le délai après qu'une nouvelle instance soit capable d'accepter une connexion TCP peut se réduire à seulement 20 secondes.

Si votre application n'a pas fini de démarrer au moment où l'équilibreur de charge la déclare suffisamment saine pour recevoir du trafic, vous verrez un flot de demandes ayant échoué, et votre environnement commencera à échouer à des vérifications de l'état. Une URL de vérification de l'état qui atteint un chemin servi par votre application peut éviter ce problème. Les vérifications de l'état ELB ne réussissent pas tant qu'une demande GET adressée à l'URL de vérification de l'état n'a pas renvoyé un code de statut 200.