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 des environnements dans Elastic Beanstalk
Grâce à la surveillance de l'état de santé d'Elastic Beanstalk, vous pouvez vérifier la disponibilité des applications et créer des alertes qui s'activent lorsque les indicateurs dépassent vos seuils. Vous pouvez utiliser la surveillance de l'état d'Elastic Beanstalk à la fois dans la console et sur la ligne de commande pour suivre l'état de votre environnement.
**Topics**
+ [Surveillance de l'état de l'environnement dans la console AWS de gestion](environment-health-console.md)
+ [Utilisation de l'interface de ligne de commande EB pour surveiller l'intégrité de l'environnement](health-enhanced-ebcli.md)
+ [Création de rapports d'intégrité de base](using-features.healthstatus.md)
+ [Rapports et surveillance de l'état de santé améliorés dans Elastic Beanstalk](health-enhanced.md)
+ [Gestion des alarmes](using-features.alarms.md)
+ [Affichage de l'historique des modifications d'un environnement Elastic Beanstalk](using-features.changehistory.md)
+ [Affichage du flux d'événements d'un environnement Elastic Beanstalk](using-features.events.md)
+ [Affichage de la liste des instances de serveur et connexion à ces instances](using-features.ec2connect.md)
+ [Affichage des journaux des instances Amazon EC2 dans votre environnement Elastic Beanstalk](using-features.logging.md)
+ [Afficher les journaux de déploiement pour un environnement Elastic Beanstalk](environments-deployment-logs.md)
# Surveillance de l'état de l'environnement dans la console AWS de gestion
Vous pouvez accéder aux informations opérationnelles concernant votre application depuis la console Elastic Beanstalk. La console affiche l'état de votre environnement et l'intégrité de l'application en un coup de œil. Dans la page **Environments (Environnements)** de la console et dans la page de chaque application, les environnements de la liste sont codés par couleur pour indiquer leur état.
**Pour surveiller un environnement dans la console Elastic Beanstalk**
1. Ouvrez la console [Elastic Beanstalk](https://console.aws.amazon.com/elasticbeanstalk), puis **dans la liste des régions, sélectionnez votre**. Région AWS
1. Dans le panneau de navigation, choisissez **Environments** (Environnements), puis choisissez le nom de votre environnement dans la liste.
1. Dans le panneau de navigation, choisissez **Surveillance**.
La page Monitoring vous montre les statistiques globales sur votre environnement, telles que l'utilisation de l'UC et la latence moyenne. Outre les statistiques globales, vous pouvez afficher les graphiques de surveillance qui affichent l'utilisation des ressources sur la durée. Vous pouvez cliquer sur n'importe lequel des graphiques pour afficher des informations plus détaillées.
**Note**
Par défaut, seules CloudWatch les métriques de base sont activées, qui renvoient les données par périodes de cinq minutes. Vous pouvez activer des mesures plus détaillées d'une minute en modifiant CloudWatch les paramètres de configuration de votre environnement.
## Graphiques de surveillance
La page **Surveillance** présente une vue d'ensemble des métriques liées à l'état de votre environnement. Cela inclut l'ensemble de mesures par défaut fourni par Elastic Load Balancing et Amazon EC2, ainsi que des graphiques illustrant l'évolution de l'état de l'environnement au fil du temps.
La barre située au-dessus des graphiques propose différents intervalles de temps que vous pouvez sélectionner. Par exemple, sélectionnez **1w** pour afficher les informations couvrant la semaine dernière. Vous pouvez également sélectionner **3h** pour afficher les informations couvrant les trois dernières heures.
Pour une plus grande variété de sélections d'intervalles de temps, choisissez **Personnalisé**. Vous disposez alors de deux options d'intervalle : *Absolue* ou *Relative*. L'option **Absolue** vous permet de spécifier une plage de dates spécifique, par exemple *du 1er janvier 2023 au 30 juin 2023*. L'option **Relative** vous permet de sélectionner un nombre entier avec une unité de temps spécifique : *Minutes*, *Heures*, *Jours*, *Semaines* ou *Mois*. Les exemples incluent *10 heures*, *10 jours* et *10 mois*.
![\[Section Surveillance de l'état de l'environnement sur la page Surveillance de l'environnement de la console Elastic Beanstalk\]](http://docs.aws.amazon.com/fr_fr/elasticbeanstalk/latest/dg/images/environment-monitoring-graphs.png)
## Personnalisation de la console de surveillance
Pour créer et consulter des statistiques personnalisées, vous devez utiliser Amazon CloudWatch. CloudWatch Vous pouvez ainsi créer des tableaux de bord personnalisés pour surveiller vos ressources dans une vue unique. Sélectionnez **Ajouter au tableau de bord** pour accéder à la CloudWatch console Amazon depuis la page de **surveillance**. Amazon vous CloudWatch offre la possibilité de créer un nouveau tableau de bord ou d'en sélectionner un existant. Pour plus d'informations, consultez la section [Utilisation CloudWatch des tableaux de bord Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) dans le *guide de CloudWatch l'utilisateur Amazon*.
![\[Section Surveillance de l'état de l'environnement sur la page Surveillance de l'environnement de la console Elastic Beanstalk\]](http://docs.aws.amazon.com/fr_fr/elasticbeanstalk/latest/dg/images/environment-monitoring-graphs.png)
Les EC2 métriques [Elastic Load Balancing](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/elb-metricscollected.html) et [Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/ec2-metricscollected.html) sont activées pour tous les environnements.
Lorsque l'[état de santé est amélioré](health-enhanced.md), la EnvironmentHealth métrique est activée et un graphique est automatiquement ajouté à la console de surveillance. L'état amélioré ajoute également la [page Health](health-enhanced-console.md#health-enhanced-console-healthpage) à la console de gestion. Pour obtenir une liste des métriques d'état amélioré disponibles, veuillez consulter [Publication de métriques CloudWatch personnalisées Amazon pour un environnement](health-enhanced-cloudwatch.md).
# Utilisation de l'interface de ligne de commande EB pour surveiller l'intégrité de l'environnement
L'interface de ligne de commande [Elastic Beanstalk (EB CLI) est un outil de ligne](eb-cli3.md) de commande permettant de gérer les environnements. AWS Elastic Beanstalk Vous pouvez également utiliser l'interface de ligne de commande EB pour surveiller l'intégrité de votre environnement en temps réel et avec davantage de granularité que celle qui est actuellement disponible dans la console Elastic Beanstalk.
Après avoir [installé](eb-cli3.md#eb-cli3-install) et [configuré](eb-cli3-configuration.md) l'EB CLI, vous pouvez lancer un nouvel environnement et y déployer votre code à l'aide de la **eb create** commande. Si vous avez déjà un environnement que vous avez créé dans la console Elastic Beanstalk, vous pouvez y attacher l'interface de ligne de commande EB en exécutant **eb init** dans un dossier de projet et en suivant les invites (le dossier du projet peut être vide).
**Important**
Assurez-vous que vous utilisez la dernière version de l'interface de ligne de commande EB en exécutant `pip install` avec l'option `--upgrade` :
```
$ sudo pip install --upgrade awsebcli
```
Pour des instructions complètes d'installation de l'interface de ligne de commande EB, veuillez consulter [Installation de la CLI EB avec un script de configuration (recommandé)](eb-cli3.md#eb-cli3-install).
Pour utiliser l'interface de ligne de commande EB pour surveiller l'intégrité de votre environnement, vous devez tout d'abord configurer un dossier local du projet en exécutant **eb init** puis en suivant les invites. Pour obtenir des instructions complètes, veuillez consulter [Configuration de l'interface de ligne de commande EB](eb-cli3-configuration.md).
Si un environnement s'exécute déjà dans Elastic Beanstalk et que vous souhaitez utiliser l'interface de ligne de commande EB pour surveiller son état, procédez comme suit pour l'attacher à l'environnement existant.
**Pour attacher l'interface de ligne de commande EB à un environnement existant**
1. Ouvrez une terminal de ligne de commande et accédez à votre dossier utilisateur.
1. Créez et ouvrez un dossier pour votre environnement.
1. Exécutez la commande **eb init**, puis choisissez l'application et l'environnement dont vous souhaitez analyser l'intégrité. Si un seul environnement exécute l'application que vous avez choisie, l'interface de ligne de commande EB le sélectionne automatiquement et vous n'avez pas à choisir l'environnement, comme illustré dans l'exemple suivant.
```
~/project$ eb init
Select an application to use
1) elastic-beanstalk-example
2) [ Create new Application ]
(default is 2): 1
Select the default environment.
You can change this later by typing "eb use [environment_name]".
1) elasticBeanstalkEx2-env
2) elasticBeanstalkExa-env
(default is 1): 1
```
**Pour surveillez l'intégrité en utilisant l'interface de ligne de commande EB**
1. Ouvrez une ligne de commande et accédez au dossier de votre projet.
1. Exécutez la commande **eb health** pour afficher l'état d'intégrité des instances dans votre environnement. Dans cet exemple, il y a cinq instances en cours d'exécution dans un environnement Linux.
```
~/project $ eb health
elasticBeanstalkExa-env Ok 2015-07-08 23:13:20
WebServer Ruby 2.1 (Puma)
total ok warning degraded severe info pending unknown
5 5 0 0 0 0 0 0
instance-id status cause health
Overall Ok
i-d581497d Ok
i-d481497c Ok
i-136e00c0 Ok
i-126e00c1 Ok
i-8b2cf575 Ok
instance-id r/sec %2xx %3xx %4xx %5xx p99 p90 p75 p50 p10 requests
Overall 671.8 100.0 0.0 0.0 0.0 0.003 0.002 0.001 0.001 0.000
i-d581497d 143.0 1430 0 0 0 0.003 0.002 0.001 0.001 0.000
i-d481497c 128.8 1288 0 0 0 0.003 0.002 0.001 0.001 0.000
i-136e00c0 125.4 1254 0 0 0 0.004 0.002 0.001 0.001 0.000
i-126e00c1 133.4 1334 0 0 0 0.003 0.002 0.001 0.001 0.000
i-8b2cf575 141.2 1412 0 0 0 0.003 0.002 0.001 0.001 0.000
instance-id type az running load 1 load 5 user% nice% system% idle% iowait% cpu
i-d581497d t2.micro 1a 12 mins 0.0 0.04 6.2 0.0 1.0 92.5 0.1
i-d481497c t2.micro 1a 12 mins 0.01 0.09 5.9 0.0 1.6 92.4 0.1
i-136e00c0 t2.micro 1b 12 mins 0.15 0.07 5.5 0.0 0.9 93.2 0.0
i-126e00c1 t2.micro 1b 12 mins 0.17 0.14 5.7 0.0 1.4 92.7 0.1
i-8b2cf575 t2.micro 1c 1 hour 0.19 0.08 6.5 0.0 1.2 92.1 0.1
instance-id status id version ago deployments
i-d581497d Deployed 1 Sample Application 12 mins
i-d481497c Deployed 1 Sample Application 12 mins
i-136e00c0 Deployed 1 Sample Application 12 mins
i-126e00c1 Deployed 1 Sample Application 12 mins
i-8b2cf575 Deployed 1 Sample Application 1 hour
```
Dans cet exemple, il y a une seule instance en cours d'exécution dans un environnement Windows.
```
~/project $ eb health
WindowsSampleApp-env Ok 2018-05-22 17:33:19
WebServer IIS 10.0 running on 64bit Windows Server 2016/2.2.0
total ok warning degraded severe info pending unknown
1 1 0 0 0 0 0 0
instance-id status cause health
Overall Ok
i-065716fba0e08a351 Ok
instance-id r/sec %2xx %3xx %4xx %5xx p99 p90 p75 p50 p10 requests
Overall 13.7 100.0 0.0 0.0 0.0 1.403 0.970 0.710 0.413 0.079
i-065716fba0e08a351 2.4 100.0 0.0 0.0 0.0 1.102* 0.865 0.601 0.413 0.091
instance-id type az running % user time % privileged time % idle time cpu
i-065716fba0e08a351 t2.large 1b 4 hours 0.2 0.1 99.7
instance-id status id version ago deployments
i-065716fba0e08a351 Deployed 2 Sample Application 4 hours
```
## Lecture du résultat
Le résultat affiche le nom de l'environnement, l'intégrité globale de l'environnement et la date actuelle en haut de l'écran.
```
elasticBeanstalkExa-env Ok 2015-07-08 23:13:20
```
Les trois lignes suivantes indiquent le type d'environnement (» WebServer » dans ce cas), la configuration (Ruby 2.1 avec Puma) et une ventilation du nombre d'instances dans chacun des sept états.
```
WebServer Ruby 2.1 (Puma)
total ok warning degraded severe info pending unknown
5 5 0 0 0 0 0 0
```
Le reste du résultat est divisé en quatre sections. La première affiche l'*état* et la *cause* de l'état de l'environnement dans l'ensemble, puis pour chaque instance. L'exemple suivant montre deux instances de l'environnement avec un état `Info` et une cause indiquant qu'un déploiement a commencé.
```
instance-id status cause health
Overall Ok
i-d581497d Info Performing application deployment (running for 3 seconds)
i-d481497c Info Performing application deployment (running for 3 seconds)
i-136e00c0 Ok
i-126e00c1 Ok
i-8b2cf575 Ok
```
Pour de plus amples informations sur les couleurs et les états d'intégrité, veuillez consulter [Couleurs et états utilisés dans les rapports d'intégrité](health-enhanced-status.md).
La section **requests (demandes)** affiche des informations à partir des journaux du serveur web sur chaque instance. Dans cet exemple, chaque instance accepte les demandes normalement et il n'y a pas d'erreurs.
```
instance-id r/sec %2xx %3xx %4xx %5xx p99 p90 p75 p50 p10 requests
Overall 13.7 100.0 0.0 0.0 0.0 1.403 0.970 0.710 0.413 0.079
i-d581497d 2.4 100.0 0.0 0.0 0.0 1.102* 0.865 0.601 0.413 0.091
i-d481497c 2.7 100.0 0.0 0.0 0.0 0.842* 0.788 0.480 0.305 0.062
i-136e00c0 4.1 100.0 0.0 0.0 0.0 1.520* 1.088 0.883 0.524 0.104
i-126e00c1 2.2 100.0 0.0 0.0 0.0 1.334* 0.791 0.760 0.344 0.197
i-8b2cf575 2.3 100.0 0.0 0.0 0.0 1.162* 0.867 0.698 0.477 0.076
```
La section **cpu** illustre les métriques du système d'exploitation pour chaque instance. La sortie diffère selon le système d'exploitation. Voici la sortie pour les environnements Linux.
```
instance-id type az running load 1 load 5 user% nice% system% idle% iowait% cpu
i-d581497d t2.micro 1a 12 mins 0.0 0.03 0.2 0.0 0.0 99.7 0.1
i-d481497c t2.micro 1a 12 mins 0.0 0.03 0.3 0.0 0.0 99.7 0.0
i-136e00c0 t2.micro 1b 12 mins 0.0 0.04 0.1 0.0 0.0 99.9 0.0
i-126e00c1 t2.micro 1b 12 mins 0.01 0.04 0.2 0.0 0.0 99.7 0.1
i-8b2cf575 t2.micro 1c 1 hour 0.0 0.01 0.2 0.0 0.1 99.6 0.1
```
Voici la sortie pour les environnements Windows.
```
instance-id type az running % user time % privileged time % idle time
i-065716fba0e08a351 t2.large 1b 4 hours 0.2 0.0 99.8
```
Pour de plus amples informations sur les métriques du serveur et du système d'exploitation affichées, veuillez consulter [Métriques des instances](health-enhanced-metrics.md).
La section finale, **deployments (déploiements)**, présente l'état de déploiement de chaque instance. En cas d'échec d'un déploiement propagé, vous pouvez utiliser l'ID, le statut et l'étiquette de version indiqués pour identifier les instances de votre environnement exécutant la mauvaise version.
```
instance-id status id version ago deployments
i-d581497d Deployed 1 Sample Application 12 mins
i-d481497c Deployed 1 Sample Application 12 mins
i-136e00c0 Deployed 1 Sample Application 12 mins
i-126e00c1 Deployed 1 Sample Application 12 mins
i-8b2cf575 Deployed 1 Sample Application 1 hour
```
## Vue d'intégrité interactive
La commande **eb health** affiche un instantané de l'intégrité de votre environnement. Pour actualiser les informations affichées toutes les 10 secondes, utilisez l'option `--refresh`.
```
$ eb health --refresh
elasticBeanstalkExa-env Ok 2015-07-09 22:10:04 (1 secs)
WebServer Ruby 2.1 (Puma)
total ok warning degraded severe info pending unknown
5 5 0 0 0 0 0 0
instance-id status cause health
Overall Ok
i-bb65c145 Ok Application deployment completed 35 seconds ago and took 26 seconds
i-ba65c144 Ok Application deployment completed 17 seconds ago and took 25 seconds
i-f6a2d525 Ok Application deployment completed 53 seconds ago and took 26 seconds
i-e8a2d53b Ok Application deployment completed 32 seconds ago and took 31 seconds
i-e81cca40 Ok
instance-id r/sec %2xx %3xx %4xx %5xx p99 p90 p75 p50 p10 requests
Overall 671.8 100.0 0.0 0.0 0.0 0.003 0.002 0.001 0.001 0.000
i-bb65c145 143.0 1430 0 0 0 0.003 0.002 0.001 0.001 0.000
i-ba65c144 128.8 1288 0 0 0 0.003 0.002 0.001 0.001 0.000
i-f6a2d525 125.4 1254 0 0 0 0.004 0.002 0.001 0.001 0.000
i-e8a2d53b 133.4 1334 0 0 0 0.003 0.002 0.001 0.001 0.000
i-e81cca40 141.2 1412 0 0 0 0.003 0.002 0.001 0.001 0.000
instance-id type az running load 1 load 5 user% nice% system% idle% iowait% cpu
i-bb65c145 t2.micro 1a 12 mins 0.0 0.03 0.2 0.0 0.0 99.7 0.1
i-ba65c144 t2.micro 1a 12 mins 0.0 0.03 0.3 0.0 0.0 99.7 0.0
i-f6a2d525 t2.micro 1b 12 mins 0.0 0.04 0.1 0.0 0.0 99.9 0.0
i-e8a2d53b t2.micro 1b 12 mins 0.01 0.04 0.2 0.0 0.0 99.7 0.1
i-e81cca40 t2.micro 1c 1 hour 0.0 0.01 0.2 0.0 0.1 99.6 0.1
instance-id status id version ago deployments
i-bb65c145 Deployed 1 Sample Application 12 mins
i-ba65c144 Deployed 1 Sample Application 12 mins
i-f6a2d525 Deployed 1 Sample Application 12 mins
i-e8a2d53b Deployed 1 Sample Application 12 mins
i-e81cca40 Deployed 1 Sample Application 1 hour
(Commands: Help,Quit, ▼ ▲ ◄ ►)
```
Cet exemple illustre un environnement qui a récemment été monté en puissance d'une à cinq instances. L'opération de mise à l'échelle a abouti, et toutes les instances transmettent maintenant des vérifications de l'état et sont prêtes à prendre des demandes. En mode interactif, l'état d'intégrité est mis à jour toutes les 10 secondes. Dans l'angle supérieur droit, un minuteur assure le décompte jusqu'à la prochaine mise à jour.
Dans l'angle inférieur gauche, le rapport affiche une liste d'options. Pour quitter le mode interactif, appuyez sur **Q.** Pour faire défiler la page, appuyez sur les touches fléchées. Pour afficher une liste de commandes supplémentaires, appuyez sur **H**.
## Options d'affichage d'intégrité interactif
Lors de l'affichage d'intégrité de l'environnement de manière interactive, vous pouvez utiliser les touches du clavier pour ajuster la vue et dire à Elastic Beanstalk de remplacer ou de redémarrer des instances individuelles. Pour afficher la liste des commandes disponibles lors de la consultation du rapport d'intégrité en mode interactif, appuyez sur **H**.
```
up,down,home,end Scroll vertically
left,right Scroll horizontally
F Freeze/unfreeze data
X Replace instance
B Reboot instance
<,> Move sort column left/right
-,+ Sort order descending/ascending
P Save health snapshot data file
Z Toggle color/mono mode
Q Quit this program
Views
1 All tables/split view
2 Status Table
3 Request Summary Table
4 CPU%/Load Table
H This help menu
(press Q or ESC to return)
```
# Création de rapports d'intégrité de base
Cette rubrique décrit les fonctionnalités proposées par Elastic Beanstalk Basic Health.
AWS Elastic Beanstalk utilise des informations provenant de sources multiples pour déterminer si votre environnement est disponible et pour traiter les demandes provenant d'Internet. L'état de santé d'un environnement est représenté par l'une des quatre couleurs et s'affiche sur la page de [présentation de l'environnement](environments-console.md) de la console Elastic Beanstalk. Il est également disponible depuis l'[DescribeEnvironments](https://docs.aws.amazon.com/elasticbeanstalk/latest/api/API_DescribeEnvironments.html)API et en appelant **eb status** avec l'[EB CLI](eb-cli3.md).
Le système de création de rapports de base sur l'état fournit des informations sur l'état des instances dans un environnement Elastic Beanstalk en fonction des vérifications de l'état effectuées par Elastic Load Balancing pour les environnements à charge équilibrée ou Amazon Elastic Compute Cloud pour des environnements instance unique.
Outre le contrôle de l'état de vos EC2 instances, Elastic Beanstalk surveille également les autres ressources de votre environnement et signale les ressources manquantes ou mal configurées qui peuvent rendre votre environnement inaccessible aux utilisateurs.
Les métriques collectées par les ressources de votre environnement sont publiées sur Amazon toutes CloudWatch les cinq minutes. Cela inclut les métriques du système d'exploitation provenant d' EC2Elastic Load Balancing et les métriques des requêtes. Vous pouvez consulter des graphiques basés sur ces CloudWatch mesures sur la [page de surveillance](environment-health-console.md) de la console d'environnement. Pour l'intégrité de base, ces métriques ne sont pas utilisées pour déterminer une intégrité de l'environnement.
**Topics**
+ [Couleurs de l'intégrité](#using-features.healthstatus.colors)
+ [Vérifications de l'état Elastic Load Balancing](#using-features.healthstatus.understanding)
+ [Vérifications de l'état d'un environnement à instance unique et d'un environnement de travail](#monitoring-basic-healthcheck-singleinstance)
+ [Contrôles supplémentaires](#monitoring-basic-additionalchecks)
+ [CloudWatch Métriques Amazon](#monitoring-basic-cloudwatch)
## Couleurs de l'intégrité
Elastic Beanstalk signale l'état d'un environnement de serveur web en fonction de la façon dont l'application qui s'y exécute répond à la vérification de l'état. Elastic Beanstalk utilise l'une des quatre couleurs pour décrire l'état, comme illustré dans le tableau suivant :
****
| Couleur | Description |
| --- | --- |
| Gris | Votre environnement est en cours de mise à jour. |
| Vert | Votre environnement a passé avec succès la vérification de l'état la plus récente. Au moins une instance dans votre environnement est disponible et accepte des demandes. |
| Jaune | Votre environnement a échoué à une ou plusieurs vérifications de l'état. Certaines demandes à votre environnement sont en cours d'échec. |
| Rouge | Votre environnement a échoué à au moins trois vérifications de l'état, ou une ressource d'environnement est devenue indisponible. Les demandes échouent systématiquement. |
Ces descriptions s'appliquent uniquement aux environnements utilisant la création de rapports d'intégrité de base. Veuillez consulter [Couleurs et états utilisés dans les rapports d'intégrité](health-enhanced-status.md) pour obtenir des détails sur l'état améliore.
## Vérifications de l'état Elastic Load Balancing
Dans un environnement à charge équilibrée, Elastic Load Balancing envoie une demande à chaque instance dans un environnement toutes les 10 secondes afin de confirmer que les instances sont saines. Par défaut, l'équilibreur de charge est configuré pour ouvrir une connexion TCP sur le port 80. Si l'instance reconnaît la connexion, elle est considérée comme saine.
Vous pouvez choisir remplacer ce paramètre en spécifiant une ressource existante dans votre application. Si vous spécifiez un chemin d'accès, tel que `/health`, l'URL de vérification de l'état est définie sur `HTTP:80/health`. L'URL de vérification de l'état doit être définie sur un chemin d'accès qui est toujours desservi par votre application. Si elle est définie sur une page statique qui est desservie ou mise en cache par le serveur web devant votre application, les vérifications de l'état ne révéleront pas de problèmes avec le serveur d'applications ou le conteneur web. Pour obtenir des instructions sur la modification de votre URL de vérification de l'état, consultez [Surveillance de l'état](environments-cfg-clb.md#using-features.managing.elb.healthchecks).
Si une URL de vérification de l'état est configurée, Elastic Load Balancing attend une demande GET qu'il soumet pour renvoyer une réponse `200 OK`. L'application échoue à la vérification de l'état en cas de défaut de réponse dans les 5 secondes, ou si la réponse est un code d'état autre que HTTP. Après 5 échecs consécutifs de vérification de l'état, Elastic Load Balancing suspend l'instance.
Pour de plus amples informations sur les vérifications de l'état Elastic Load Balancing, veuillez consulter [Vérification de l'état](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/TerminologyandKeyConcepts.html#healthcheck) dans le *Guide de l'utilisateur Elastic Load Balancing*.
**Note**
La configuration d'une URL de vérification de l'état ne modifie pas le comportement de vérification de l'état du groupe Auto Scaling d'un environnement. Une instance défectueuse est supprimée de l'équilibreur de charge, mais n'est pas automatiquement remplacée par Amazon EC2 Auto Scaling, sauf si vous configurez Amazon EC2 Auto Scaling pour utiliser le bilan de santé d'Elastic Load Balancing comme base pour le remplacement des instances. Pour configurer Amazon EC2 Auto Scaling afin de remplacer les instances qui échouent à un test de santé d'Elastic Load Balancing, consultez[Paramètre de vérification de l'état Auto Scaling pour votre environnement Elastic Beanstalk](environmentconfig-autoscaling-healthchecktype.md).
## Vérifications de l'état d'un environnement à instance unique et d'un environnement de travail
Dans un environnement à instance unique ou au niveau du travailleur, Elastic Beanstalk détermine l'état de santé de l'instance en surveillant le statut de son instance Amazon. EC2 Les paramètres d'intégrité d'Elastic Load Balancing, y compris le contrôle de santé HTTP URLs, ne peuvent pas être utilisés dans ces types d'environnement.
Pour plus d'informations sur les contrôles de statut des EC2 [instances Amazon, consultez la section Monitoring Instances with Status Checks](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html) dans le *guide de EC2 l'utilisateur Amazon*.
## Contrôles supplémentaires
Outre les vérifications de l'état Elastic Load Balancing, Elastic Beanstalk surveille les ressources de votre environnement et l'état devient rouge si les ressources ne parviennent pas à se déployer, ne sont pas correctement configurées ou deviennent indisponibles. Ces contrôles confirment ce qui suit :
+ Le groupe Auto Scaling de l'environnement est disponible et possède au minimum une instance.
+ Le groupe de sécurité de l'environnement est disponible et est configuré pour autoriser le trafic entrant sur le port 80.
+ L'environnement CNAME existe et pointe vers l'équilibreur de charge approprié.
+ Dans un environnement de travail, la file d'attente Amazon Simple Queue Service (Amazon SQS) est interrogée au moins une fois toutes les trois minutes.
## CloudWatch Métriques Amazon
En ce qui concerne les rapports de santé de base, le service Elastic Beanstalk ne publie aucun indicateur sur Amazon. CloudWatch Les CloudWatch métriques utilisées pour produire des graphiques sur la [page de surveillance](environment-health-console.md) de la console d'environnement sont publiées par les ressources de votre environnement.
Par exemple, EC2 publie les métriques suivantes pour les instances du groupe Auto Scaling de votre environnement :
`CPUUtilization`
Pourcentage d'unités de calcul actuellement en cours d'utilisation.
`DiskReadBytes``DiskReadOps``DiskWriteBytes``DiskWriteOps`
Nombre d'octets lus et écrits et nombre d'opérations de lecture et d'écriture.
`NetworkIn``NetworkOut`
Nombre d'octets envoyés et reçus.
Elastic Load Balancing publie les métriques suivantes pour l'équilibreur de charge de votre environnement :
`BackendConnectionErrors`
Nombre d'échecs de connexion entre l'équilibreur de charge et les instances d'environnement.
`HTTPCode_Backend_2XX``HTTPCode_Backend_4XX`
Nombre de codes de réponses aboutis (2XX) et d'erreur client (4XX) générés par des instances dans votre environnement.
`Latency`
Nombre de secondes entre le moment où l'équilibreur de charge relaie une demande à une instance et celui de la réception de la réponse.
`RequestCount`
Nombre de demandes terminées.
Ces listes ne sont pas complètes. Pour obtenir la liste complète des statistiques pouvant être signalées pour ces ressources, consultez les rubriques suivantes du manuel Amazon CloudWatch Developer Guide :
**Métriques**
| Namespace | Rubrique |
| --- | --- |
| AWS::ElasticLoadBalancing::LoadBalancer | [Métriques et ressources Elastic Load Balancing](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/elb-metricscollected.html) |
| AWS::AutoScaling::AutoScalingGroupe | [Métriques et ressources Amazon Elastic Compute Cloud](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/ec2-metricscollected.html) |
| AWS::SQS::Queue | [Métriques et ressources Amazon SQS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/sqs-metricscollected.html) |
| AWS : :RDS : : DBInstance | [Dimensions et métriques Amazon RDS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/rds-metricscollected.html) |
### Métrique d'intégrité d'environnement de travail
Pour les environnements de travail uniquement, le démon SQS publie une métrique personnalisée pour l'état de l'environnement CloudWatch, où la valeur 1 est verte. Vous pouvez consulter les données des indicateurs CloudWatch de santé de votre compte à l'aide de l'espace de `ElasticBeanstalk/SQSD` noms. La dimension de métrique est `EnvironmentName`, et le nom de métrique est `Health`. Toutes les instances publient leurs métriques sur le même espace de noms.
Pour permettre au démon de publier des métriques, le profil d'instance de l'environnement doit avoir l'autorisation d'appeler `cloudwatch:PutMetricData`. Cette autorisation est incluse dans le profil d'instance par défaut. Pour plus d'informations, consultez [Gestion des profils d'instance Elastic Beanstalk](iam-instanceprofile.md).
# Rapports et surveillance de l'état de santé améliorés dans Elastic Beanstalk
Cette section explique les fonctionnalités de la fonctionnalité Elastic Beanstalk Enhanced Health.
Les rapports de santé améliorés sont une fonctionnalité que vous pouvez activer dans votre environnement AWS Elastic Beanstalk pour recueillir des informations supplé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](health-enhanced-console.md).
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](#health-enhanced-agent) 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](#health-enhanced-factors) 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](health-enhanced-console.md) de la console Elastic Beanstalk ou la commande [eb health](health-enhanced-ebcli.md) de l'[interface de ligne de commande Elastic Beanstalk](eb-cli3.md). Pour enregistrer et suivre l'état de santé de l'environnement et de l'instance au fil du temps, vous pouvez configurer votre environnement pour publier les informations recueillies par Elastic Beanstalk afin d'améliorer les rapports de santé sur Amazon sous forme de CloudWatch métriques personnalisées. CloudWatch les [frais](https://aws.amazon.com/cloudwatch/pricing/) relatifs aux mesures personnalisées s'appliquent à toutes les mesures autres que celles `EnvironmentHealth` qui sont gratuites.
**Remarques sur la plateforme Windows**
Lorsque vous activez les rapports améliorés sur l'état de santé pour un environnement Windows Server, ne modifiez pas la [configuration de la journalisation IIS](https://docs.microsoft.com/en-us/iis/manage/provisioning-and-managing-iis/configure-logging-in-iis). Pour que la surveillance améliorée de l'état de santé fonctionne correctement, la journalisation IIS doit être configurée avec le format **W3C** et les destinations d'événements de journal **ETW event only** ou **Both log file and ETW event**.
Par ailleurs, ne désactivez pas ou n'arrêtez pas le service Windows de l'[agent de vérification de l'état Elastic Beanstalk](#health-enhanced-agent) sur les instances de votre environnement. Pour collecter et signaler des informations d'état de santé améliorées sur une instance, ce service doit être activé et en cours d'exécution.
La première fois que vous créez un environnement, Elastic Beanstalk vous invite à créer les rôles requis et permet d'améliorer les rapports de santé par défaut. 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](health-enhanced-enable.md) pour commencer à utiliser immédiatement ces rapports.
**Topics**
+ [Agent de vérification de l'état Elastic Beanstalk](#health-enhanced-agent)
+ [Facteurs de détermination de l'intégrité de l'environnement et de l'instance](#health-enhanced-factors)
+ [Personnalisation d'une règle de vérification de l'état](#health-enhanced.rules)
+ [Rôles d'intégrité améliorée](#health-enhanced-roles)
+ [Autorisation de santé améliorée](#health-enhanced-authz)
+ [Événements d'intégrité améliorée](#health-enhanced-events)
+ [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](#health-enhanced-effects)
+ [Activation des rapports améliorés sur l'état Elastic Beanstalk](health-enhanced-enable.md)
+ [Surveillance améliorée de l'état avec la console de gestion de l'environnement](health-enhanced-console.md)
+ [Couleurs et états utilisés dans les rapports d'intégrité](health-enhanced-status.md)
+ [Métriques des instances](health-enhanced-metrics.md)
+ [Configuration de règles d'intégrité améliorée pour un environnement](health-enhanced-rules.md)
+ [Publication de métriques CloudWatch personnalisées Amazon pour un environnement](health-enhanced-cloudwatch.md)
+ [Utilisation des rapports améliorés sur l'état à l'aide de l'API Elastic Beanstalk](health-enhanced-api.md)
+ [Format de journal d'intégrité améliorée](health-enhanced-serverlogs.md)
+ [Notifications et dépannage](environments-health-enhanced-notifications.md)
+ [Analyse de l'environnement basée sur l'IA](health-ai-analysis.md)
## 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 santé fournit des statistiques similaires à celles [publiées CloudWatch](using-features.healthstatus.md#monitoring-basic-cloudwatch) par Amazon EC2 Auto Scaling et Elastic Load Balancing dans le cadre [des rapports de santé de base](using-features.healthstatus.md), notamment la charge du processeur, 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](#health-enhanced-factors), pour déterminer l'état global de l'environnement.
L'état général de l'environnement peut être consulté en temps réel sur la page de présentation de l'environnement de la console Elastic Beanstalk et est publié 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**](health-enhanced-ebcli.md) dans l'[interface de ligne de commande EB](eb-cli3.md).
Moyennant des frais supplémentaires, vous pouvez choisir de publier des métriques individuelles au niveau de l'instance et de l'environnement CloudWatch toutes les 60 secondes. Les métriques publiées sur CloudWatch peuvent ensuite être utilisées pour créer des [graphiques de surveillance](environment-health-console.md#environment-health-console-customize) dans la [console de gestion d'environnement](environments-console.md).
La création de rapports d'intégrité améliorée n'implique un coût que si vous choisissez de publier des métriques d'intégrité améliorée sur 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](health-enhanced-metrics.md). Pour plus de détails sur la publication de statistiques de santé améliorées sur CloudWatch, voir[Publication de métriques CloudWatch personnalisées Amazon pour un environnement](health-enhanced-cloudwatch.md).
## 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](using-features.healthstatus.md#using-features.healthstatus.understanding) et la [surveillance des ressources](using-features.healthstatus.md#monitoring-basic-additionalchecks), 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](health-enhanced-ebcli.md).
```
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é](using-features.rolling-version-deploy.md).
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](command-options-general.md#command-options-general-elasticbeanstalkcommand)) 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](command-options-general.md#command-options-general-autoscalingupdatepolicyrollingupdate)). 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.
**Note**
Si votre application ne réussit pas les vérifications de l'état avec le statut **OK**, mais qu'elle est stable à un autre niveau, vous pouvez définir l'option `HealthCheckSuccessThreshold` dans l'espace de noms [`aws:elasticbeanstalk:command namespace`](command-options-general.md#command-options-general-elasticbeanstalkcommand) afin de modifier le niveau auquel Elastic Beanstalk considère une instance comme étant saine.
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](health-enhanced-metrics-server-iis.md).
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](#health-enhanced-agent) 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](health-enhanced-serverlogs.md) 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](health-enhanced-metrics.md).
## 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](health-enhanced-rules.md).
## 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. Le rôle de service permet à Elastic Beanstalk d'interagir AWS avec d'autres services 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 SDK ou le 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 afin d'améliorer l'intégrité. Pour obtenir des instructions sur la création de rôles appropriés pour vos environnements, veuillez consulter [Rôles d'Elastic Beanstalk Service, profils d'instance et politiques utilisateur](concepts-roles.md).
Nous vous recommandons d'utiliser des *stratégies gérées* pour votre profil d'instance et votre rôle de service. Les politiques gérées sont des politiques Gestion des identités et des accès AWS (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](concepts-webserver.md) ou de [niveau de travail](concepts-worker.md), 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](iam-instanceprofile.md).
## 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](command-options-general.md#command-options-general-elasticbeanstalkhealthreporting) 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](security-best-practices.md#security-best-practices.preventive.least-priv) à vos applications et environnements.
**Note**
Auparavant, le paramètre par défaut pour `EnhancedHealthAuthEnabled` était `false`, ce entraînait la désactivation par défaut de l’autorisation de l’action `elasticbeanstalk:PutInstanceStatistics`. Pour activer cette action pour un environnement existant, définissez l'option `EnhancedHealthAuthEnabled` dans l'espace de noms [aws:elasticbeanstalk:healthreporting:system](command-options-general.md#command-options-general-elasticbeanstalkhealthreporting) sur `true`. Vous pouvez configurer cette option à l'aide d'un [paramètre d'option](ebextensions-optionsettings.md) dans un [fichier de configuration](ebextensions.md).
## É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**.
![\[Page de présentation de l'environnement Elastic Beanstalk de la console Elastic Beanstalk affichant des événements récents d'état amélioré\]](http://docs.aws.amazon.com/fr_fr/elasticbeanstalk/latest/dg/images/enhanced-health-events.png)
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](environments-dashboard.md) de la console Elastic Beanstalk et de l'[interface de ligne de commande EB](eb-cli3.md). En associant l'interface de ligne de commande EB à votre environnement et en exécutant la commande [**eb health**](health-enhanced-ebcli.md), 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](using-features.healthstatus.md#using-features.healthstatus.understanding) 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](using-features.rollingupdates.md) et [rolling deployments](using-features.rolling-version-deploy.md) 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](environments-cfg-clb.md#using-features.managing.elb.healthchecks) 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.
# Activation des rapports améliorés sur l'état Elastic Beanstalk
Cette rubrique explique comment les rapports de santé améliorés sont activés. Il fournit des procédures vous permettant d'activer la fonctionnalité d'intégrité améliorée pour votre environnement à l'aide de la console Elastic Beanstalk, de l'EB CLI et d'une configuration .ebextensions.
Les nouveaux environnements créés avec les dernières [versions de la plateforme](concepts.platforms.md) incluent l'[agent AWS Elastic Beanstalk de santé](health-enhanced.md#health-enhanced-agent), qui permet d'améliorer les rapports de santé. Si vous créez votre environnement dans la console Elastic Beanstalk ou avec l'interface de ligne de commande EB, les rapports améliorés sur l'état sont activés par défaut. Vous pouvez également définir vos préférences relatives aux rapports améliorés sur l'état dans le code source de votre application, à l'aide des [fichiers de configuration](ebextensions.md).
Les rapports améliorés sur l'état nécessitent un [profil d'instance](concepts-roles-instance.md) et un [rôle de service](concepts-roles-service.md) incluant l'ensemble standard d'autorisations. Lorsque vous créez un environnement dans la console Elastic Beanstalk, Elastic Beanstalk crée automatiquement les rôles nécessaires. Pour obtenir des instructions sur la création de votre premier environnement, consultez [Découvrez comment démarrer avec Elastic Beanstalk](GettingStarted.md).
**Topics**
+ [Activation des rapports améliorés sur l'état à l'aide de la console Elastic Beanstalk](#health-enhanced-enable-console)
+ [Activation des rapports d'intégrité améliorée via l'interface de ligne de commande EB](#health-enhanced-enable-ebcli)
+ [Activation des rapports d'intégrité améliorées via un fichier de configuration](#health-enhanced-enable-config)
## Activation des rapports améliorés sur l'état à l'aide de la console Elastic Beanstalk
**Pour activer les rapports améliorés sur l'état dans un environnement en cours d'exécution à l'aide de la console Elastic Beanstalk**
1. Ouvrez la console [Elastic Beanstalk](https://console.aws.amazon.com/elasticbeanstalk), puis **dans la liste des régions, sélectionnez votre**. Région AWS
1. Dans le panneau de navigation, choisissez **Environments** (Environnements), puis choisissez le nom de votre environnement dans la liste.
1. Dans le panneau de navigation, choisissez **Configuration**.
1. Dans la catégorie de configuration **Monitoring (Surveillance)**, choisissez **Edit (Modifier)**.
1. Dans la section **Rapport sur l'état de santé**, choisissez **Amélioré** dans le champ **Présentation**.
**Note**
Les options relatives aux rapports améliorés sur l'état de santé ne s'affichent pas si vous utilisez une [plateforme ou une version non prise en charge](health-enhanced.md).
1. Pour enregistrer les modifications, cliquez sur **Appliquer** en bas de la page.
La console Elastic Beanstalk active par défaut les rapports améliorés sur l'état lorsque vous créez un environnement avec la version 2 (v2) de la plateforme. Vous pouvez désactiver les rapports améliorés sur l'état en modifiant l'option des rapports sur l'état lors de la création de l'environnement.
**Pour désactiver les rapports améliorés sur l'état lors de la création d'un environnement à l'aide de la console Elastic Beanstalk**
1. Ouvrez la console [Elastic Beanstalk](https://console.aws.amazon.com/elasticbeanstalk), puis **dans la liste des régions, sélectionnez votre**. Région AWS
1. [Créez une application](applications.md) ou sélectionnez une application existante.
1. [Créez un environnement](using-features.environments.md). Sur la page **Créer un nouvel environnement**, avant de choisir **Créer un environnement**, choisissez **Configurer plus d'options**.
1. Dans la catégorie de configuration **Monitoring (Surveillance)**, choisissez **Edit (Modifier)**.
1. Dans la section **Rapport sur l'état de santé**, choisissez **Basique** dans le champ **Présentation**.
1. Choisissez **Enregistrer**.
## Activation des rapports d'intégrité améliorée via l'interface de ligne de commande EB
Lorsque vous créez un environnement avec la commande **eb create**, l'interface de ligne de commande EB active les rapports améliorés sur l'état par défaut, et applique le rôle de service et le profil d'instance par défaut.
Vous pouvez spécifier un autre rôle de service par nom en utilisant l'option `--service-role`.
Si votre environnement est exécuté dans une version v2 de la plateforme avec des rapports basiques sur l'état de santé et que vous souhaitez passer aux rapports améliorés sur l'état de santé, procédez comme suit.
**Pour activer les rapports améliorés sur l'état dans un environnement en cours d'exécution via l'[interface de ligne de commande EB](eb-cli3.md)**
1. Utilisez la commande **eb config** pour ouvrir le fichier de configuration dans l'éditeur de texte par défaut.
```
~/project$ eb config
```
1. Recherchez l'espace de noms `aws:elasticbeanstalk:environment` dans la section des paramètres. Assurez-vous que la valeur de `ServiceRole` n'est pas nulle et qu'elle correspond au nom de votre [rôle de service](concepts-roles-service.md).
```
aws:elasticbeanstalk:environment:
EnvironmentType: LoadBalanced
ServiceRole: aws-elasticbeanstalk-service-role
```
1. Sous l'espace de noms `aws:elasticbeanstalk:healthreporting:system:`, remplacez la valeur `SystemType` par **enhanced**.
```
aws:elasticbeanstalk:healthreporting:system:
SystemType: enhanced
```
1. Enregistrez le fichier de configuration et fermez l'éditeur de texte.
1. L'interface de ligne de commande EB lance une mise à jour de l'environnement pour appliquer les modifications apportées à la configuration. Attendez la fin de l'opération ou appuyez sur **Ctrl\$1C** pour quitter l'interface en toute sécurité.
```
~/project$ eb config
Printing Status:
INFO: Environment update is starting.
INFO: Health reporting type changed to ENHANCED.
INFO: Updating environment no-role-test's configuration settings.
```
## Activation des rapports d'intégrité améliorées via un fichier de configuration
Vous pouvez activer les rapports améliorés sur l'état en incluant un [fichier de configuration](ebextensions.md) dans votre bundle source. L'exemple suivant présente un fichier de configuration qui active les rapports améliorés sur l'état et affecte le rôle de service et le profil d'instance par défaut à l'environnement :
**Example .ebextensions/enhanced-health.config**
```
option_settings:
aws:elasticbeanstalk:healthreporting:system:
SystemType: enhanced
aws:autoscaling:launchconfiguration:
IamInstanceProfile: aws-elasticbeanstalk-ec2-role
aws:elasticbeanstalk:environment:
ServiceRole: aws-elasticbeanstalk-service-role
```
Si vous avez créé votre propre rôle de service ou profil d'instance, remplacez le texte en surbrillance par les noms de ces rôles.
# Surveillance améliorée de l'état avec la console de gestion de l'environnement
Lorsque vous activez les rapports de santé améliorés dans AWS Elastic Beanstalk, vous pouvez surveiller l'état de l'environnement dans la [console de gestion de l'environnement](environments-console.md).
**Topics**
+ [Aperçu de l'environnement](#health-enhanced-console-overview)
+ [Page « Health (Santé) » de l'environnement](#health-enhanced-console-healthpage)
+ [Page « Monitoring (Surveillance) »](#health-enhanced-console-monitoringpage)
## Aperçu de l'environnement
La [présentation de l'environnement](environments-dashboard.md) affiche les [statuts d'état](health-enhanced-status.md) de l'environnement et répertorie les événements qui apportent des informations sur l'évolution récente des statuts d'état.
**Pour afficher la présentation de l'environnement**
1. Ouvrez la console [Elastic Beanstalk](https://console.aws.amazon.com/elasticbeanstalk), puis **dans la liste des régions, sélectionnez votre**. Région AWS
1. Dans le panneau de navigation, choisissez **Environments** (Environnements), puis choisissez le nom de votre environnement dans la liste.
Pour plus d'informations sur l'état de santé de l'environnement actuel, ouvrez la page **Santé** en choisissant **Causes**. Sinon, dans le panneau de navigation, sélectionnez **Health (Santé)**.
## Page « Health (Santé) » de l'environnement
La page **Health** affiche l'état de santé, les métriques et les causes de l'environnement et de chaque EC2 instance Amazon de l'environnement.
**Note**
Elastic Beanstalk affiche la page **Health (État)** uniquement si vous avez [activé la surveillance améliorée de l'état](health-enhanced-enable.md) pour l'environnement.
L'image suivante montre la page **Health (Santé)** pour un environnement Linux.
![\[Page Health (Santé) de l'environnement pour un environnement Linux\]](http://docs.aws.amazon.com/fr_fr/elasticbeanstalk/latest/dg/images/enhanced-health-instances.png)
L'image suivante montre la page **Health (Santé)** pour un environnement Windows. Notez que les métriques d'UC sont différentes de celles d'un environnement Linux.
![\[Page relative à l'état de l'environnement pour un environnement Windows.\]](http://docs.aws.amazon.com/fr_fr/elasticbeanstalk/latest/dg/images/enhanced-health-instances-win.png)
En haut de la page, vous pouvez voir le nombre total d'instances d'environnement, ainsi que le nombre d'instances par état. Pour afficher uniquement les instances associées à un état particulier, choisissez **Filter By (Filtrer par)**, puis choisissez un [état](health-enhanced-status.md).
![\[Page d'intégrité de l'environnement affichant le filtre par menu pour choisir l'état d'une instance à afficher\]](http://docs.aws.amazon.com/fr_fr/elasticbeanstalk/latest/dg/images/enhanced-health-instances-status.png)
Pour redémarrer ou suspendre une instance défectueuse, choisissez **Actions d'instance**, puis **Reboot (Redémarrer)** ou **Terminate (Résilier)**.
![\[Page relative à l'état de l'environnement affichant le menu des actions de l'instance permettant de redémarrer ou de mettre fin à des instances défectueuses.\]](http://docs.aws.amazon.com/fr_fr/elasticbeanstalk/latest/dg/images/enhanced-health-instances-actions.png)
Elastic Beanstalk met à jour la page **Health (État)** toutes les 10 secondes. Il fournit des informations sur la santé de l'environnement et de l’instance.
Pour chaque EC2 instance Amazon de l'environnement, la page affiche l'ID et le [statut](health-enhanced-status.md) de l'instance, le temps écoulé depuis le lancement de l'instance, l'identifiant du dernier déploiement exécuté sur l'instance, les réponses et la latence des demandes traitées par l'instance, ainsi que les informations relatives à la charge et à l'utilisation du processeur. La ligne **Overall (Globale)** affiche des informations sur la réponse moyenne et la latence pour l'ensemble de l'environnement.
La page affiche de nombreux détails dans un très grand tableau. Pour masquer certaines colonnes, choisissez ![\[the cog icon.\]](http://docs.aws.amazon.com/fr_fr/elasticbeanstalk/latest/dg/images/cog.png) (**Preferences (Préférences)**). Sélectionnez ou effacez les noms de colonne, puis choisissez **Confirme (Confirmer)**.
![\[Sélection des colonnes à afficher sur la page d’état de santé de l'environnement\]](http://docs.aws.amazon.com/fr_fr/elasticbeanstalk/latest/dg/images/enhanced-health-console-preferences.png)
Choisissez l’**Instance ID (ID d'instance)** de n'importe quelle instance pour afficher plus d'informations sur cette dernière, y compris sa zone de disponibilité et le type d'instance.
![\[Métriques de serveur sur la page de santé de l'environnement avec les informations d'instance\]](http://docs.aws.amazon.com/fr_fr/elasticbeanstalk/latest/dg/images/enhanced-health-console-instance.png)
Choisissez l’**Deployment ID (ID de déploiement)** d'une instance pour afficher des informations sur le dernier [déploiement](using-features.deploy-existing-version.md) sur l'instance.
![\[Métriques de serveur sur la page de santé de l'environnement avec les informations de déploiement\]](http://docs.aws.amazon.com/fr_fr/elasticbeanstalk/latest/dg/images/enhanced-health-console-deployment.png)
Les informations sur le déploiement incluent les éléments suivants :
+ **ID de déploiement** — Identifiant unique du [déploiement](using-features.deploy-existing-version.md). IDs Le déploiement commence à 1 et augmente d'une unité chaque fois que vous déployez une nouvelle version de l'application ou que vous modifiez les paramètres de configuration qui affectent le logiciel ou le système d'exploitation exécuté sur les instances de votre environnement.
+ **Version** — Libellé de version du code source de l'application utilisé dans le déploiement.
+ **Statut** — Statut du déploiement (`In Progress`, `Deployed` ou `Failed`).
+ **Durée écoulée** — Durée écoulée depuis le début du déploiement (pour les déploiements en cours) ou durée écoulée depuis la fin du déploiement (pour les déploiements terminés).
Si vous [activez l'intégration de X-Ray](environment-configuration-debugging.md) dans votre environnement et que vous instrumentez votre application avec le AWS X-Ray SDK, la page **Health** ajoute des liens vers la AWS X-Ray console dans la ligne de présentation.
![\[Métriques de demandes sur la page Health (Santé) de l'environnement\]](http://docs.aws.amazon.com/fr_fr/elasticbeanstalk/latest/dg/images/enhanced-health-console-xray.png)
Choisissez un lien pour afficher les traces associées aux statistiques mises en évidence dans la AWS X-Ray console.
## Page « Monitoring (Surveillance) »
La page **de surveillance** affiche des statistiques récapitulatives et des graphiques pour les CloudWatch métriques Amazon personnalisées générées par le système de rapports de santé amélioré. Pour savoir comment ajouter des graphiques et des statistiques à cette page, veuillez consulter [Surveillance de l'état de l'environnement dans la console AWS de gestion](environment-health-console.md).
# Couleurs et états utilisés dans les rapports d'intégrité
Les rapports améliorés sur l'état de santé indiquent l'état de santé des instances et de l'environnement global à l'aide de quatre couleurs, comme dans les [rapports basiques sur l'état de santé](using-features.healthstatus.md). Les rapports améliorés sur l'état de santé incluent également sept statuts d'état de santé. Ce sont des termes descriptifs, composés d'un seul mot, qui vous permettent de mieux comprendre l'état de santé de votre environnement.
## État de l'instance et état de l'environnement
Chaque fois qu'Elastic Beanstalk vérifie l'état de votre environnement, les rapports améliorés sur l'état vérifient l'état de chaque instance de votre environnement, en analysant l'ensemble des [données](health-enhanced.md#health-enhanced-factors) disponibles. En cas d'échec de l'une des vérifications de niveau inférieur, Elastic Beanstalk rétrograde l'état de l'instance.
Elastic Beanstalk affiche les informations sur l'état pour l'environnement global (couleur, statut et cause) dans la [console de gestion de l'environnement](environments-console.md). Ces informations sont également disponibles dans l'interface de ligne de commande EB. Le statut d'état de santé et les messages d'explication sont mis à jour toutes les 10 secondes pour chaque instance, et sont disponibles via l'[interface de ligne de commande EB](eb-cli3.md) lorsque vous affichez le statut d'état de santé avec [**eb health**](health-enhanced-ebcli.md).
Elastic Beanstalk tire parti des changements d'état des instances pour évaluer l'état de l'environnement, mais ne change pas immédiatement l'état de santé de l'environnement. Lorsque la vérification de l'état d'une instance échoue au moins trois fois dans un laps de temps d'une minute, Elastic Beanstalk peut rétrograder l'état de l'environnement. En fonction du nombre d'instances de l'environnement et du problème identifié, une instance défaillante peut conduire Elastic Beanstalk à afficher un message d'information ou à changer l'état de santé de l'environnement en le faisant passer de vert (**OK**) à jaune (**Avertissement**) ou rouge (**Dégradé** ou **Grave**).
## OK (vert)
Ce statut s'affiche lorsque :
+ L'instance réussit les vérifications de l'état et l'agent d'état ne signale aucun problème.
+ La plupart des instances de l'environnement réussissent les vérifications de l'état et l'agent d'état ne signale aucun problème majeur.
+ L'instance réussit les vérifications de l'état et traite les demandes normalement.
*Exemple :* votre environnement a été déployé récemment et accepte les demandes normalement. 5 % de demandes renvoient des erreurs de la série 400. Le déploiement s'est terminé normalement sur chaque instance.
*Message (instance) :* Application deployment completed 23 seconds ago and took 26 seconds.
## Avertissement (jaune)
Ce statut s'affiche lorsque :
+ L'agent d'état signale un nombre modéré d'échecs de la demande ou d'autres problèmes pour une instance ou un environnement.
+ Une opération est en cours sur une instance et prend beaucoup de temps.
*Exemple :* une instance de l'environnement a le statut **Grave**.
*Message (environnement) :* Impaired services on 1 out of 5 instances.
## Dégradé (rouge)
Ce statut s'affiche lorsque l'agent d'état signale un nombre élevé d'échecs de la demande ou d'autres problèmes pour une instance ou un environnement.
*Exemple :* l'environnement est en cours de mise à l'échelle ascendante vers 5 instances.
*Message (environnement) :* 4 active instances is below Auto Scaling group minimum size 5.
## Grave (rouge)
Ce statut s'affiche lorsque l'agent d'état signale un nombre très élevé d'échecs de la demande ou d'autres problèmes pour une instance ou un environnement.
*Exemple :* Elastic Beanstalk ne parvient pas à contacter l'équilibreur de charge pour obtenir l'état de l'instance.
*Message (environnement) :* ELB health is failing or not available for all instances. None of the instances are sending data. Impossible d'assumer le rôle « arn:aws:iam : :123456789012:role/ ». aws-elasticbeanstalk-service-role Verify that the role exists and is configured correctly.
*Message (Instances) :* Instance ELB health has not been available for 37 minutes. Pas de données. Last seen 37 minutes ago.
## Info (vert)
Ce statut s'affiche lorsque :
+ Une opération est en cours sur une instance.
+ Une opération est en cours sur plusieurs instances d'un environnement.
*Exemple :* une nouvelle version d'application est en cours de déploiement dans les instances en cours d'exécution.
*Message (environnement) :* Command is executing on 3 out of 5 instances.
*Message (instance) :* Performing application deployment (running for 3 seconds).
## En attente (gris)
Ce statut s'affiche lorsqu'une opération est en cours sur une instance et que le [délai d'attente de la commande](health-enhanced.md#health-enhanced-factors-timeout) n'est pas dépassé.
*Exemple :* vous avez créé l'environnement récemment et des instances sont en cours d'amorçage.
*Message :* Performing initialization (running for 12 seconds).
## Inconnu (gris)
Ce statut s'affiche lorsqu'Elastic Beanstalk et l'agent de vérification de l'état signalent une quantité de données insuffisante sur une instance.
*Exemple :* aucune donnée n'est reçue.
## Suspendu (gris)
Ce statut s'affiche lorsqu'Elastic Beanstalk cesse de surveiller l'état de l'environnement. L'environnement peut ne pas fonctionner correctement. Certaines conditions d'état graves, si elles persistent, conduisent Elastic Beanstalk à faire passer l'environnement au statut **Suspendu**.
*Exemple :* Elastic Beanstalk ne parvient pas à accéder au [rôle de service](iam-servicerole.md) de l'environnement.
*Exemple :* le [groupe Auto Scaling](using-features.managing.as.md) créé par Elastic Beanstalk pour l'environnement a été supprimé.
*Message :* Environment health has transitioned from **OK** to **Severe**. Il n'y a aucune instance. La capacité souhaitée du groupe Auto Scaling est définie sur 1.
# Métriques des instances
Des métriques d'instance fournissent des informations sur l'intégrité d'instances dans votre environnement. L'[agent de vérification de l'état Elastic Beanstalk](health-enhanced.md#health-enhanced-agent) s'exécute sur chaque instance. Il rassemble et transmet à Elastic Beanstalk des métriques relatives aux instances. Elastic Beanstalk analyse ensuite ces métriques pour déterminer l'état des instances dans vos environnements.
L'agent de vérification de l'état Elastic Beanstalk sur instance recueille des métriques sur les instances à partir de serveurs web et du système d'exploitation. Pour obtenir des informations sur les serveurs web sur les plateformes Linux, Elastic Beanstalk lit et analyse les journaux des serveurs web. Sur la plateforme Windows Server, Elastic Beanstalk reçoit directement ces informations du serveur web IIS. Les serveurs web fournissent des informations sur les demandes HTTP entrantes : le nombre de requêtes qui sont entrées, combien ont généré des erreurs et le délai qui a été nécessaire à leur résolution. Le système d'exploitation fournit des informations d'instantané sur l'état des ressources des instances : la charge de l'UC et la distribution du temps consacré à chaque type de processus.
L'agent de vérification de l'état recueille des métriques de système d'exploitation et de serveur web et les transmet à Elastic Beanstalk toutes les 10 secondes. Elastic Beanstalk analyse les données et utilise les résultats pour mettre à jour l'état de santé de chaque instance et de l'environnement.
**Topics**
+ [Métriques de serveur web](#health-enhanced-metrics-server)
+ [Métriques du système d'exploitation](#health-enhanced-metrics-os)
+ [Capture des métriques du serveur web dans IIS sous Windows Server](health-enhanced-metrics-server-iis.md)
## Métriques de serveur web
Sur les plateformes Linux, l'agent de vérification de l'état Elastic Beanstalk lit les métriques de serveur web à partir des journaux générés par le conteneur web ou le serveur qui traite les demandes sur chaque instance de votre environnement. Les plateformes Elastic Beanstalk sont configurées pour générer deux journaux : un au format lisible par l'utilisateur et un au format lisible par la machine. L'agent de vérification de l'état transmet les journaux lisibles par la machine à Elastic Beanstalk toutes les 10 secondes.
Pour plus d'informations sur le format de journal utilisé par Elastic Beanstalk, consultez [Format de journal d'intégrité améliorée](health-enhanced-serverlogs.md).
Sur la plateforme Windows Server, Elastic Beanstalk ajoute un module au pipeline de demandes du serveur web IIS et capture les métriques relatives aux délais des demandes HTTP et aux codes de réponse. Le module envoie ces métriques à l'agent d'état de l'instance à l'aide d'un canal de communication inter-processus (IPC) hautes performances. Pour plus d’informations sur l’implémentation, consultez [Capture des métriques du serveur web dans IIS sous Windows Server](health-enhanced-metrics-server-iis.md).Métriques de serveur web signalées
`RequestCount`
Nombre de requêtes gérées par le serveur web par seconde au cours des 10 dernières secondes. Affiché comme un `r/sec` (demandes par seconde) moyen dans l'interface de ligne de commande EB et sur la [Page « Health (Santé) » de l'environnement](health-enhanced-console.md#health-enhanced-console-healthpage).
`Status2xx``Status3xx``Status4xx``Status5xx`
Nombre de requêtes ayant abouti sur chaque type de code de statut au cours des 10 dernières secondes. Par exemple, les demandes ayant abouti renvoient 200 OK, les redirections renvoient 301 et une erreur 404 est renvoyée si l'URL saisie ne correspond à aucune ressource de l'application.
L'interface de ligne de commande EB et la [Page « Health (Santé) » de l'environnement](health-enhanced-console.md#health-enhanced-console-healthpage) affichent ces métrique sous la forme d'un nombre brut de demandes pour les instances et sous la forme d'un pourcentage des demandes globales pour les environnements.
`p99.9``p99``p95``p90``p85``p75``p50``p10`
Moyenne de latence pour le pourcentage de requêtes *x* le plus lent au cours des 10 dernières secondes, où *x* est la différence entre le nombre et 100. Par exemple, `p99 1.403` indique que les demandes faisant partie des 1 % les plus lents au cours des 10 dernières secondes avaient une latence moyenne de 1 351 secondes.
## Métriques du système d'exploitation
L'agent de vérification de l'état Elastic Beanstalk rapporte les métriques de système d'exploitation suivantes. Elastic Beanstalk utilise ces métriques pour identifier les instances qui subissent une charge lourde constante. Les métriques diffèrent selon le système d'exploitation.Métriques de système d'exploitation signalées (Linux)
`Running`
Le temps qui s'est écoulé depuis le lancement de l'instance.
`Load 1``Load 5`
Charge moyenne au cours des dernières périodes de 1 minute et de 5 minutes. Affiché comme une valeur décimale indiquant le nombre moyen de processus qui s'exécutent pendant cette durée. Si le nombre affiché est supérieur au nombre de v CPUs (threads) disponibles, le reste correspond au nombre moyen de processus en attente.
Par exemple, si votre type d'instance comporte quatre V CPUs et que la charge est de 4,5, il y a eu en moyenne 0,5 processus en attente pendant cette période, soit l'équivalent d'un processus en attente 50 % du temps.
`User %``Nice %``System %``Idle %``I/O Wait %`
Pourcentage de temps que l'UC a consacré à chaque état au cours des 10 dernières secondes.Métriques de système d'exploitation signalées (Windows)
`Running`
Le temps qui s'est écoulé depuis le lancement de l'instance.
`% User Time``% Privileged Time``% Idle Time`
Pourcentage de temps que l'UC a consacré à chaque état au cours des 10 dernières secondes.
# Capture des métriques du serveur web dans IIS sous Windows Server
Sur la plateforme Windows Server, Elastic Beanstalk ajoute un module au pipeline de demandes du serveur web IIS et capture les métriques relatives aux délais des demandes HTTP et aux codes de réponse. Le module envoie ces métriques à l'agent d'état de l'instance à l'aide d'un canal de communication inter-processus (IPC) hautes performances. L'agent de vérification de l'état regroupe ces métriques, les combine avec celles du système d'exploitation et les envoie au service Elastic Beanstalk.
## Détails de l'implémentation
Pour capturer les métriques provenant d'IIS, Elastic Beanstalk implémente une interface [https://msdn.microsoft.com/en-us/library/system.web.ihttpmodule%28v=vs.110%29.aspx](https://msdn.microsoft.com/en-us/library/system.web.ihttpmodule%28v=vs.110%29.aspx) gérée et s'abonne aux événements [https://msdn.microsoft.com/en-us/library/system.web.httpapplication.beginrequest(v=vs.110).aspx](https://msdn.microsoft.com/en-us/library/system.web.httpapplication.beginrequest(v=vs.110).aspx) et [https://msdn.microsoft.com/en-us/library/system.web.httpapplication.endrequest(v=vs.110).aspx](https://msdn.microsoft.com/en-us/library/system.web.httpapplication.endrequest(v=vs.110).aspx). Cela permet au module de signaler la latence des requêtes HTTP et les codes de réponse pour toutes les requêtes web gérées par IIS. Pour ajouter le module au pipeline de demandes d'IIS, Elastic Beanstalk enregistre le module dans la section [https://docs.microsoft.com/en-us/iis/configuration/system.webserver/modules/](https://docs.microsoft.com/en-us/iis/configuration/system.webserver/modules/) du fichier de configuration IIS `%windir%\System32\inetsrv\config\applicationHost.config`.
Le module Elastic Beanstalk dans IIS envoie les métriques de demandes web capturées à l'agent de vérification de l'état sur instance, qui est un service Windows appelé `HealthD`. Pour envoyer ces données, le module utilise [https://msdn.microsoft.com/en-us/library/system.servicemodel.netnamedpipebinding(v=vs.110).aspx](https://msdn.microsoft.com/en-us/library/system.servicemodel.netnamedpipebinding(v=vs.110).aspx), qui fournit une liaison sécurisée et fiable, optimisée pour les communications machine.
# Configuration de règles d'intégrité améliorée pour un environnement
AWS Elastic Beanstalk les rapports de santé améliorés reposent sur un ensemble de règles visant à déterminer la santé de votre environnement. Certaines de ces règles peuvent ne pas être adaptées à votre application. Voici quelques exemples courants :
+ Vous utilisez des outils de test côté client. Dans ce cas, des erreurs fréquentes de client HTTP (4xx) sont attendues.
+ Vous utilisez [AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/) avec Application Load Balancer de votre environnement pour bloquer le trafic entrant indésirable. Dans ce cas, Application Load Balancer renvoie l'erreur HTTP 403 pour chaque message entrant rejeté.
Par défaut, Elastic Beanstalk inclut toutes les erreurs HTTP 4xx de l'application lors de la détermination de l'état de l'environnement. L'état de santé de votre environnement passe de **OK** à **Warning** (Avertissement), **Degraded** (Dégradé) ou **Severe** (Grave), en fonction du taux d'erreur. Pour gérer correctement les cas mentionnés dans les exemples précédents, Elastic Beanstalk vous permet de configurer certaines règles d'état améliorées. Vous pouvez choisir d'ignorer les erreurs HTTP 4xx de l'application sur les instances de l'environnement ou d'ignorer les erreurs HTTP 4xx renvoyées par l'équilibreur de charge de l'environnement. Cette rubrique décrit comment effectuer ces modifications de configuration.
**Note**
Actuellement, il s'agit de la seule personnalisation de règle d'intégrité améliorée disponible. Vous ne pouvez pas configurer l'intégrité améliorée pour ignorer d'autres erreurs HTTP en plus de 4xx.
## Configuration des règles d'état améliorées à l'aide de la console Elastic Beanstalk
Vous pouvez utiliser la console Elastic Beanstalk pour configurer les règles d'état améliorées dans votre environnement.
**Pour configurer la vérification des codes d'état HTTP 4xx à l'aide de la console Elastic Beanstalk**
1. Ouvrez la console [Elastic Beanstalk](https://console.aws.amazon.com/elasticbeanstalk), puis **dans la liste des régions, sélectionnez votre**. Région AWS
1. Dans le panneau de navigation, choisissez **Environments** (Environnements), puis choisissez le nom de votre environnement dans la liste.
1. Dans le panneau de navigation, choisissez **Configuration**.
1. Dans la catégorie de configuration **Monitoring (Surveillance)**, choisissez **Edit (Modifier)**.
1. Sous **Personnalisation de la règle de surveillance de l'intégrité**, activez ou désactivez les options **Ignorer** souhaitées.
![\[Section de personnalisation de la règle de surveillance de l'état sur la page de configuration de la surveillance de la console Elastic Beanstalk\]](http://docs.aws.amazon.com/fr_fr/elasticbeanstalk/latest/dg/images/enhanced-health-rule-customization.png)
1. Pour enregistrer les modifications, cliquez sur **Appliquer** en bas de la page.
## Configuration des règles d'intégrité améliorée à l'aide de l'interface de ligne de commande EB
Vous pouvez utiliser l'interface de ligne de commande EB pour configurer les règles d'état améliorées en enregistrant la configuration de votre environnement en local, en ajoutant une entrée qui configure les règles d'état améliorées, puis en chargeant la configuration dans Elastic Beanstalk. Vous pouvez appliquer la configuration enregistrée à un environnement pendant ou après la création.
**Pour configurer la vérification du code d'état HTTP 4xx à l'aide de l'interface de ligne de commande EB et des configurations enregistrées**
1. Initialisez votre dossier de projet avec [**eb init**](eb-cli3-configuration.md).
1. Créez un environnement en exécutant la commande **eb create**.
1. Enregistrez un modèle de configuration localement en exécutant la commande **eb config save**. L'exemple suivant utilise l'option `--cfg` pour spécifier le nom de la configuration.
```
$ eb config save --cfg 01-base-state
Configuration saved at: ~/project/.elasticbeanstalk/saved_configs/01-base-state.cfg.yml
```
1. Ouvrez le fichier de configuration enregistrée dans un éditeur de texte.
1. Sous `OptionSettings` > `aws:elasticbeanstalk:healthreporting:system:`, ajoutez une clé `ConfigDocument` pour lister chaque règle d'intégrité améliorée à configurer. Le `ConfigDocument` suivant désactive la vérification des codes d'état HTTP 4xx de l'application, tout en conservant la vérification du code HTTP 4xx de l'équilibreur de charge activé.
```
OptionSettings:
...
aws:elasticbeanstalk:healthreporting:system:
ConfigDocument:
Rules:
Environment:
Application:
ApplicationRequests4xx:
Enabled: false
ELB:
ELBRequests4xx:
Enabled: true
Version: 1
SystemType: enhanced
...
```
**Note**
Vous pouvez combiner `Rules` et `CloudWatchMetrics` dans le même paramètre d'option `ConfigDocument`. Le paramètre `CloudWatchMetrics` est décrit dans [Publication de métriques CloudWatch personnalisées Amazon pour un environnement](health-enhanced-cloudwatch.md).
Si vous avez précédemment activé `CloudWatchMetrics`, le fichier de configuration que vous récupérez à l'aide de la commande **eb config save** possède déjà une clé `ConfigDocument` avec une section `CloudWatchMetrics`. *Ne la supprimez pas* : ajoutez une section `Rules` dans la même valeur d'option `ConfigDocument`.
1. Enregistrez le fichier de configuration et fermez l'éditeur de texte. Dans cet exemple, le fichier de configuration mis à jour est enregistré avec un nom qui est différent (`02-cloudwatch-enabled.cfg.yml`) de celui du fichier de configuration téléchargé. Cela crée une configuration enregistrée distincte lorsque le fichier est téléchargé. Vous pouvez utiliser le même nom que le fichier téléchargé pour remplacer la configuration existante sans en créer une.
1. Utilisez la commande **eb config put** pour charger le fichier de configuration mis à jour dans Elastic Beanstalk.
```
$ eb config put 02-cloudwatch-enabled
```
Lorsque vous utilisez les commandes **eb config** `get` et `put` avec des configurations enregistrés, n'incluez pas l'extension de nom de fichier.
1. Appliquez la configuration enregistrée à votre environnement en cours d'exécution.
```
$ eb config --cfg 02-cloudwatch-enabled
```
L'option `--cfg` spécifie un fichier de configuration nommé qui est appliqué à l'environnement. Vous pouvez enregistrer le fichier de configuration en local ou dans Elastic Beanstalk. Si un fichier de configuration avec le nom spécifié existe dans les deux emplacements, l'interface de ligne de commande EB utilise le fichier local.
## Configuration des règles d'intégrité améliorée à l'aide d'un document de configuration
Le document de configuration pour les règles d'intégrité améliorée est un document JSON qui répertorie les règles à configurer.
L'exemple suivant montre un document de configuration qui désactive la vérification des codes d'état HTTP 4xx de l'application et active la vérification des codes d'état HTTP 4xx de l'équilibreur de charge.
```
{
"Rules": {
"Environment": {
"Application": {
"ApplicationRequests4xx": {
"Enabled": false
}
},
"ELB": {
"ELBRequests4xx": {
"Enabled": true
}
}
}
},
"Version": 1
}
```
Pour le AWS CLI, vous transmettez le document en tant que valeur de `Value` clé dans un argument de paramètres d'option, qui est lui-même un objet JSON. Dans ce cas, vous devez utiliser des guillemets d'échappement dans le document intégré. La commande suivante vérifie si les paramètres de configuration sont valides.
```
$ aws elasticbeanstalk validate-configuration-settings --application-name my-app --environment-name my-env --option-settings '[
{
"Namespace": "aws:elasticbeanstalk:healthreporting:system",
"OptionName": "ConfigDocument",
"Value": "{\"Rules\": { \"Environment\": { \"Application\": { \"ApplicationRequests4xx\": { \"Enabled\": false } }, \"ELB\": { \"ELBRequests4xx\": {\"Enabled\": true } } } }, \"Version\": 1 }"
}
]'
```
Pour un fichier de configuration `.ebextensions` au format YAML, vous pouvez fournir le document JSON en l'état.
```
option_settings:
- namespace: aws:elasticbeanstalk:healthreporting:system
option_name: ConfigDocument
value: {
"Rules": {
"Environment": {
"Application": {
"ApplicationRequests4xx": {
"Enabled": false
}
},
"ELB": {
"ELBRequests4xx": {
"Enabled": true
}
}
}
},
"Version": 1
}
```
# Publication de métriques CloudWatch personnalisées Amazon pour un environnement
Vous pouvez publier les données recueillies par le biais de rapports de santé AWS Elastic Beanstalk améliorés sur Amazon CloudWatch sous forme de statistiques personnalisées. La publication de métriques vous CloudWatch permet de surveiller l'évolution des performances des applications au fil du temps et d'identifier les problèmes potentiels en suivant l'évolution de l'utilisation des ressources et de la latence des demandes en fonction de la charge.
En publiant des métriques sur CloudWatch, vous les rendez également disponibles pour une utilisation avec [des graphiques de surveillance et des](environment-health-console.md#environment-health-console-graphs) [alarmes](using-features.alarms.md). Une métrique gratuite est automatiquement activée lorsque vous utilisez des rapports de santé améliorés. *EnvironmentHealth* Mesures personnalisées autres que celles liées *EnvironmentHealth*aux [CloudWatch frais](https://aws.amazon.com/cloudwatch/pricing/) standard.
Pour publier des métriques CloudWatch personnalisées pour un environnement, vous devez d'abord activer les rapports de santé améliorés sur l'environnement. Pour obtenir des instructions, consultez [Activation des rapports améliorés sur l'état Elastic Beanstalk](health-enhanced-enable.md).
**Topics**
+ [Métriques de création de rapports d'intégrité améliorés](#health-enhanced-cloudwatch-metrics)
+ [Configuration des CloudWatch métriques à l'aide de la console Elastic Beanstalk](#health-enhanced-cloudwatch-console)
+ [Configuration de métriques CloudWatch personnalisées à l'aide de l'interface de ligne de commande EB](#health-enhanced-cloudwatch-ebcli)
+ [Fourniture des documents de configuration des métriques personnalisées](#health-enhanced-cloudwatch-configdocument)
## Métriques de création de rapports d'intégrité améliorés
Lorsque vous activez les rapports de santé améliorés dans votre environnement, le système de rapports de santé améliorés publie automatiquement une [métrique CloudWatch personnalisée](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/publishingMetrics.html), *EnvironmentHealth*. [Pour publier des métriques supplémentaires CloudWatch, configurez votre environnement avec ces métriques à l'aide de la [console [Elastic Beanstalk](#health-enhanced-cloudwatch-console),](#health-enhanced-cloudwatch-ebcli) de l'EB CLI ou de .ebextensions.](command-options.md)
Vous pouvez publier les indicateurs de santé améliorés suivants depuis votre environnement vers CloudWatch.Métriques disponibles (toutes les plateformes)
`EnvironmentHealth`
*Environnement uniquement. * Il s'agit de la seule CloudWatch métrique publiée par le système de rapports de santé améliorés, sauf si vous configurez des métriques supplémentaires. L'état de l'environnement est représentée par un des sept [statuts](health-enhanced-status.md). Dans la CloudWatch console, ces statuts correspondent aux valeurs suivantes :
+ 0 – OK
+ 1 – Info
+ 5 – Inconnu
+ 10 – Pas de données
+ 15 – Avertissement
+ 20 – Dégradé
+ 25 – Grave
`InstancesSevere``InstancesDegraded``InstancesWarning``InstancesInfo``InstancesOk``InstancesPending``InstancesUnknown``InstancesNoData`
*Environnement uniquement. * Ces métriques indiquent le nombre d'instances dans les environnement avec chaque état de santé. `InstancesNoData` indique le nombre d'instances pour lesquelles aucune donnée ne sera reçue.
`ApplicationRequestsTotal``ApplicationRequests5xx``ApplicationRequests4xx``ApplicationRequests3xx``ApplicationRequests2xx`
*Instance et environnement. * Indique le nombre total de requêtes terminées par l'instance ou l'environnement et le nombre de requêtes ayant abouti avec chaque catégorie de code d'état.
`ApplicationLatencyP10``ApplicationLatencyP50``ApplicationLatencyP75``ApplicationLatencyP85``ApplicationLatencyP90``ApplicationLatencyP95``ApplicationLatencyP99``ApplicationLatencyP99.9`
*Instance et environnement. * Indique la quantité moyenne de temps, en secondes, nécessaire pour terminer le pourcentage *x* le plus rapide de requêtes.
`InstanceHealth`
*Instance uniquement.* Indique l'état d'intégrité actuel de l'instance. L'état d'instance est représentée par un statut (sur sept [statuts](health-enhanced-status.md) au total). Dans la CloudWatch console, ces statuts correspondent aux valeurs suivantes :
+ 0 – OK
+ 1 – Info
+ 5 – Inconnu
+ 10 – Pas de données
+ 15 – Avertissement
+ 20 – Dégradé
+ 25 – GraveMétriques disponibles (Linux)
`CPUIrq``CPUIdle``CPUUser``CPUSystem``CPUSoftirq``CPUIowait``CPUNice`
*Instance uniquement.* Indique le pourcentage de temps que l'UC a passé dans chaque état au cours de la dernière minute.
`LoadAverage1min`
*Instance uniquement.* La charge d'UC moyenne de l'instance au cours de la dernière minute.
`RootFilesystemUtil`
*Instance uniquement.* Indique le pourcentage d'espace disque en cours d'utilisation.Métriques disponibles (Windows)
`CPUIdle``CPUUser``CPUPrivileged`
Instance uniquement. Indique le pourcentage de temps que l'UC a passé dans chaque état au cours de la dernière minute.
## Configuration des CloudWatch métriques à l'aide de la console Elastic Beanstalk
Vous pouvez utiliser la console Elastic Beanstalk pour configurer votre environnement afin de publier des CloudWatch indicateurs de santé améliorés et de les rendre disponibles pour une utilisation avec des graphiques de surveillance et des alarmes.
**Pour configurer CloudWatch des métriques personnalisées dans la console Elastic Beanstalk**
1. Ouvrez la console [Elastic Beanstalk](https://console.aws.amazon.com/elasticbeanstalk), puis **dans la liste des régions, sélectionnez votre**. Région AWS
1. Dans le panneau de navigation, choisissez **Environments** (Environnements), puis choisissez le nom de votre environnement dans la liste.
1. Dans le panneau de navigation, choisissez **Configuration**.
1. Dans la catégorie de configuration **Monitoring (Surveillance)**, choisissez **Edit (Modifier)**.
1. Sous **Rapport sur l'état de santé**, sélectionnez les métriques d'instance et d'environnement que vous voulez publier dans CloudWatch. Pour sélectionner plusieurs métriques, appuyez sur la touche **Ctrl** tout en choisissant.
1. Pour enregistrer les modifications, cliquez sur **Appliquer** en bas de la page.
L'activation des métriques CloudWatch personnalisées les ajoute à la liste des métriques disponibles sur la [page **Monitoring**](environment-health-console.md).
## Configuration de métriques CloudWatch personnalisées à l'aide de l'interface de ligne de commande EB
Vous pouvez utiliser l'interface de ligne de commande EB pour configurer des métriques personnalisées en enregistrant la configuration de votre environnement en local, en ajoutant une entrée qui définit les métriques à publier, puis en chargeant la configuration dans Elastic Beanstalk. Vous pouvez appliquer la configuration enregistrée à un environnement pendant ou après la création.
**Pour configurer des métriques CloudWatch personnalisées à l'aide de l'interface de ligne de commande EB et des configurations enregistrées**
1. Initialisez votre dossier de projet avec [**eb init**](eb-cli3-configuration.md).
1. Créez un environnement en exécutant la commande **eb create**.
1. Enregistrez un modèle de configuration localement en exécutant la commande **eb config save**. L'exemple suivant utilise l'option `--cfg` pour spécifier le nom de la configuration.
```
$ eb config save --cfg 01-base-state
Configuration saved at: ~/project/.elasticbeanstalk/saved_configs/01-base-state.cfg.yml
```
1. Ouvrez le fichier de configuration enregistrée dans un éditeur de texte.
1. Sous `OptionSettings` >`aws:elasticbeanstalk:healthreporting:system:`, ajoutez une `ConfigDocument` clé pour activer chacune des CloudWatch mesures souhaitées. Par exemple, le `ConfigDocument` suivant publie des métriques `ApplicationRequests5xx` et `ApplicationRequests4xx` au niveau de l'environnement et des métriques `ApplicationRequestsTotal` au niveau de l'instance.
```
OptionSettings:
...
aws:elasticbeanstalk:healthreporting:system:
ConfigDocument:
CloudWatchMetrics:
Environment:
ApplicationRequests5xx: 60
ApplicationRequests4xx: 60
Instance:
ApplicationRequestsTotal: 60
Version: 1
SystemType: enhanced
...
```
Dans l'exemple, 60 indique le nombre de secondes entre les mesures. C'est la seule valeur actuellement prise en charge.
**Note**
Vous pouvez combiner `CloudWatchMetrics` et `Rules` dans le même paramètre d'option `ConfigDocument`. Le paramètre `Rules` est décrit dans [Configuration de règles d'intégrité améliorée pour un environnement](health-enhanced-rules.md).
Si vous avez précédemment utilisé `Rules` pour configurer les règles d'intégrité améliorée, le fichier de configuration que vous récupérez à l'aide de la commande **eb config save** possède déjà une clé `ConfigDocument` avec une section `Rules`. *Ne la supprimez pas* : ajoutez une section `CloudWatchMetrics` dans la même valeur d'option `ConfigDocument`.
1. Enregistrez le fichier de configuration et fermez l'éditeur de texte. Dans cet exemple, le fichier de configuration mis à jour est enregistré avec un nom qui est différent (`02-cloudwatch-enabled.cfg.yml`) de celui du fichier de configuration téléchargé. Cela crée une configuration enregistrée distincte lorsque le fichier est téléchargé. Vous pouvez utiliser le même nom que le fichier téléchargé pour remplacer la configuration existante sans en créer une.
1. Utilisez la commande **eb config put** pour charger le fichier de configuration mis à jour dans Elastic Beanstalk.
```
$ eb config put 02-cloudwatch-enabled
```
Lorsque vous utilisez les commandes **eb config** `get` et `put` avec des configurations enregistrées, n'incluez pas l'extension de fichier.
1. Appliquez la configuration enregistrée à votre environnement en cours d'exécution.
```
$ eb config --cfg 02-cloudwatch-enabled
```
L'option `--cfg` spécifie un fichier de configuration nommé qui est appliqué à l'environnement. Vous pouvez enregistrer le fichier de configuration en local ou dans Elastic Beanstalk. Si un fichier de configuration avec le nom spécifié existe dans les deux emplacements, l'interface de ligne de commande EB utilise le fichier local.
## Fourniture des documents de configuration des métriques personnalisées
Le document de configuration (config) pour les métriques CloudWatch personnalisées Amazon est un document JSON qui répertorie les métriques à publier au niveau de l'environnement et de l'instance. L'exemple suivant illustre un document de configuration qui active toutes les métriques personnalisées disponibles.
```
{
"CloudWatchMetrics": {
"Environment": {
"ApplicationLatencyP99.9": 60,
"InstancesSevere": 60,
"ApplicationLatencyP90": 60,
"ApplicationLatencyP99": 60,
"ApplicationLatencyP95": 60,
"InstancesUnknown": 60,
"ApplicationLatencyP85": 60,
"InstancesInfo": 60,
"ApplicationRequests2xx": 60,
"InstancesDegraded": 60,
"InstancesWarning": 60,
"ApplicationLatencyP50": 60,
"ApplicationRequestsTotal": 60,
"InstancesNoData": 60,
"InstancesPending": 60,
"ApplicationLatencyP10": 60,
"ApplicationRequests5xx": 60,
"ApplicationLatencyP75": 60,
"InstancesOk": 60,
"ApplicationRequests3xx": 60,
"ApplicationRequests4xx": 60
},
"Instance": {
"ApplicationLatencyP99.9": 60,
"ApplicationLatencyP90": 60,
"ApplicationLatencyP99": 60,
"ApplicationLatencyP95": 60,
"ApplicationLatencyP85": 60,
"CPUUser": 60,
"ApplicationRequests2xx": 60,
"CPUIdle": 60,
"ApplicationLatencyP50": 60,
"ApplicationRequestsTotal": 60,
"RootFilesystemUtil": 60,
"LoadAverage1min": 60,
"CPUIrq": 60,
"CPUNice": 60,
"CPUIowait": 60,
"ApplicationLatencyP10": 60,
"LoadAverage5min": 60,
"ApplicationRequests5xx": 60,
"ApplicationLatencyP75": 60,
"CPUSystem": 60,
"ApplicationRequests3xx": 60,
"ApplicationRequests4xx": 60,
"InstanceHealth": 60,
"CPUSoftirq": 60
}
},
"Version": 1
}
```
Pour le AWS CLI, vous transmettez le document en tant que valeur de `Value` clé dans un argument de paramètres d'option, qui est lui-même un objet JSON. Dans ce cas, vous devez utiliser des guillemets d'échappement dans le document intégré.
```
$ aws elasticbeanstalk validate-configuration-settings --application-name my-app --environment-name my-env --option-settings '[
{
"Namespace": "aws:elasticbeanstalk:healthreporting:system",
"OptionName": "ConfigDocument",
"Value": "{\"CloudWatchMetrics\": {\"Environment\": {\"ApplicationLatencyP99.9\": 60,\"InstancesSevere\": 60,\"ApplicationLatencyP90\": 60,\"ApplicationLatencyP99\": 60,\"ApplicationLatencyP95\": 60,\"InstancesUnknown\": 60,\"ApplicationLatencyP85\": 60,\"InstancesInfo\": 60,\"ApplicationRequests2xx\": 60,\"InstancesDegraded\": 60,\"InstancesWarning\": 60,\"ApplicationLatencyP50\": 60,\"ApplicationRequestsTotal\": 60,\"InstancesNoData\": 60,\"InstancesPending\": 60,\"ApplicationLatencyP10\": 60,\"ApplicationRequests5xx\": 60,\"ApplicationLatencyP75\": 60,\"InstancesOk\": 60,\"ApplicationRequests3xx\": 60,\"ApplicationRequests4xx\": 60},\"Instance\": {\"ApplicationLatencyP99.9\": 60,\"ApplicationLatencyP90\": 60,\"ApplicationLatencyP99\": 60,\"ApplicationLatencyP95\": 60,\"ApplicationLatencyP85\": 60,\"CPUUser\": 60,\"ApplicationRequests2xx\": 60,\"CPUIdle\": 60,\"ApplicationLatencyP50\": 60,\"ApplicationRequestsTotal\": 60,\"RootFilesystemUtil\": 60,\"LoadAverage1min\": 60,\"CPUIrq\": 60,\"CPUNice\": 60,\"CPUIowait\": 60,\"ApplicationLatencyP10\": 60,\"LoadAverage5min\": 60,\"ApplicationRequests5xx\": 60,\"ApplicationLatencyP75\": 60,\"CPUSystem\": 60,\"ApplicationRequests3xx\": 60,\"ApplicationRequests4xx\": 60,\"InstanceHealth\": 60,\"CPUSoftirq\": 60}},\"Version\": 1}"
}
]'
```
Pour un fichier de configuration `.ebextensions` au format YAML, vous pouvez fournir le document JSON en l'état.
```
option_settings:
- namespace: aws:elasticbeanstalk:healthreporting:system
option_name: ConfigDocument
value: {
"CloudWatchMetrics": {
"Environment": {
"ApplicationLatencyP99.9": 60,
"InstancesSevere": 60,
"ApplicationLatencyP90": 60,
"ApplicationLatencyP99": 60,
"ApplicationLatencyP95": 60,
"InstancesUnknown": 60,
"ApplicationLatencyP85": 60,
"InstancesInfo": 60,
"ApplicationRequests2xx": 60,
"InstancesDegraded": 60,
"InstancesWarning": 60,
"ApplicationLatencyP50": 60,
"ApplicationRequestsTotal": 60,
"InstancesNoData": 60,
"InstancesPending": 60,
"ApplicationLatencyP10": 60,
"ApplicationRequests5xx": 60,
"ApplicationLatencyP75": 60,
"InstancesOk": 60,
"ApplicationRequests3xx": 60,
"ApplicationRequests4xx": 60
},
"Instance": {
"ApplicationLatencyP99.9": 60,
"ApplicationLatencyP90": 60,
"ApplicationLatencyP99": 60,
"ApplicationLatencyP95": 60,
"ApplicationLatencyP85": 60,
"CPUUser": 60,
"ApplicationRequests2xx": 60,
"CPUIdle": 60,
"ApplicationLatencyP50": 60,
"ApplicationRequestsTotal": 60,
"RootFilesystemUtil": 60,
"LoadAverage1min": 60,
"CPUIrq": 60,
"CPUNice": 60,
"CPUIowait": 60,
"ApplicationLatencyP10": 60,
"LoadAverage5min": 60,
"ApplicationRequests5xx": 60,
"ApplicationLatencyP75": 60,
"CPUSystem": 60,
"ApplicationRequests3xx": 60,
"ApplicationRequests4xx": 60,
"InstanceHealth": 60,
"CPUSoftirq": 60
}
},
"Version": 1
}
```
# Utilisation des rapports améliorés sur l'état à l'aide de l'API Elastic Beanstalk
Étant donné que les rapports d'état AWS Elastic Beanstalk améliorés ont des exigences en matière de rôles et de solutions, vous devez mettre à jour les scripts et le code que vous utilisiez avant la publication des rapports d'état améliorés avant de pouvoir les utiliser. Pour assurer la rétrocompatibilité, les rapports améliorés sur l'état ne sont pas activés par défaut lorsque vous créez un environnement à l'aide de l'API Elastic Beanstalk.
Vous configurez des rapports de santé améliorés en définissant le rôle de service, le profil d'instance et les options CloudWatch de configuration Amazon pour votre environnement. Vous pouvez le faire de trois façons : en définissant les options de configuration dans le dossier `.ebextensions`, avec des configurations enregistrées ou en les configurant directement dans le paramètre `create-environment` de l'appel `option-settings`.
Pour utiliser l'API ou l'interface de ligne de AWS commande (CLI) afin de créer un environnement prenant en charge l'amélioration de la santé, vous devez : SDKs
+ Créez un rôle de service et un profil d'instance avec les [autorisations](concepts-roles.md) appropriées.
+ Créez un nouvel environnement avec une nouvelle [version de plateforme](concepts.platforms.md)
+ Définissez les [options de configuration](command-options.md) du type de système d'état, du profil d'instance et du rôle de service.
Utilisez les options de configuration suivantes dans les espaces de noms `aws:elasticbeanstalk:healthreporting:system`, `aws:autoscaling:launchconfiguration` et `aws:elasticbeanstalk:environment` afin de configurer votre environnement pour les rapports améliorés sur l'état.
## Options de configuration des rapports améliorés sur l'état
**SystemType**
Espace de nom : `aws:elasticbeanstalk:healthreporting:system`
Pour activer les rapports améliorés sur l'état, définissez l'option sur **enhanced**.
**IamInstanceProfile**
Espace de nom : `aws:autoscaling:launchconfiguration`
Choisissez le nom d'un profil d'instance configuré pour être utilisé avec Elastic Beanstalk.
**ServiceRole**
Espace de nom : `aws:elasticbeanstalk:environment`
Choisissez le nom d'un rôle de service configuré pour être utilisé avec Elastic Beanstalk.
**ConfigDocument** (facultatif)
Espace de nom : `aws:elasticbeanstalk:healthreporting:system`
Document JSON qui définit les métriques d'instance et d'environnement sur lesquelles publier CloudWatch. Par exemple :
```
{
"CloudWatchMetrics":
{
"Environment":
{
"ApplicationLatencyP99.9":60,
"InstancesSevere":60
}
"Instance":
{
"ApplicationLatencyP85":60,
"CPUUser": 60
}
}
"Version":1
}
```
**Note**
Les documents de configuration peuvent exiger une mise en forme spéciale, comme des guillemets d'échappement, en fonction de la façon dont vous les fournissez à Elastic Beanstalk. Pour obtenir des exemples, consultez [Fourniture des documents de configuration des métriques personnalisées](health-enhanced-cloudwatch.md#health-enhanced-cloudwatch-configdocument).
# Format de journal d'intégrité améliorée
AWS Elastic Beanstalk les plateformes utilisent un format de journal de serveur Web personnalisé pour transmettre efficacement les informations relatives aux requêtes HTTP au système amélioré de rapports de santé. Le système analyse les journaux, identifie les problèmes et définit en conséquence l'état de santé de l'instance et de l'environnement. Si vous désactivez le proxy de serveur web dans votre environnement et que vous traitez les demandes directement depuis le conteneur web, vous pouvez toujours utiliser pleinement les rapports améliorés sur l'état en configurant votre serveur de sorte à générer des journaux à l'emplacement et au format utilisés par l'[agent de vérification de l'état Elastic Beanstalk](health-enhanced.md#health-enhanced-agent).
**Note**
Les informations de cette page concernent uniquement les plateformes Linux. Sur la plateforme Windows Server, Elastic Beanstalk reçoit les informations sur les demandes HTTP directement à partir du serveur web IIS. Pour en savoir plus, consultez [Capture des métriques du serveur web dans IIS sous Windows Server](health-enhanced-metrics-server-iis.md).
## Configuration de journal de serveur web
Les plateformes Elastic Beanstalk sont configurées de sorte à générer deux journaux contenant des informations sur les demandes HTTP. La première est au format détaillé et fournit des informations complètes sur la demande, y compris les informations de l'agent utilisateur du demandeur et un horodatage contrôlable de visu.
**/var/log/nginx/access.journal**
L'exemple suivant provient d'un proxy nginx exécuté dans un environnement de serveur web Ruby, mais le format est similaire pour Apache.
```
172.31.24.3 - - [23/Jul/2015:00:21:20 +0000] "GET / HTTP/1.1" 200 11 "-" "curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3" "177.72.242.17"
172.31.24.3 - - [23/Jul/2015:00:21:21 +0000] "GET / HTTP/1.1" 200 11 "-" "curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3" "177.72.242.17"
172.31.24.3 - - [23/Jul/2015:00:21:22 +0000] "GET / HTTP/1.1" 200 11 "-" "curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3" "177.72.242.17"
172.31.24.3 - - [23/Jul/2015:00:21:22 +0000] "GET / HTTP/1.1" 200 11 "-" "curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3" "177.72.242.17"
172.31.24.3 - - [23/Jul/2015:00:21:22 +0000] "GET / HTTP/1.1" 200 11 "-" "curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3" "177.72.242.17"
```
Le deuxième journal est au format court. Il comporte des informations pertinentes uniquement pour la création de rapports d'intégrité améliorée. Ce journal est sorti vers un sous-dossier nommé `healthd` et tourne chaque heure. Les anciens journaux sont supprimés immédiatement après la rotation.
**/var/log/nginx/healthd/application.log.2015-07-23-00**
L'exemple suivant montre un journal au format lisible par la machine.
```
1437609879.311"/"200"0.083"0.083"177.72.242.17
1437609879.874"/"200"0.347"0.347"177.72.242.17
1437609880.006"/bad/path"404"0.001"0.001"177.72.242.17
1437609880.058"/"200"0.530"0.530"177.72.242.17
1437609880.928"/bad/path"404"0.001"0.001"177.72.242.17
```
Le format des journaux d'intégrité améliorée inclut les informations suivantes :
+ Le moment de la demande, en heure Unix
+ Le chemin d'accès de la demande
+ Le code de statut HTTP pour le résultat
+ La durée des demandes
+ Le temps en amont
+ L'en-tête HTTP `X-Forwarded-For`
Pour les proxys nginx, les heures sont indiquées en secondes à virgule flottante, avec trois décimales. Pour Apache, les millisecondes entières sont utilisées.
**Note**
Si un avertissement similaire au suivant s'affiche dans un fichier journal, où `DATE-TIME` correspond à une date et une heure, et que vous utilisez un proxy personnalisé, comme dans un environnement Docker multi-conteneurs, vous devez utiliser un fichier .ebextension pour configurer votre environnement afin que `healthd` puisse lire vos fichiers journaux :
```
W, [DATE-TIME #1922] WARN -- : log file "/var/log/nginx/healthd/application.log.DATE-TIME" does not exist
```
Vous pouvez commencer par le fichier .ebextension dans l'[exemple Docker multi-conteneurs](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/samples/docker-multicontainer-v2.zip).
**/etc/nginx/conf.d/webapp\$1healthd.conf**
L'exemple suivant montre la configuration de journal pour nginx avec le format de journal `healthd` mis en évidence.
```
upstream my_app {
server unix:///var/run/puma/my_app.sock;
}
log_format healthd '$msec"$uri"'
'$status"$request_time"$upstream_response_time"'
'$http_x_forwarded_for';
server {
listen 80;
server_name _ localhost; # need to listen to localhost for worker tier
if ($time_iso8601 ~ "^(\d{4})-(\d{2})-(\d{2})T(\d{2})") {
set $year $1;
set $month $2;
set $day $3;
set $hour $4;
}
access_log /var/log/nginx/access.log main;
access_log /var/log/nginx/healthd/application.log.$year-$month-$day-$hour healthd;
location / {
proxy_pass http://my_app; # match the name of upstream directive which is defined above
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location /assets {
alias /var/app/current/public/assets;
gzip_static on;
gzip on;
expires max;
add_header Cache-Control public;
}
location /public {
alias /var/app/current/public;
gzip_static on;
gzip on;
expires max;
add_header Cache-Control public;
}
}
```
**/etc/httpd/conf.d/healthd.conf**
L'exemple suivant montre la configuration des journaux pour Apache.
```
LogFormat "%{%s}t\"%U\"%s\"%D\"%D\"%{X-Forwarded-For}i" healthd
CustomLog "|/usr/sbin/rotatelogs /var/log/httpd/healthd/application.log.%Y-%m-%d-%H 3600" healthd
```
## Génération de journaux pour la création de rapports d'intégrité améliorée
Pour fournir des journaux à l'agent d'intégrité, vous devez procéder comme suit :
+ Sortir des journaux dans le bon format, comme illustré dans la section précédente
+ Sortir des journaux dans `/var/log/nginx/healthd/`
+ Nommer des journaux à l'aide du format suivant : `application.log.$year-$month-$day-$hour`
+ Effectuer une rotation des journaux une fois par heure
+ Ne pas tronquer de journaux
# Notifications et dépannage
**Essayez Amazon Q Developer CLI pour un dépannage assisté par l'IA**
La CLI Amazon Q Developer peut vous aider à résoudre rapidement les problèmes d'environnement. La Q CLI fournit des solutions en vérifiant l'état de l'environnement, en examinant les événements, en analysant les journaux et en posant des questions de clarification. Pour plus d'informations et des instructions détaillées, consultez la section [Résolution des problèmes liés aux environnements Elastic Beanstalk avec Amazon](https://aws.amazon.com/blogs/devops/troubleshooting-elastic-beanstalk-environments-with-amazon-q-developer-cli/) Q Developer CLI dans les blogs. AWS
Cette page répertorie les messages relatifs aux problèmes courants ainsi que des liens vers des informations supplémentaires. Les messages apparaissent dans [Volet de présentation de l'environnement](environments-dashboard-envoverview.md) la console Elastic Beanstalk et sont [enregistrés](using-features.events.md) lors d'événements où des problèmes de santé persistent après plusieurs vérifications.
## Déploiements
Elastic Beanstalk surveille la cohérence de votre environnement à la suite de déploiements. En cas de défaillance d'un déploiement propagé, la version de votre application s'exécutant sur les instances de votre environnement peut varier. Cela peut se produire si un déploiement réussit sur un ou plusieurs lots mais échoue avant que tous les lots aient abouti.
*Une version d'application incorrecte a été détectée sur 2 instances sur 5. Version attendue « v1 » (déploiement 1).*
*Version d'application incorrecte sur les instances de l'environnement. Version attendue « v1 » (déploiement 1).*
La version d'application attendue ne s'exécute pas sur tout ou partie des instances dans un environnement.
*Version d'application « v2 » incorrecte (déploiement 2). Version attendue « v1 » (déploiement 1).*
L'application déployée sur une instance diffère de la version attendue. En cas de défaillance d'un déploiement, la version attendue revient à la version du dernier déploiement ayant abouti. Dans l'exemple ci-dessus, le premier déploiement (version « v1 ») a abouti, mais le deuxième déploiement (version « v2 ») a échoué. Toutes les instances exécutant « v2 » sont considérées comme défectueuses.
Pour résoudre ce problème, démarrez un autre déploiement. Vous pouvez [redéployer une version précédente](using-features.deploy-existing-version.md) dont vous savez qu'elle fonctionne, ou configurer votre environnement pour [ignorer les vérifications de l'état](using-features.rolling-version-deploy.md#environments-cfg-rollingdeployments-console) au cours du déploiement et redéployer la nouvelle version pour forcer le déploiement à aboutir.
Vous pouvez également identifier et résilier les instances qui exécutent la mauvaise version d'application. Elastic Beanstalk lance des instances avec la version appropriée pour remplacer toutes les instances que vous résiliez. Utilisez la [commande d'état de l'interface de ligne de commande EB](health-enhanced-ebcli.md) pour identifier les instances qui exécutent la mauvaise version d'application.
## Serveur d'application
*15 % des demandes signalent une erreur avec HTTP 4xx*
*20 % des demandes à ELB signalent une erreur avec HTTP 4xx.*
Un pourcentage élevé de demandes HTTP à une instance ou un environnement échouent avec des erreurs 4xx.
Un code de statut de série 400 indique que l'utilisateur a soumis une demande erronée, telle que la demande d'une page qui n'existe pas (404 : Fichier introuvable) ou à laquelle l'utilisateur n'a pas accès à (403 Interdit). Un petit nombre d'erreurs 404 n'est pas rare, mais un grand nombre pourrait signifier qu'il y a des liens internes ou externes vers des pages indisponibles. Ces problèmes peuvent être résolus en réparant des liens internes erronés et en ajoutant des redirections pour des liens externes erronés.
*5 % des demandes échouent avec HTTP 5xx*
*3 % des demandes à ELB échouent avec HTTP 5xx.*
Un pourcentage élevé de demandes HTTP à une instance ou un environnement échoue avec les codes de statut de série 500.
Un code de statut de série 500 indique que le serveur d'applications a rencontré une erreur interne. Ces problèmes indiquent qu'il y a une erreur dans le code de votre application et ils doivent être identifiés et corrigés rapidement.
*95 % de l'UC est en cours d'utilisation*
Sur une instance, l'agent d'état rapporte un pourcentage extrêmement élevé d'utilisation de l'UC et définit l'état de l'instance sur **Avertissement** ou **Dégradé**.
Mettez à l'échelle votre environnement pour réduire la charge des instances.
## Instance de travail
*20 messages en attente dans la file d'attente (il y a 25 secondes)*
Des demandes sont ajoutées à la file d'attente de votre environnement de travail plus vite qu'elles ne peuvent être traitées. Mettez à l'échelle votre environnement pour accroître la capacité.
*5 messages dans la file d'attente de lettres mortes (il y a 15 secondes)*
Des demandes de travail échouent régulièrement et sont ajoutées à la [Files d’attente de lettres mortes](using-features-managing-env-tiers.md#worker-deadletter). Vérifiez les demandes dans la file d'attente de lettres mortes pour voir pourquoi elles échouent.
## Autres ressources
*4 instances actives est inférieur à la taille minimale 5 du groupe Auto Scaling*
Le nombre d'instances s'exécutant dans votre environnement est inférieur au nombre minimal configuré pour le groupe Auto Scaling.
*Des notifications du groupe Auto Scaling (nom du groupe) ont été supprimées ou modifiées*
Les notifications configurées pour votre groupe Auto Scaling ont été modifiées en dehors d'Elastic Beanstalk.
# Analyse de l'environnement basée sur l'IA
AWS Elastic Beanstalk L'analyse basée sur l'IA identifie les causes profondes et recommande des solutions aux problèmes de santé liés à l'environnement. Lorsque votre environnement rencontre des problèmes, vous pouvez demander une analyse de l'IA à l'aide des opérations d'`RetrieveEnvironmentInfo`API `RequestEnvironmentInfo` et de type `analyze` info pour obtenir des informations générées par l'IA et des solutions recommandées.
**Note**
L'analyse par IA n'est disponible que sur les versions compatibles d'Amazon Linux 2 et de la AL2023 plateforme publiées le 16 février 2026 ou après cette date.
## Comment ça marche
Lorsque vous demandez une analyse basée sur l'IA, Elastic Beanstalk exécute un script sur une instance de votre environnement qui collecte les événements récents, l'état de santé de l'instance et les journaux (jusqu'[à](https://docs.aws.amazon.com/bedrock/latest/userguide/key-definitions.html) 170 000 jetons de données). Il envoie ensuite ces données à Amazon Bedrock dans votre compte et renvoie des informations et des recommandations sur les prochaines étapes.
## Conditions préalables
Avant d'utiliser l'analyse par IA, vérifiez que votre environnement répond aux exigences suivantes :
+ Environnement exécutant une [version de plate-forme prise en charge](#health-ai-analysis-supported-platforms)
+ [Profil d'instance](iam-instanceprofile.md) avec les autorisations requises (voir [Autorisations requises](#health-ai-analysis-permissions) ci-dessous)
+ **Détails des cas d'utilisation anthropiques** — L'analyse de l'IA utilise les modèles Anthropic Claude via Amazon Bedrock. Anthropic vous demande de soumettre un formulaire détaillé de cas d'utilisation unique avant de pouvoir invoquer ses modèles. Pour soumettre ce formulaire, sélectionnez n'importe quel modèle Anthropic dans le catalogue de modèles de la [console Amazon Bedrock](https://console.aws.amazon.com/bedrock/) ou appelez l'[https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutUseCaseForModelAccess.html](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutUseCaseForModelAccess.html)API. Vous ne devez effectuer cette opération qu'une seule fois par AWS compte. Si vous soumettez le formulaire depuis le compte de gestion des AWS Organizations, il couvre automatiquement tous les comptes membres de l'organisation. Pour plus d'informations, consultez [Access Amazon Bedrock foundation models](https://docs.aws.amazon.com/bedrock/latest/userguide/model-access.html).
+ **GovCloud régions** — Si vous utilisez des régions AWS GovCloud (États-Unis), vous devez autoriser l'accès au dernier modèle Anthropic Claude Sonnet and/or Opus dans Amazon Bedrock avant d'utiliser l'analyse par IA. Pour obtenir des instructions sur l'activation de l'accès aux modèles dans GovCloud les régions, consultez [Gérer l'accès aux modèles Amazon Bedrock Foundation](https://docs.aws.amazon.com/bedrock/latest/userguide/model-access.html#model-access-govcloud). Pour plus d'informations sur le dernier modèle Anthropic Claude Sonnet and/or Opus disponible, voir [Régions et modèles pris en charge pour les profils d'inférence](https://docs.aws.amazon.com/bedrock/latest/userguide/inference-profiles-support.html).
## Autorisations requises
Pour utiliser l'analyse par IA, le profil d'instance Amazon EC2 de votre environnement doit être autorisé à invoquer Amazon Bedrock. Ajoutez les autorisations suivantes à votre profil d'instance :
+ `bedrock:InvokeModel`
+ `bedrock:ListFoundationModels`
+ `elasticbeanstalk:DescribeEvents`
+ `elasticbeanstalk:DescribeEnvironmentHealth`
Pour plus d'informations sur la configuration des profils d'instance, consultez[Gestion des profils d'instance Elastic Beanstalk](iam-instanceprofile.md).
## Utilisation de l'analyse de l'IA dans la console
**À partir de l'aperçu de l'environnement**
Lorsque l'état de santé de votre environnement est **Avertissement**, **Dégradé ou Sévère**, **un** bouton d'**analyse de l'IA** apparaît dans la section de présentation de l'environnement. Cliquez sur ce bouton pour lancer une analyse IA de votre environnement.
**Depuis la page Logs**
Vous pouvez également accéder à l'analyse de l'IA depuis la page **Logs** du volet de navigation. Cliquez sur le bouton **Analyse de l'IA** pour demander une analyse basée sur l'IA de l'état actuel de votre environnement.
## Utilisation de l'analyse basée sur l'IA avec AWS CLI
Vous pouvez utiliser l'API Elastic Beanstalk via le pour demander et récupérer des analyses d'IA AWS CLI par programmation.
**Demander une analyse de l'IA**
Utilisez l'[https://docs.aws.amazon.com/elasticbeanstalk/latest/api/API_RequestEnvironmentInfo.html](https://docs.aws.amazon.com/elasticbeanstalk/latest/api/API_RequestEnvironmentInfo.html)opération avec le `InfoType` paramètre défini sur`analyze`.
**Example AWS CLI - Demander une analyse de l'IA**
```
aws elasticbeanstalk request-environment-info \
--environment-name my-env \
--info-type analyze \
--region us-east-1
```
**Récupérez une analyse d'IA**
Utilisez l'[https://docs.aws.amazon.com/elasticbeanstalk/latest/api/API_RetrieveEnvironmentInfo.html](https://docs.aws.amazon.com/elasticbeanstalk/latest/api/API_RetrieveEnvironmentInfo.html)opération avec le `InfoType` paramètre défini sur `analyze` pour récupérer les résultats de l'analyse.
**Example AWS CLI - Récupérez l'analyse de l'IA**
```
aws elasticbeanstalk retrieve-environment-info \
--environment-name my-env \
--info-type analyze \
--region us-east-1
```
La réponse inclut une analyse de l'état actuel de l'environnement générée par l'IA, ainsi que des solutions recommandées pour tout problème identifié.
## Utilisation de l'analyse de l'IA avec l'EB CLI
Si vous utilisez l'EB CLI, vous pouvez demander une analyse de l'IA avec l'option `--analyze` (`-ai`) de la **eb logs** commande. La commande demande l'analyse, attend qu'elle soit terminée et affiche les résultats.
**Example EB CLI - Demander une analyse de l'IA**
```
$ eb logs --analyze
```
L'`--analyze`option n'est pas compatible avec `--instance``--all`,`--zip`, ou`--log-group`. Pour la référence complète des commandes, voir[**eb logs**](eb3-logs.md).
**Note**
L'`--analyze`option nécessite la version 3.27 ou ultérieure de l'EB CLI.
## Considérations importantes
+ **Tarification** — L'analyse basée sur l'IA utilise Amazon Bedrock pour traiter les données de votre environnement, et la tarification standard d'Amazon Bedrock s'applique aux appels de modèles. Pour plus de détails sur la tarification, consultez [Tarification Amazon Bedrock](https://aws.amazon.com/bedrock/pricing/).
+ **Configuration requise** : l'analyse de l'IA n'est disponible que sur Amazon Linux 2 et sur les versions AL2023 basées sur la plateforme publiées le 16 février 2026 ou après cette date. Pour utiliser cette fonctionnalité, mettez à jour votre environnement vers une version de plate-forme prise en charge. Pour de plus amples informations, veuillez consulter [Mise à jour de la version de la plateforme de votre environnement Elastic Beanstalk](using-features.platform.upgrade.md).
+ **Autorisations** — Avant d'utiliser l'analyse par IA, assurez-vous que votre profil d'instance dispose des autorisations Amazon Bedrock (`bedrock:InvokeModel`et`bedrock:ListFoundationModels`) et des autorisations Elastic `elasticbeanstalk:DescribeEvents` Beanstalk (et) requises. `elasticbeanstalk:DescribeEnvironmentHealth`
+ **Confidentialité des données** — L'analyse envoie les événements environnementaux et les journaux à Amazon Bedrock dans votre compte pour traitement. Pour plus d'informations sur la manière dont Amazon Bedrock gère vos données, consultez [Amazon Bedrock Security and](https://aws.amazon.com/bedrock/security-compliance/) Compliance.
+ **Quotas de service** — L'analyse par IA utilise un modèle Anthropic Claude dans Amazon Bedrock, qui a des quotas par défaut pour les demandes par minute et les jetons par minute. Si vous rencontrez des erreurs de régulation, vous pouvez demander une augmentation du quota. Pour plus d’informations, consultez [Demande d’augmentation de quota](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html).
## Versions de plateforme prises en charge
L'analyse par IA est prise en charge sur Amazon Linux 2 et AL2023 sur les versions basées sur la plateforme publiées le [16 février 2026](RELEASE_NOTES_URL) ou après cette date. Pour vérifier la version de votre plateforme, consultez les notes de mise à jour d'[Elastic Beanstalk](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/welcome.html).
# Gestion des alarmes
Cette rubrique explique les étapes à suivre pour créer des alarmes pour les indicateurs que vous surveillez. Il fournit également des instructions pour consulter vos alarmes existantes et vérifier leur état.
Vous pouvez créer des alarmes pour les métriques que vous surveillez en utilisant la console Elastic Beanstalk. Les alarmes vous aident à surveiller les modifications apportées à votre AWS Elastic Beanstalk environnement afin que vous puissiez facilement identifier et atténuer les problèmes avant qu'ils ne surviennent. Par exemple, vous pouvez définir une alarme qui vous informe lorsque l'utilisation de l'UC dans un environnement dépasse un certain seuil, veiller à ce que être notifié avant qu'un problème potentiel se produise. Pour de plus amples informations, veuillez consulter [Utilisation d'Elastic Beanstalk avec Amazon CloudWatch](AWSHowTo.cloudwatch.md).
**Note**
Elastic CloudWatch Beanstalk l'utilise pour la surveillance et les alarmes CloudWatch , ce qui signifie que des coûts sont appliqués AWS à votre compte pour toutes les alarmes que vous utilisez.
Pour plus d'informations sur la surveillance des métriques spécifiques, consultez [Création de rapports d'intégrité de base](using-features.healthstatus.md).
**Pour vérifier l'état de vos alarmes**
1. Ouvrez la console [Elastic Beanstalk](https://console.aws.amazon.com/elasticbeanstalk), puis **dans la liste des régions, sélectionnez votre**. Région AWS
1. Dans le panneau de navigation, choisissez **Environments** (Environnements), puis choisissez le nom de votre environnement dans la liste.
1. Dans le panneau de navigation, cliquez sur **Alarms (alertes)**.
La page affiche une liste d’alarmes existantes. Si des alarmes sont en état d'alarme, elles sont signalées par l'icône d'avertissement (![\[Image of the warning icon.\]](http://docs.aws.amazon.com/fr_fr/elasticbeanstalk/latest/dg/images/warning.png)).
1. Pour filtrer les alarmes, choisissez le menu déroulant, puis sélectionnez un filtre.
1. Pour modifier ou supprimer une alarme, choisissez respectivement l'icône de modification (![\[Image of a cog, which serves as the edit icon.\]](http://docs.aws.amazon.com/fr_fr/elasticbeanstalk/latest/dg/images/cog.png)) ou l'icône de suppression (![\[Image of an x, which servers as the delete icon.\]](http://docs.aws.amazon.com/fr_fr/elasticbeanstalk/latest/dg/images/x.png)).
**Pour créer une alarme**
1. Ouvrez la console [Elastic Beanstalk](https://console.aws.amazon.com/elasticbeanstalk), puis **dans la liste des régions, sélectionnez votre**. Région AWS
1. Dans le panneau de navigation, choisissez **Environments** (Environnements), puis choisissez le nom de votre environnement dans la liste.
1. Dans le panneau de navigation, choisissez **Surveillance**.
1. Localisez la métrique pour laquelle vous souhaitez créer une alarme, puis choisissez l'icône d'alarme (![\[Image of a bell, which serves as the alarm icon.\]](http://docs.aws.amazon.com/fr_fr/elasticbeanstalk/latest/dg/images/bell.png)). La page **Add alarm (Ajouter une alarme)** s'affiche.
1. Entrez les détails relatifs à l'alarme :
+ **Nom** : un nom pour cette alarme.
+ **Description** (facultatif) : une brève description de ce qu'est cette alarme.
+ **Période** : l'intervalle de temps entre les lectures.
+ **Seuil** : décrit le comportement et la valeur que la métrique doit dépasser afin de déclencher une alarme.
+ **Changer l'état après** : le délai après qu'un seuil a été dépassé qui déclenche une modification de l'état de l'alarme.
+ **Notifier** : rubrique Amazon SNS qui est notifiée lorsqu'une alarme change d'état.
+ **Notifier quand l'état passe à** :
+ **OK** : La métrique se trouve dans le seuil défini.
+ **Alarme** : la métrique a dépassé le seuil défini.
+ **Données insuffisantes** : l'alarme vient de démarrer, la métrique n'est pas disponible, ou la quantité de données n'est pas suffisante pour permettre à la métrique de déterminer le statut de l'alarme.
1. Choisissez **Ajouter**. L'état de l'environnement passe au gris pendant la mise à jour de l'environnement. Vous pouvez afficher l'alarme que vous avez créée en choisissant **Alarms (Alarmes)** dans le volet de navigation.
# Affichage de l'historique des modifications d'un environnement Elastic Beanstalk
Cette rubrique explique comment utiliser la console Elastic Beanstalk pour consulter l'historique des modifications de configuration apportées à vos environnements Elastic Beanstalk.
Elastic Beanstalk récupère votre historique des modifications à partir d'événements enregistrés dans [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) et les affiche dans une liste que vous pouvez facilement parcourir et filtrer.
Le panneau Change History (Historique des modifications) affiche les informations suivantes concernant les modifications apportées à vos environnements :
+ la date et l'heure auxquelles une modification a été apportée ;
+ l'utilisateur IAM responsable d'une modification ;
+ l'outil source (l'interface de ligne de commande Elastic Beanstalk (CLI EB) ou la console) utilisé pour effectuer la modification ;
+ le paramètre de configuration et les nouvelles valeurs qui ont été définies.
Les données sensibles faisant partie de la modification, telles que les noms des utilisateurs de base de données concernés par la modification, n'apparaissent pas dans le panneau.
**Pour afficher l'historique des modifications**
1. Ouvrez la console [Elastic Beanstalk](https://console.aws.amazon.com/elasticbeanstalk), puis **dans la liste des régions, sélectionnez votre**. Région AWS
1. Dans le panneau de navigation, sélectionnez **Change history (Historique des modifications)**.
La page Change History (Historique des modifications) affiche une liste des modifications de configuration apportées à vos environnements Elastic Beanstalk.
Notez les points suivants concernant la navigation dans les informations de cette page :
+ Vous pouvez parcourir la liste en sélectionnant **<** (précédent) ou **>** (suivant) ou en sélectionnant un numéro de page spécifique.
+ Sous la colonne **Configuration changes (Modifications de configuration)**, sélectionnez l'icône flèche pour basculer entre le développement et la réduction de la liste des modifications sous l'en-tête **Changes made (Modifications apportées)**.
+ Utilisez la barre de recherche pour filtrer vos résultats à partir de la liste de l'historique des modifications. Vous pouvez saisir n'importe quelle chaîne pour affiner la liste des modifications qui s'affichent.
Remarques sur le filtrage des résultats affichés :
+ Le filtre de recherche n'est pas sensible à la casse.
+ Vous pouvez filtrer les modifications affichées en fonction des informations figurant dans la colonne **Configuration changes (Modifications de configuration)**, même si elles ne sont pas visibles parce qu'elles sont réduites dans **Changes made (Modifications apportées)**.
+ Vous ne pouvez filtrer que les résultats affichés. Toutefois, le filtre ne change pas même si vous sélectionnez le bouton pour accéder à une autre page et afficher plus de résultats. Vos résultats filtrés s'ajoutent également au jeu de résultats de la page suivante.
Les exemples suivants montrent comment filtrer les données affichées sur l'écran précédent :
+ Entrez **GettingStartedApp-env** dans le champ de recherche pour affiner les résultats afin d'inclure uniquement les modifications apportées à l'environnement nommé *GettingStartedApp-env*.
+ Saisissez **example3** dans la zone de recherche pour affiner les résultats et inclure uniquement les modifications apportées par les utilisateurs IAM dont le nom d'utilisateur contient la chaîne *exemple3*.
+ Saisissez **2020-10** dans la zone de recherche pour affiner les résultats et inclure uniquement les modifications apportées au cours du mois d'octobre 2020. Définissez la valeur de recherche sur **2020-10-16** pour filtrer davantage les résultats affichés et inclure uniquement les modifications effectuées le jour du 16 octobre 2020.
+ Saisissez **proxy:staticfiles** dans la zone de recherche pour affiner les résultats et inclure uniquement les modifications apportées à l'espace de nom nommé *aws:elasticbeanstalk:environment:proxy:staticfiles*. Les lignes affichées sont le résultat du filtre. Cela est vrai même pour les résultats qui sont réduits sous **Changes made (Modifications apportées)**.
# Affichage du flux d'événements d'un environnement Elastic Beanstalk
Cette rubrique explique comment accéder aux événements et aux notifications associés à votre application.
## Afficher des événements avec la console Elastic Beanstalk
**Pour consulter les événements avec la console Elastic Beanstalk**
1. Ouvrez la console [Elastic Beanstalk](https://console.aws.amazon.com/elasticbeanstalk), puis **dans la liste des régions, sélectionnez votre**. Région AWS
1. Dans le panneau de navigation, choisissez **Environments** (Environnements), puis choisissez le nom de votre environnement dans la liste.
1. Dans le panneau de navigation, sélectionnez **Events**.
La page Événements affiche une liste de tous les événements enregistrés pour l'environnement. Vous pouvez parcourir la liste en choisissant **<** (précédent), **>** (suivant) ou les numéros de page. Vous pouvez filtrer selon le type d'événement affiché à l'aide de la liste déroulante **Severity (Gravité)**.
## Affichage des événements à l'aide des outils de ligne de commande
L'[interface de ligne de commande EB](eb-cli3.md) et l'[AWS CLI](https://aws.amazon.com/cli/) fournissent toutes les deux des commandes permettant de récupérer les événements. Si vous gérez votre environnement via l'interface de ligne de commande EB, utilisez [**eb events**](eb3-events.md) pour imprimer la liste des événements. Cette commande inclut également une option `--follow`, qui continue d'afficher les nouveaux événements jusqu'à ce que vous appuyiez sur **Ctrl\$1C** pour arrêter la sortie.
Pour extraire des événements à l'aide de AWS CLI, utilisez la `describe-events` commande et spécifiez l'environnement par son nom ou son identifiant :
```
$ aws elasticbeanstalk describe-events --environment-id e-gbjzqccra3
{
"Events": [
{
"ApplicationName": "elastic-beanstalk-example",
"EnvironmentName": "elasticBeanstalkExa-env",
"Severity": "INFO",
"RequestId": "a4c7bfd6-2043-11e5-91e2-9114455c358a",
"Message": "Environment update completed successfully.",
"EventDate": "2015-07-01T22:52:12.639Z"
},
...
```
Pour plus d'informations sur les outils de ligne de commande, consultez[Configuration de l'interface de ligne de commande EB (EB CLI) pour gérer Elastic Beanstalk](eb-cli3.md).
# Affichage de la liste des instances de serveur et connexion à ces instances
Cette rubrique explique comment consulter la liste des EC2 instances Amazon exécutant votre environnement applicatif Elastic Beanstalk et comment s'y connecter.
Vous pouvez consulter la liste des EC2 instances Amazon exécutant votre environnement AWS Elastic Beanstalk applicatif via la console Elastic Beanstalk. Vous pouvez vous connecter aux instances en utilisant tout client SSH. Vous pouvez vous connecter aux instances exécutant Windows à l'aide de Bureau à distance.
**Important**
Avant de pouvoir accéder à vos instances Amazon EC2 fournies par Elastic Beanstalk, vous devez créer une EC2 paire de clés Amazon et configurer votre Amazon Elastic Beanstalk provisionnée pour utiliser la paire de clés Amazon. EC2instances EC2 Vous pouvez configurer vos paires de EC2 clés Amazon à l'aide de la [console AWS de gestion](https://console.aws.amazon.com/). Pour obtenir des instructions sur la création d'une paire de clés pour Amazon EC2, consultez le *guide de EC2 démarrage Amazon*. Pour plus d'informations sur la façon de configurer vos EC2 instances Amazon pour utiliser une paire de EC2 clés Amazon, consultez[EC2 paire de clés](using-features.managing.security.md#using-features.managing.security.keypair).
Par défaut, Elastic Beanstalk n'active pas les EC2 connexions à distance aux instances d'un conteneur Windows, à l'exception de celles des anciens conteneurs Windows. (Elastic EC2 Beanstalk configure les instances des anciens conteneurs Windows pour utiliser le port 3389 pour les connexions RDP.) Vous pouvez activer les connexions à distance à vos EC2 instances exécutant Windows en ajoutant une règle à un groupe de sécurité qui autorise le trafic entrant vers les instances. Nous vous recommandons vivement de supprimer la règle lorsque vous mettez fin à votre connexion à distance. Vous pouvez ajouter la règle à nouveau la prochaine fois que vous avez besoin de vous connecter à distance. Pour de plus amples informations, veuillez consulter [Ajout d'une règle pour le trafic RDP entrant vers une instance Windows](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/authorizing-access-to-an-instance.html#authorizing-access-to-an-instance-rdp) et [Connexion à votre instance Windows](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/EC2Win_GetStarted.html#connecting_to_windows_instance) dans le *Guide de l'utilisateur Amazon Elastic Compute Cloud pour Microsoft Windows*.
**Pour consulter les EC2 instances Amazon d'un environnement et s'y connecter**
1. Ouvrez la EC2 console Amazon à l'adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Dans le panneau de navigation de la console, choisissez **Équilibreurs de charge**.
1. Les équilibreurs de charge créés par Elastic Beanstalk ont **awseb** dans le nom. Recherchez l'équilibreur de charge pour votre environnement et cliquez dessus.
1. Dans le volet inférieur de la console, choisissez l'onglet **Instances**.
Une liste des instances qu'utilise l'équilibreur de charge pour votre environnement Elastic Beanstalk s'affiche. Notez un ID d'instance auquel vous souhaitez vous connecter.
1. Dans le volet de navigation de la EC2 console Amazon, choisissez **Instances** et recherchez l'ID de votre instance dans la liste.
1. Cliquez avec le bouton droit sur l'ID d' EC2 instance de l'instance Amazon exécutée dans l'équilibreur de charge de votre environnement, puis sélectionnez **Connect** dans le menu contextuel.
1. Notez adresse DNS publique de l'instance sur l'onglet **Description**.
1. Connectez-vous à une instance exécutant Linux à l'aide du client SSH de votre choix, puis tapez **ssh -i .ec2/mykeypair.pem ec2-User@. of-the-instance
Pour plus d'informations sur la connexion à une instance Amazon EC2 Linux, consultez [Getting Started with Amazon EC2 Linux Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html) dans le *guide de EC2 l'utilisateur Amazon*.
*Si votre environnement Elastic Beanstalk [utilise la plateforme .NET on Windows Server, consultez Getting Started with EC2 Amazon Windows](create_deploy_NET.container.console.md) [Instances dans le guide de l'utilisateur Amazon](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/EC2_GetStarted.html). EC2 *
# Affichage des journaux des instances Amazon EC2 dans votre environnement Elastic Beanstalk
Cette rubrique décrit les types de journaux d'instance fournis par Elastic Beanstalk. Il fournit également des instructions détaillées pour les récupérer et les gérer.
Les instances Amazon EC2 de votre environnement Elastic Beanstalk génèrent des journaux que vous pouvez afficher pour résoudre les problèmes avec vos fichiers de configuration ou d'application. Les journaux sont créés par le serveur Web, le serveur d'applications, les scripts de la plateforme Elastic Beanstalk et sont stockés localement sur CloudFormation des instances individuelles. Vous pouvez les récupérer facilement avec la [console de gestion d'environnement](environments-console.md) ou l'interface de ligne de commande EB. Vous pouvez également configurer votre environnement pour diffuser les journaux sur Amazon CloudWatch Logs en temps réel.
Les journaux des processus sont les 100 dernières lignes des fichiers journaux les plus couramment utilisés : les journaux opérationnels Elastic Beanstalk et les journaux provenant du serveur web ou du serveur d'applications. Lorsque vous demandez des journaux de queue dans la console de gestion d'environnement ou avec **eb logs**, une instance dans votre environnement concatène les entrées du journal les plus récentes dans un fichier texte unique et les télécharge sur Amazon S3.
Les journaux de groupe sont des journaux complets pour un plus large éventail de fichiers journaux, y compris des journaux yum et cron et plusieurs journaux CloudFormation. Lorsque vous demandez des journaux de groupe, une instance de votre environnement rassemble les fichiers journaux complets dans une archive ZIP et les télécharge sur Amazon S3.
Pour télécharger les journaux soumis à rotation sur Amazon S3, les instances de votre environnement doivent avoir un [profil d'instance](concepts-roles-instance.md) avec l'autorisation d'écrire sur votre compartiment Elastic Beanstalk Amazon S3. Ces autorisations sont incluses dans le profil d'instance par défaut qu'Elastic Beanstalk vous invite à créer lorsque vous lancez un environnement dans la console Elastic Beanstalk pour la première fois.
**Pour récupérer des journaux d'instance**
1. Ouvrez la console [Elastic Beanstalk](https://console.aws.amazon.com/elasticbeanstalk), puis **dans la liste des régions, sélectionnez votre**. Région AWS
1. Dans le panneau de navigation, choisissez **Environments** (Environnements), puis choisissez le nom de votre environnement dans la liste.
1. Dans le panneau de navigation, sélectionnez **Logs** (Journaux).
1. Choisissez **Request Logs (Journaux de demande)**, puis choisissez le type de journaux à récupérer. Pour obtenir des journaux de processus, choisissez **Last 100 Lines (100 dernières lignes)**. Pour obtenir des journaux de bundle, choisissez **Full Logs (Journaux complets)**.
1. Quand Elastic Beanstalk a fini de récupérer vos journaux, choisissez **Download (Télécharger)**.
Elastic Beanstalk stocke les journaux de queue et de bundle dans un compartiment Amazon S3 et génère une URL Amazon S3 présignée que vous pouvez utiliser pour accéder à vos journaux. Elastic Beanstalk supprime les fichiers d'Amazon S3 après une durée de 15 minutes.
**Avertissement**
Quiconque possédant l'URL Amazon S3 pré-signée peut consulter les fichiers avant qu'ils ne soient supprimés. Faites en sorte que seules les parties approuvées aient accès à l'URL.
**Note**
Votre stratégie utilisateur doit disposer de l'autorisation `s3:DeleteObject`. Elastic Beanstalk utilise vos autorisations utilisateur pour supprimer les journaux d'Amazon S3.
Pour conserver des journaux, vous pouvez configurer votre environnement afin de publier les journaux dans Amazon S3 automatiquement après leur rotation. Pour activer la rotation des journaux dans Amazon S3, suivez la procédure présentée dans [Configuration de l'affichage des journaux d'instance](environments-cfg-logging.md#environments-cfg-logging-console). Les instances dans votre environnement essaient de télécharger des journaux qui ont fait l'objet d'une rotation une fois par heure.
Si votre application génère des journaux dans un emplacement qui ne fait pas partie de la configuration par défaut de la plateforme de votre environnement, vous pouvez étendre la configuration par défaut à l'aide des fichiers de configuration (`[.ebextensions](ebextensions.md)`). Vous pouvez ajouter les fichiers journaux de votre application aux journaux de processus, aux journaux de groupe ou à la rotation des journaux.
Pour le streaming des journaux en temps réel et le stockage à long terme, configurez votre environnement pour qu'il [diffuse les journaux vers Amazon CloudWatch Logs](#health-logs-cloudwatchlogs).
Pour obtenir une analyse basée sur l'IA des journaux, des événements et de l'état de votre instance de votre environnement afin d'identifier les causes profondes des problèmes de santé et d'y apporter des solutions, consultez. [Analyse de l'environnement basée sur l'IA](health-ai-analysis.md)
**Topics**
+ [Emplacement des journaux sur les instances Amazon EC2](#health-logs-instancelocation)
+ [Emplacement des journaux dans Amazon S3](#health-logs-s3location)
+ [Paramètres de rotation des journaux sous Linux](#health-logs-logrotate)
+ [Extension de la configuration de tâche de journal par défaut](#health-logs-extend)
+ [Streaming de fichiers journaux vers Amazon CloudWatch Logs](#health-logs-cloudwatchlogs)
## Emplacement des journaux sur les instances Amazon EC2
Les journaux sont stockés dans des emplacements standard des instances Amazon EC2 de votre environnement. Elastic Beanstalk génère les journaux suivants.
**Amazon Linux 2**
+ `/var/log/eb-engine.log`
**AMI Amazon Linux (AL1)**
**Note**
[Le 18 juillet 2022,](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2022-07-18-linux-al1-retire.html) **Elastic Beanstalk a défini le statut de toutes les branches de la plateforme sur la base de l'AMI AL1 Amazon Linux () comme étant supprimées.** Pour plus d'informations sur la migration vers une branche de plateforme Amazon Linux 2023 actuelle et entièrement prise en charge, consultez [Migration de votre application Elastic Beanstalk Linux vers Amazon Linux 2023 ou Amazon Linux 2](using-features.migration-al.md).
+ `/var/log/eb-activity.log`
+ `/var/log/eb-commandprocessor.log`
**Windows Server**
+ `C:\Program Files\Amazon\ElasticBeanstalk\logs\`
+ `C:\cfn\log\cfn-init.log`
Ces journaux contiennent des messages sur les activités de déploiement, y compris des messages liés aux fichiers de configuration ([`.ebextensions`](ebextensions.md)).
Chaque serveur d'applications et web stocke des journaux dans son propre dossier :
+ **Apache** : `/var/log/httpd/`
+ **IIS** : `C:\inetpub\wwwroot\`
+ **Node.js** : `/var/log/nodejs/`
+ **nginx** : `/var/log/nginx/`
+ **Passenger** : `/var/app/support/logs/`
+ **Puma** : `/var/log/puma/`
+ **Python** : `/opt/python/log/`
+ **Tomcat** : `/var/log/tomcat/`
## Emplacement des journaux dans Amazon S3
Lorsque vous demandez les journaux de queue ou de bundle à partir de votre environnement, ou lorsque des instances téléchargent les journaux ayant fait l'objet d'une rotation, ils sont stockés dans votre compartiment Elastic Beanstalk d'Amazon S3. Elastic Beanstalk crée un `elasticbeanstalk-region-account-id` bucket nommé AWS pour chaque région dans laquelle vous créez des environnements. Dans ce compartiment, les journaux sont stockés dans le chemin d'accès `resources/environments/logs/logtype/environment-id/instance-id`.
Par exemple, les journaux de l'instance`i-0a1fd158`, dans l' AWS environnement Elastic `e-mpcwnwheky` Beanstalk `us-west-2` dans Region `123456789012` in account, sont stockés aux emplacements suivants :
+ **Journaux de queue** :
`s3://elasticbeanstalk-us-west-2-123456789012/resources/environments/logs/tail/e-mpcwnwheky/i-0a1fd158`
+ **Journaux de groupe** :
`s3://elasticbeanstalk-us-west-2-123456789012/resources/environments/logs/bundle/e-mpcwnwheky/i-0a1fd158`
+ **Journaux ayant fait l'objet d'une rotation** :
`s3://elasticbeanstalk-us-west-2-123456789012/resources/environments/logs/publish/e-mpcwnwheky/i-0a1fd158`
**Note**
Vous trouverez l'ID de votre environnement dans la console de gestion d'environnement.
Elastic Beanstalk supprime automatiquement les journaux de queue et de bundle d'Amazon S3 15 minutes après leur création. Les journaux faisant l'objet d'une rotation sont conservés jusqu'à ce que vous les supprimiez ou que vous les déplaciez vers Amazon Glacier.
## Paramètres de rotation des journaux sous Linux
Sur les plates-formes Linux, Elastic Beanstalk utilise `logrotate` pour soumettre les journaux à rotation régulièrement. Si la configuration a été effectuée, une fois qu'un journal a effectué sa rotation localement, la tâche de rotation le sélectionne et le télécharge sur Amazon S3. Les journaux qui ont fait l'objet d'une rotation localement ne s'affichent pas dans les journaux de processus ou de groupe par défaut.
Vous pouvez trouver les fichiers de configuration Elastic Beanstalk pour `logrotate` dans `/etc/logrotate.elasticbeanstalk.hourly/`. Ces paramètres de rotation sont propres à la plateforme et sont susceptibles de changer dans de futures versions de la plateforme. Pour plus d'informations concernant les paramètres disponibles et les exemples de configurations, exécutez `man logrotate`.
Les fichiers de configuration sont invoqués par des tâches cron dans `/etc/cron.hourly/`. Pour obtenir plus d'informations concernant `cron`, exécutez `man cron`.
## Extension de la configuration de tâche de journal par défaut
Elastic Beanstalk utilise des fichiers des sous-répertoires de `/opt/elasticbeanstalk/tasks` (Linux) ou `C:\Program Files\Amazon\ElasticBeanstalk\config` (Windows Server) sur l'instance Amazon EC2 pour configurer les tâches pour les journaux de queue, les journaux de bundle et la rotation des journaux.
**Sur Amazon Linux :**
+ **Journaux de queue** :
`/opt/elasticbeanstalk/tasks/taillogs.d/`
+ **Journaux de groupe** :
`/opt/elasticbeanstalk/tasks/bundlelogs.d/`
+ **Journaux ayant fait l'objet d'une rotation** :
`/opt/elasticbeanstalk/tasks/publishlogs.d/`
**Sous Windows Server :**
+ **Journaux de queue** :
`c:\Program Files\Amazon\ElasticBeanstalk\config\taillogs.d\`
+ **Journaux de groupe** :
`c:\Program Files\Amazon\ElasticBeanstalk\config\bundlelogs.d\`
+ **Journaux ayant fait l'objet d'une rotation** :
`c:\Program Files\Amazon\ElasticBeanstalk\config\publogs.d\`
Par exemple, le fichier `eb-activity.conf` sous Linux ajoute deux fichiers journaux à la tâche de journaux de processus.
**`/opt/elasticbeanstalk/tasks/taillogs.d/eb-activity.conf `**
```
/var/log/eb-commandprocessor.log
/var/log/eb-activity.log
```
Vous pouvez utiliser les fichiers de configuration d'environnement (`[.ebextensions](ebextensions.md)`) pour ajouter vos propres fichiers `.conf` à ces dossiers. Un fichier `.conf` répertorie les fichiers journaux spécifiques à votre application, qu'Elastic Beanstalk ajoute aux tâches des fichiers journaux.
Utilisez la section `files` pour ajouter des fichiers de configuration aux tâches que vous voulez modifier. Par exemple, le texte de configuration suivant ajoute un fichier de configuration du journal à chaque instance dans votre environnement. Ce fichier de configuration du journal, `cloud-init.conf`, ajoute `/var/log/cloud-init.log` aux journaux de processus.
```
files:
"/opt/elasticbeanstalk/tasks/taillogs.d/cloud-init.conf" :
mode: "000755"
owner: root
group: root
content: |
/var/log/cloud-init.log
```
Ajoutez ce texte à un fichier avec l'extension de nom de fichier `.config` à votre bundle de fichiers source sous un dossier nommé `.ebextensions`.
```
~/workspace/my-app
|-- .ebextensions
| `-- tail-logs.config
|-- index.php
`-- styles.css
```
Sur les plateforme Linux, vous pouvez également utiliser des caractères génériques dans les configurations de tâche de journal. Ce fichier de configuration ajoute tous les fichiers avec l'extension de nom de fichier `.log` provenant du dossier `log` situé à la racine de l'application aux journaux de bundle.
```
files:
"/opt/elasticbeanstalk/tasks/bundlelogs.d/applogs.conf" :
mode: "000755"
owner: root
group: root
content: |
/var/app/current/log/*.log
```
Les configurations de tâche de journal ne prennent pas en charge les caractères génériques sur les plateformes Windows.
**Note**
Pour vous familiariser avec les procédures de personnalisation des journaux, vous pouvez déployer un exemple d'application à l'aide de l'[interface de ligne de commande EB](eb-cli3.md). Pour cela, l'interface de ligne de commande EB crée un répertoire d'application local qui contient un sous-répertoire `.ebextentions` avec un exemple de configuration. Vous pouvez également utiliser les fichiers journaux de l’exemple d'application pour explorer la fonction d'extraction du journal décrite dans cette rubrique.
Pour de plus amples informations sur l'utilisation des fichiers de configuration, veuillez consulter [Personnalisation d'environnement avancée avec fichiers de configuration (`.ebextensions`)](ebextensions.md).
De la même manière que pour l'extension des journaux de processus et des journaux de groupe, vous pouvez étendre la rotation des journaux à l'aide d'un fichier de configuration. Chaque fois que Elastic Beanstalk fait pivoter ses propres journaux et les télécharge sur Amazon S3, il soumet également à rotation et télécharge vos journaux supplémentaires. L'extension de la rotation des journaux se comporte différemment en fonction du système d'exploitation utilisé par la plateforme. Les sections suivantes décrivent les deux cas possibles.
### Extension de la rotation des journaux sous Linux
Comme expliqué dans [Paramètres de rotation des journaux sous Linux](#health-logs-logrotate), Elastic Beanstalk utilise `logrotate` pour soumettre les journaux à rotation sur les plateformes Linux. Lorsque vous configurez les fichiers journaux de votre application pour la rotation des fichiers, l'application n'a pas besoin de créer de copies des fichiers journaux. Elastic Beanstalk configure `logrotate` pour créer une copie des fichiers journaux de votre application pour chaque rotation. Par conséquent, l'application doit conserver les fichiers journaux déverrouillés lorsqu'elle n'écrit pas activement dans ces journaux.
### Extension de la rotation des journaux sous Windows Server
Sur Windows Server, lorsque vous configurez les fichiers journaux de votre application pour la rotation, l'application doit effectuer une rotation régulière des fichiers journaux. Elastic Beanstalk recherche les fichiers dont le nom commence par le modèle que vous avez configuré et les sélectionne pour les charger vers Amazon S3. En outre, les points dans le nom du fichier sont ignorés et Elastic Beanstalk considère que le nom du fichier journal de base s'arrête au point.
Elastic Beanstalk charge toutes les versions d'un fichier journal de base, à l'exception de la plus récente qu'il considère comme le fichier journal actif de l'application, qui peut parfois être verrouillé. Votre application peut, par conséquent, garder le fichier journal actif verrouillé entre les rotations.
Par exemple, votre application écrit dans un fichier journal nommé `my_log.log`, et vous spécifiez ce nom dans votre fichier `.conf`. L'application effectue une rotation périodique du fichier. Pendant le cycle de rotation d'Elastic Beanstalk, les fichiers suivants se trouvent dans le dossier des fichiers journaux : `my_log.log`, `my_log.0800.log`, `my_log.0830.log`. Elastic Beanstalk considère tous ces fichiers comme des versions du nom de base `my_log`. Le fichier `my_log.log` comporte l'heure de modification la plus récente. Ainsi, Elastic Beanstalk charge uniquement les deux autres fichiers, `my_log.0800.log` et `my_log.0830.log`.
## Streaming de fichiers journaux vers Amazon CloudWatch Logs
[Vous pouvez configurer votre environnement pour diffuser les journaux vers Amazon CloudWatch Logs dans la console Elastic Beanstalk ou en utilisant les options de configuration.](command-options.md) Avec CloudWatch Logs, chaque instance de votre environnement diffuse des journaux vers des groupes de journaux que vous pouvez configurer pour qu'ils soient conservés pendant des semaines, voire des années, même après la fermeture de votre environnement.
L'ensemble des journaux diffusés varie selon l'environnement, mais il inclut toujours `eb-engine.log` et les journaux d'accès provenant du serveur proxy nginx ou Apache qui s'exécute devant votre application.
Vous pouvez configurer la diffusion de journaux dans la console Elastic Beanstalk [pendant la création de l'environnement](environments-create-wizard.md#environments-create-wizard-software) ou [pour un environnement existant](environments-cfg-logging.md#environments-cfg-logging-console). Vous pouvez définir les options suivantes depuis la console : activer/désactiver le streaming des CloudWatch journaux vers Logs, définir le nombre de jours de rétention et sélectionner l'une des options du cycle de vie. Dans l'exemple suivant, les journaux sont conservés jusqu'à sept jours, même lorsque l'environnement est résilié.
![\[Image d'écran des paramètres CloudWatch des journaux dans la console Elastic Beanstalk.\]](http://docs.aws.amazon.com/fr_fr/elasticbeanstalk/latest/dg/images/log-streaming-screen.png)
Le [fichier de configuration](ebextensions.md) suivant active la diffusion de journaux avec une conservation de 180 jours, même si l'environnement a été résilié.
**Example .ebextensions/log-streaming.config**
```
option_settings:
aws:elasticbeanstalk:cloudwatch:logs:
StreamLogs: true
DeleteOnTerminate: false
RetentionInDays: 180
```
# Afficher les journaux de déploiement pour un environnement Elastic Beanstalk
Elastic Beanstalk génère un journal de déploiement pour chaque déploiement dans votre environnement. Le journal de déploiement fournit une vue chronologique consolidée de ce qui s'est passé au cours d'un déploiement, notamment de l'installation des dépendances, des résultats de compilation, du démarrage de l'application et des éventuelles erreurs rencontrées. Vous pouvez utiliser les journaux de déploiement pour diagnostiquer rapidement les échecs des déploiements sans avoir à vous connecter aux instances par SSH ou à corréler plusieurs fichiers journaux.
Les journaux de déploiement sont écrits localement sur chaque instance. Pour les déploiements déclenchés via la console, la CLI, l'API ou les mises à jour gérées, une instance télécharge en permanence son journal sur Amazon S3 pendant le déploiement. La console Elastic Beanstalk lit le journal depuis Amazon S3, ce qui vous permet de suivre les progrès sans vous connecter à l'instance.
Les journaux de déploiement sont conçus pour être concis. En cas de succès, le journal affiche uniquement des messages récapitulatifs (par exemple, quelles commandes ont été exécutées et terminées). En cas d'échec, le journal inclut jusqu'à 50 lignes de sortie de l'étape ayant échoué, de sorte que vous pouvez voir l'erreur sans passer au crible les résultats détaillés.
**Note**
Les journaux de déploiement sont disponibles sur les versions des plateformes [Amazon Linux 2](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2026-03-11-al2.html) [et Amazon Linux 2023](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2026-03-11-al2023.html) publiées le 11 mars 2026 ou après cette date. Les plateformes Windows ne sont actuellement pas prises en charge.
## Opérations prises en charge
Les journaux de déploiement sont générés pour les opérations suivantes :
+ **Déploiements d'applications** — Déploiement d'une nouvelle version d'application dans votre environnement.
+ **Mises à jour de configuration** : modification des paramètres de configuration de l'environnement qui nécessitent des mises à jour d'instance.
+ **Création d'un environnement** : déploiement initial lorsque vous créez un nouvel environnement.
+ **Redémarrer le serveur d'applications** : redémarrez le serveur d'applications sur vos instances.
Les opérations qui ne modifient pas l'état de l'application ou de la configuration sur les instances, telles que la demande de journaux, l'échange CNAMEs ou la mise à jour de balises, ne génèrent pas de journaux de déploiement.
## Contenu du journal de déploiement
Un journal de déploiement enregistre les informations suivantes lors d'un déploiement :
+ **Cycle de vie du déploiement** : messages de début et de fin pour chaque phase de déploiement, tels que `Starting Application deployment` et`Completed Application deployment`.
+ **Sortie .ebextensions** — En cas de succès, les noms des commandes exécutées. En cas d'échec, les 50 dernières lignes de `cfn-init` sortie pour aider à diagnostiquer le problème.
+ **Sortie des hooks de la plateforme** : en cas de succès, les noms des scripts d'accroche exécutés. En cas d'échec, les 50 dernières lignes du hook sont sorties.
+ **Installation des dépendances** : sortie des gestionnaires de packages tels que **npm install****pip install**,**composer install**, et**bundle install**. En cas de succès, seul un message de fin est enregistré. En cas de panne, les 50 dernières lignes de sortie sont incluses.
+ **Sortie de construction** : sortie à partir de commandes de génération telles que **docker build****go build**, et les versions Java. En cas de panne, les 50 dernières lignes de sortie sont incluses.
+ **Sortie de démarrage de l'application** : sortie initiale de votre application après son démarrage. La source dépend de votre plateforme :
+ *Docker* — Journaux de conteneurs provenant de ou **docker logs** **docker compose logs**
+ *Java SE, Go, Node.js, Python, Ruby, .NET* — Procédez aux journaux stdout
+ *Tomcat* — Catalina enregistre les résultats
+ *PHP* — Journaux d'erreurs du master et du pool PHP-FPM
+ *ECS* — Journaux de conteneur de chaque conteneur de tâches
**Note**
La sortie de l'application est capturée 2 secondes après le démarrage de l'application. Seuls les messages de démarrage initiaux sont inclus. Si votre application met plus de temps à produire une sortie, celle-ci n'apparaîtra pas dans le journal de déploiement. Pour consulter les journaux complets des applications, demandez des journaux de bundle ou connectez-vous directement à l'instance. Pour de plus amples informations, veuillez consulter [Affichage des journaux d'instance](using-features.logging.md).
Lorsqu'une étape de déploiement échoue, le journal la marque `[ERROR]` et inclut jusqu'à 50 lignes de sortie de l'étape échouée. Si le journal de déploiement ne contient pas suffisamment de détails, vous pouvez récupérer les journaux d'instance complets (y compris `eb-engine.log``eb-hooks.log`, et les journaux d'application) à partir de l'onglet **Logs**. Pour de plus amples informations, veuillez consulter [Affichage des journaux des instances Amazon EC2 dans votre environnement Elastic Beanstalk](using-features.logging.md).
## Afficher les journaux de déploiement dans la console
La console Elastic Beanstalk **propose** un onglet Déploiements sur le tableau de bord de l'environnement où vous pouvez consulter l'historique et les journaux de vos déploiements.
### Afficher l'historique des déploiements
**Pour consulter l'historique des déploiements**
1. Ouvrez la console [Elastic Beanstalk](https://console.aws.amazon.com/elasticbeanstalk), puis **dans la liste des régions, sélectionnez votre**. Région AWS
1. Dans le panneau de navigation, choisissez **Environments** (Environnements), puis choisissez le nom de votre environnement dans la liste.
1. Dans le tableau de bord de l'environnement, choisissez l'onglet **Déploiements**.
L'onglet Déploiements affiche un tableau des déploiements pour l'environnement. Chaque ligne inclut les informations suivantes :
+ **ID de demande** : identifiant unique pour le déploiement.
+ **État** — *Succès*, *échec* ou *en cours*.
+ **Type : type** de déploiement, tel que *création d'environnement*, *déploiement d'applications*, mise à jour de *configuration, mise à* *jour de plate-forme gérée*, *redémarrage du serveur d'applications*, *environnement de reconstruction*, *environnement de restauration*, *domaine d'environnement d'échange* ou *fin d'environnement*.
+ **Heure de début** : date à laquelle le déploiement a commencé.
+ **Durée : durée** du déploiement.
Lorsqu'un déploiement est en cours, l'onglet interroge automatiquement les mises à jour. Vous pouvez également cliquer sur le bouton d'actualisation pour recharger manuellement la liste.
### Afficher les détails et les journaux du déploiement
**Pour consulter les détails du déploiement**
1. Dans l'onglet **Déploiements**, choisissez le lien **Request ID** pour le déploiement que vous souhaitez inspecter.
1. La page détaillée du déploiement présente une section récapitulative avec l'ID de demande, le statut, le type de déploiement, l'heure de début, la durée et la politique de déploiement. La politique de déploiement (par exemple, *Tout en une fois*, *Rolling*, *Rolling with additional batch*, *Immuable* ou *Traffic Splitting*) est affichée lorsqu'elle peut être déterminée à partir des événements de déploiement.
1. Sous le résumé, choisissez l'un des onglets suivants :
+ **Événements** : chronologie des événements liés à ce déploiement, filtrée pour n'afficher que les événements relatifs au déploiement sélectionné.
+ **Journaux de déploiement** : journal de déploiement consolidé de l'instance. Vous pouvez effectuer une recherche, filtrer par niveau de journal et télécharger le fichier journal.
Pour les déploiements en cours, l'onglet journaux est automatiquement actualisé pour afficher les nouvelles entrées de journal au fur et à mesure qu'elles sont écrites. Une fois le déploiement terminé, la console récupère l'état final du journal pour s'assurer que vous voyez le résultat complet.
**Important**
L'affichage des journaux de déploiement dans la console nécessite une `s3:GetObject` autorisation sur le compartiment de stockage Amazon S3 de l'environnement (`elasticbeanstalk-region-account-id`). Si votre politique IAM n'inclut pas cette autorisation, l'historique et les événements du déploiement seront toujours disponibles, mais l'onglet journaux affichera une erreur.
## Fichiers journaux de déploiement sur les instances
Les journaux de déploiement sont écrits `/var/log/deployments/` dans le répertoire de chaque instance. Le nom du fichier journal dépend de la manière dont le déploiement a été déclenché :
+ **Déploiements contrôlés par le flux de travail** (déclenchés via la console, la CLI ou l'API) —`eb-deployment-request-id.log`, où *request-id* est l'ID unique de demande de déploiement.
+ **Déploiements à démarrage automatique** (lancement d'instance ou redémarrage du serveur d'applications) —. `eb-deployment-unix-timestamp.log`
Elastic Beanstalk fait automatiquement pivoter ces fichiers, en conservant les 50 journaux de déploiement les plus récents sur chaque instance.
Pour les déploiements contrôlés par le flux de travail, le journal est chargé sur Amazon S3 via le chemin suivant :
```
s3://elasticbeanstalk-region-account-id/resources/environments/logs/deployments/environment-id/log-filename
```
Dans les environnements multi-instances, la première instance à commencer le téléchargement revendique le rôle pour l'ensemble du déploiement. Cette instance télécharge son journal sur Amazon S3 pendant toute la durée du déploiement. Toutes les instances continuent d'écrire des journaux de déploiement localement.
**Important**
Le téléchargement des journaux de déploiement vers Amazon S3 nécessite une `s3:PutObject` autorisation sur le compartiment de stockage Amazon S3 de l'environnement dans le profil d'instance, et la configuration du VPC doit autoriser la connectivité à Amazon S3.
Les téléchargements du journal de déploiement sont plafonnés à 1 Mo par fichier. Si un journal de déploiement dépasse cette taille, la version téléchargée est tronquée avec un message indiquant que le journal complet est disponible sur l'instance.
### Désactiver les téléchargements de journaux S3
Pour empêcher le chargement des journaux de déploiement sur Amazon S3, définissez la propriété d'environnement suivante sur votre environnement :
```
option_settings:
- namespace: aws:elasticbeanstalk:application:environment
option_name: EB_DEPLOYMENT_LOG_S3_DISABLED
value: true
```
Lorsque cette propriété d'environnement est définie, les journaux de déploiement sont toujours écrits localement `/var/log/deployments/` sur chaque instance, mais ils ne sont pas téléchargés sur Amazon S3 et ne seront pas disponibles dans l'onglet **Déploiements** de la console. Vous pouvez également définir cette propriété dans la page **Configuration** sous **Logiciel**, ou à l'aide de l'EB CLI ou AWS CLI.