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. # Personnalisation du logiciel sur des serveurs Linux Cette section décrit le type d'informations que vous pouvez inclure dans un fichier de configuration pour personnaliser le logiciel sur vos EC2 instances exécutant Linux. Pour obtenir des informations générales sur la personnalisation et la configuration de vos environnements Elastic Beanstalk, veuillez consulter [Configuration d'environnements Elastic Beanstalk](customize-containers.md). Pour plus d'informations sur la personnalisation du logiciel sur vos EC2 instances exécutant Windows, consultez[Personnalisation du logiciel sur des serveurs Windows](customize-containers-windows-ec2.md). Vous pouvez souhaiter personnaliser et configurer le logiciel dont dépend votre application. Vous pouvez ajouter des commandes à exécuter pendant le provisionnement de l’instance, définir des utilisateurs et des groupes Linux et télécharger ou créer directement des fichiers sur vos instances d'environnement. Ces fichiers peuvent être des dépendances requises par l'application (par exemple, des packages supplémentaires provenant du référentiel yum) ou des fichiers de configuration en remplacement d'un fichier de configuration de proxy par exemple, pour remplacer des paramètres spécifiques qui sont définis par défaut par Elastic Beanstalk. **Remarques** Sur les plateformes Amazon Linux 2, au lieu de fournir des fichiers et des commandes dans des fichiers de configuration .ebextensions, nous vous recommandons vivement d'utiliser *Buildfile*, *Profile* et les *hooks de plateforme* dès que possible, pour configurer et exécuter du code personnalisé sur vos instances d'environnement pendant le provisionnement d'instance. Pour plus d'informations sur ces mécanismes, consultez [Extension des plateformes Linux Elastic Beanstalk](platforms-linux-extend.md). YAML utilise une mise en retrait cohérente. Respectez le niveau de retrait lorsque vous remplacez du contenu dans un exemple de fichier de configuration et veillez à ce que votre éditeur de texte utilise des espaces, et non des caractères de tabulation, pour la mise en retrait. Les fichiers de configuration prennent en charge les clés suivantes qui affectent le serveur Linux sur lequel votre application s'exécute. **Topics** + [Forfaits](#linux-packages) + [Groupes](#linux-groups) + [Utilisateurs](#linux-users) + [Sources](#linux-sources) + [Fichiers](#linux-files) + [Commandes](#linux-commands) + [Services](#linux-services) + [Commandes de conteneur](#linux-container-commands) + [Exemple : utilisation de CloudWatch métriques Amazon personnalisées](customize-containers-cw.md) Les clés sont traitées dans l'ordre dans lequel elles sont répertoriées ici. Observez les [événements](using-features.events.md) de votre environnement pendant le développement et les tests des fichiers de configuration. Elastic Beanstalk ignore un fichier de configuration qui contient des erreurs de validation, comme une clé non valide, et ne traite aucune autre clé dans le même fichier. Lorsque cela se produit, Elastic Beanstalk ajoute un événement d'avertissement dans le journal des événements. ## Forfaits Vous pouvez utiliser la clé `packages` pour télécharger et installer des applications et des composants prépackagés. ### Syntaxe ``` packages: name of package manager: package name: version ... name of package manager: package name: version ... ... ``` Vous pouvez spécifier plusieurs packages sous chaque clé de gestionnaire de package. ### Formats de packages pris en charge Actuellement, Elastic Beanstalk prend en charge les gestionnaires de package suivants : yum, rubygems, python et rpm. Les packages sont traités dans l'ordre suivant : rpm, yum, puis rubygems et python. Il n'y a pas de classement entre rubygems et python. Au sein de chaque gestionnaire de packages, l'ordre des packages d'installation n'est pas garanti. Utilisez un gestionnaire de package pris en charge par votre système d'exploitation. **Note** Elastic Beanstalk prend en charge deux gestionnaires de package sous-jacents pour Python : pip et easy\$1install. Toutefois, dans la syntaxe du fichier de configuration, vous devez spécifier `python` comme nom du gestionnaire de package. Lorsque vous utilisez un fichier de configuration pour spécifier un gestionnaire de package Python, Elastic Beanstalk utilise Python 2.7. Si votre application repose sur une autre version de Python, vous pouvez indiquer que les packages doivent être installés dans un fichier `requirements.txt`. Pour de plus amples informations, veuillez consulter [Spécification des dépendances à l'aide d'un fichier d'exigences sur Elastic Beanstalk](python-configuration-requirements.md). ### Spécification des versions Au sein de chaque gestionnaire de package, chaque package est spécifié sous la forme d'un nom de package et d'une liste de versions. La version peut être une chaîne, une liste de versions, ou une chaîne ou une liste vide. Une chaîne ou une liste vide indique que vous souhaitez la dernière version. Pour le gestionnaire rpm, la version est spécifiée sous la forme d'un chemin d'accès à un fichier sur disque ou d'une URL. Les chemins relatifs ne sont pas pris en charge. Si vous spécifiez une version d'un package, Elastic Beanstalk tente d'installer cette version, même si une version plus récente du package est déjà installée sur l'instance. Si une version plus récente est déjà installée, le déploiement échoue. Certains gestionnaires de package prennent en charge plusieurs versions, mais pas tous. Veuillez vérifier la documentation de votre gestionnaire de package pour plus d'informations. Si vous ne spécifiez aucune version et qu'une version du package est déjà installée, Elastic Beanstalk n'installe pas une nouvelle version, car il part du principe que vous souhaitez conserver et utiliser la version existante. ### Exemple d'extrait L'extrait suivant spécifie une URL de la version pour rpm, demande la dernière version à yum et la version 0.10.2 de chef à rubygems. ``` packages: yum: libmemcached: [] ruby-devel: [] gcc: [] rpm: epel: http://download.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpm rubygems: chef: '0.10.2' ``` ## Groupes Vous pouvez utiliser la `groups` touche pour créer des Linux/UNIX groupes et pour attribuer des groupes IDs. Pour créer un groupe, ajoutez une nouvelle paire clé-valeur qui mappe un nouveau nom de groupe à un ID de groupe facultatif. La clé des groupes peut contenir un ou plusieurs noms de groupe. Le tableau suivant répertorie les clés disponibles. ### Syntaxe ``` groups: name of group: {} name of group: gid: "group id" ``` ### Options `gid` Numéro d'identification d'un groupe. Si un ID de groupe est spécifié et que le nom du groupe existe déjà, la création du groupe échoue. Si un autre groupe est associé à l'ID de groupe spécifié, le système d'exploitation peut refuser la création du groupe. ### Exemple d'extrait L'extrait suivant spécifie un groupe nommé groupOne sans attribuer d'ID de groupe, et un groupe nommé groupTwo ayant spécifié 45 comme valeur d'ID de groupe. ``` groups: groupOne: {} groupTwo: gid: "45" ``` ## Utilisateurs Vous pouvez utiliser la `users` clé pour créer des Linux/UNIX utilisateurs sur l' EC2 instance. ### Syntaxe ``` users: name of user: groups: - name of group uid: "id of the user" homeDir: "user's home directory" ``` ### Options `uid` ID d'un utilisateur. Le processus de création échoue si le nom d'utilisateur existe avec un autre ID d'utilisateur. Si l'ID d'utilisateur est déjà affecté à un utilisateur existant, le système d'exploitation peut refuser la demande de création. `groups` Liste de noms de groupes. L'utilisateur est ajouté à chaque groupe de la liste. `homeDir` Répertoire de base de l'utilisateur. Les utilisateurs sont créés en tant qu'utilisateurs du système non interactif avec le shell `/sbin/nologin`. Ce paramètre est intégré à la conception et ne peut pas être modifié. ### Exemple d'extrait ``` users: myuser: groups: - group1 - group2 uid: "50" homeDir: "/tmp" ``` ## Sources Vous pouvez utiliser la `sources` clé pour télécharger un fichier d'archive à partir d'une URL publique et le décompresser dans un répertoire cible de l' EC2 instance. ### Syntaxe ``` sources: target directory: location of archive file ``` ### Formats pris en charge Les formats pris en charge sont les suivants : tar, tar\$1gzip, tar\$1bz2 et zip. Vous pouvez faire référence à des emplacements externes tels qu'Amazon Simple Storage Service (Amazon S3) (par exemple, `https://amzn-s3-demo-bucket.s3.amazonaws.com/myobject`) tant que l'URL est publiquement accessible. ### Exemple d'extrait L'exemple suivant télécharge un fichier .zip public à partir d'un compartiment Amazon S3 et le décompresse dans `/etc/myapp`: ``` sources: /etc/myapp: https://amzn-s3-demo-bucket.s3.amazonaws.com/myobject ``` **Note** Plusieurs extractions ne doivent pas réutiliser le même chemin cible. L'extraction d'une autre source vers le même chemin cible remplacera le contenu au lieu de l'ajouter. ## Fichiers Vous pouvez utiliser la `files` clé pour créer des fichiers sur l' EC2 instance. Le contenu peut être soit en ligne dans le fichier de configuration, ou bien le contenu peut être extrait d'une URL. Les fichiers sont écrits sur disque par ordre lexicographique. Vous pouvez utiliser la clé `files` pour télécharger des fichiers privés depuis Amazon S3 en fournissant un profil d'instance pour l'autorisation. Si le chemin d'accès au fichier que vous spécifiez existe déjà sur l'instance, le fichier existant est conservé avec l'extension `.bak` ajoutée à son nom. ### Syntaxe ``` files: "target file location on disk": mode: "six-digit octal value" owner: name of owning user for file group: name of owning group for file source: URL authentication: authentication name: "target file location on disk": mode: "six-digit octal value" owner: name of owning user for file group: name of owning group for file content: | # this is my # file content encoding: encoding format authentication: authentication name: ``` ### Options `content` Contenu de la chaîne à ajouter dans le fichier. Spécifiez `content` ou `source`, mais pas les deux. `source` URL du fichier à télécharger. Spécifiez `content` ou `source`, mais pas les deux. `encoding` Format d'encodage de la chaîne spécifiée via l'option `content`. Valeurs valides : `plain` \$1 `base64` `group` Groupe Linux auquel appartient le fichier. `owner` Utilisateur Linux auquel appartient le fichier. `mode` Valeur octale à six chiffres qui représente le mode de ce fichier. Non pris en charge pour les systèmes Windows. Utilisez les trois premiers chiffres pour les liens symboliques et les trois derniers chiffres pour définir les autorisations. Pour créer un lien symbolique, spécifiez `120xxx`, où `xxx` définit les autorisations du fichier cible. Pour définir des autorisations pour un fichier, utilisez les trois derniers chiffres, tels que `000644`. `authentication` Le nom d'une [méthode d'authentification CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-authentication.html) à utiliser. Vous pouvez ajouter des méthodes d'authentification aux métadonnées du groupe Auto Scaling via la clé Resources. Vous trouverez un exemple ci-dessous. ### Exemple d'extrait ``` files: "/home/ec2-user/myfile" : mode: "000755" owner: root group: root source: http://foo.bar/myfile "/home/ec2-user/myfile2" : mode: "000755" owner: root group: root content: | this is my file content ``` Exemple d'utilisation d'un lien symbolique. Cela crée un lien `/tmp/myfile2.txt` qui renvoie vers le fichier existant `/tmp/myfile1.txt`. ``` files: "/tmp/myfile2.txt" : mode: "120400" content: "/tmp/myfile1.txt" ``` L'exemple suivant utilise la clé Resources pour ajouter une méthode d'authentification nommée S3Auth et l'utilise pour télécharger un fichier privé à partir d'un compartiment Amazon S3 : ``` Resources: AWSEBAutoScalingGroup: Metadata: AWS::CloudFormation::Authentication: S3Auth: type: "s3" buckets: ["amzn-s3-demo-bucket2"] roleName: "Fn::GetOptionSetting": Namespace: "aws:autoscaling:launchconfiguration" OptionName: "IamInstanceProfile" DefaultValue: "aws-elasticbeanstalk-ec2-role" files: "/tmp/data.json" : mode: "000755" owner: root group: root authentication: "S3Auth" source: https://elasticbeanstalk-us-west-2-123456789012.s3-us-west-2.amazonaws.com/data.json ``` ## Commandes Vous pouvez utiliser la `commands` touche pour exécuter des commandes sur l' EC2 instance. Les commandes exécutées avant l'application et le serveur web sont définies et le fichier de version de l'application est extrait. Les commandes spécifiées s'exécutent en tant qu'utilisateur racine et sont traitées dans l'ordre alphabétique par nom. Commandes exécutées dans le répertoire racine (par défaut). Pour exécuter des commandes à partir d'un autre répertoire, utilisez l'option `cwd`. Pour résoudre les problèmes associés à vos commandes, vous pouvez trouver leur sortie dans les [journaux d'instance](using-features.logging.md). ### Syntaxe ``` commands: command name: command: command to run cwd: working directory env: variable name: variable value test: conditions for command ignoreErrors: true ``` ### Options `command` Tableau ([collection de séquence de blocs](http://yaml.org/spec/1.2/spec.html#id2759963) en syntaxe YAML) ou chaîne spécifiant la commande à exécuter. Remarques importantes : + Si vous utilisez une chaîne, vous n'avez pas besoin de placer la totalité de la chaîne entre guillemets. Si vous utilisez des guillemets, utilisez des caractères d'échappement pour les occurrences littérales du même type de guillemets. + Si vous utilisez un tableau, vous n'avez pas besoin de caractères d'espacement ou d'inclure des paramètres de commande entre guillemets. Chaque élément de tableau est un argument de commande unique. N'utilisez pas un tableau pour spécifier plusieurs commandes. Les exemples suivants sont tous équivalents : ``` commands: command1: command: git commit -m "This is a comment." command2: command: "git commit -m \"This is a comment.\"" command3: command: 'git commit -m "This is a comment."' command4: command: - git - commit - -m - This is a comment. ``` Pour spécifier plusieurs commandes, utilisez un [bloc littéral scalaire](http://yaml.org/spec/1.2/spec.html#id2760844), comme illustré dans l'exemple suivant. ``` commands: command block: command: | git commit -m "This is a comment." git push ``` `env` (Facultatif) Définit des variables d'environnement pour la commande. Cette propriété remplace, plutôt que d'ajouter, l'environnement existant. `cwd` (Facultatif) Le répertoire de travail. Si cette option n'est pas spécifiée, les commandes sont exécutées à partir du répertoire racine (/). `test` (Facultatif) Commande qui doit renvoyer la valeur `true` (code de sortie 0) afin qu'Elastic Beanstalk traite la commande (par exemple, un script shell) contenue dans la clé `command`. `ignoreErrors` (Facultatif) Valeur booléenne qui détermine si les autres commandes doivent s'exécuter si la commande contenue dans la clé `command` échoue (renvoie une valeur non nulle). Définissez cette valeur sur `true` si vous voulez continuer à exécuter des commandes même si la commande échoue. Définissez-la sur `false` si vous souhaitez arrêter l'exécution des commandes si la commande échoue. La valeur par défaut est `false`. ### Exemple d'extrait L'exemple d'extrait suivant exécute un script Python. ``` commands: python_install: command: myscript.py cwd: /home/ec2-user env: myvarname: myvarvalue test: "[ -x /usr/bin/python ]" ``` ## Services Vous pouvez utiliser la clé `services` pour définir les services qui doivent être démarrés ou arrêtés lors du lancement de l'instance. La clé `services` vous permet également de spécifier des dépendances sur des sources, des packages et des fichiers de sorte que si un redémarrage est nécessaire en raison d'une installation de fichiers, Elastic Beanstalk prenne en charge le redémarrage du service. ### Syntaxe ``` services: sysvinit: name of service: enabled: "true" ensureRunning: "true" files: - "file name" sources: - "directory" packages: name of package manager: "package name[: version]" commands: - "name of command" ``` ### Options `ensureRunning` Définissez cette option sur `true` afin de garantir que le service s'exécute après qu'Elastic Beanstalk a terminé. Définissez cette option sur `false` afin de garantir que le service ne s'exécute pas après qu'Elastic Beanstalk a terminé. Ignorez cette clé pour n'apporter aucune modification à l'état du service. `enabled` Définissez cette option sur `true` afin de garantir que le service soit démarré automatiquement lors du démarrage. Définissez cette option sur `false` afin de garantir que le service ne soit pas démarré automatiquement lors du démarrage. Ignorez cette clé pour n'apporter aucune modification à cette propriété. `files` Liste de fichiers. Si Elastic Beanstalk en change un directement via le bloc de fichiers, le service est redémarré. `sources` Liste de répertoires. Si Elastic Beanstalk développe une archive dans l'un de ces répertoires, le service est redémarré. `packages` Une carte du gestionnaire de package sur une liste de noms de package. Si Elastic Beanstalk installe ou met à jour l'un de ces packages, le service est redémarré. `commands` Liste de noms de commandes. Si Elastic Beanstalk exécute la commande spécifiée, le service est redémarré. ### Exemple d'extrait Voici un exemple d'extrait : ``` services: sysvinit: myservice: enabled: true ensureRunning: true ``` ## Commandes de conteneur Vous pouvez utiliser la clé `container_commands` pour exécuter des commandes qui affectent le code source de votre application. Les commandes de conteneur s'exécutent après que l'application et le serveur web ont été configurés et que l'archive de version d'application a été extraite, mais avant que la version d'application soit déployée. Les commandes non-conteneur et autres opérations de personnalisation sont effectuées avant le code source d'application en cours d'extraction. Les commandes spécifiées s'exécutent en tant qu'utilisateur racine et sont traitées dans l'ordre alphabétique par nom. Les commandes de conteneur sont exécutées depuis le répertoire intermédiaire, où votre code source est extrait avant d'être déployé sur le serveur d'applications. Toutes les modifications apportées à votre code source dans le répertoire intermédiaire avec une commande conteneur seront incluses lorsque la source est déployée sur son emplacement final. **Note** La sortie de vos commandes de conteneur est enregistrée dans le journal d’instance `cfn-init-cmd.log`. Pour plus d'informations sur la récupération et l'affichage des journaux d'instance, [consultez Afficher les journaux des EC2 instances Amazon](using-features.logging.md). Vous pouvez utiliser `leader_only` pour exécuter uniquement la commande sur une seule instance, ou configurer un `test` pour exécuter uniquement la commande lorsqu'une commande test évalue sur `true`. Les commandes de conteneur principales uniquement sont exécutées uniquement au cours de la création et du déploiement de l'environnement, tandis que d'autres commandes et opérations de personnalisation de serveur sont effectuées chaque fois qu'une instance est mise en service ou mise à jour. Les commandes de conteneur principales uniquement ne sont pas exécutées pour lancer des modifications de configuration, par exemple, une modification d'ID d'AMI ou de type d'instance. ### Syntaxe ``` container_commands: name of container_command: command: "command to run" leader_only: true name of container_command: command: "command to run" ``` ### Options `command` Une chaîne ou un tableau de chaînes à exécuter. `env` (Facultatif) Définissez les variables d'environnement avant d'exécuter la commande, en ignorant toute valeur existante. `cwd` (Facultatif) Le répertoire de travail. Par défaut, il s'agit du répertoire intermédiaire de l'application décompressée. `leader_only` (Facultatif) Exécutez uniquement la commande sur une seule instance choisie par Elastic Beanstalk. Les commandes de conteneur principales uniquement sont exécutées avant d'autres commandes de conteneur. Une commande peut être principale uniquement ou disposer d'un `test`, mais pas les deux (`leader_only` a la priorité). `test` (Facultatif) Exécutez une commande test qui doit renvoyer la valeur `true` afin d'exécuter la commande de conteneur. Une commande peut être principale uniquement ou disposer d'un `test`, mais pas les deux (`leader_only` a la priorité). `ignoreErrors` (Facultatif) Ne manquez pas les déploiements si la commande de conteneur renvoie une valeur différente de 0 (réussite). Définissez sur `true` pour activer. ### Exemple d'extrait Voici un exemple d'extrait : ``` container_commands: collectstatic: command: "django-admin.py collectstatic --noinput" 01syncdb: command: "django-admin.py syncdb --noinput" leader_only: true 02migrate: command: "django-admin.py migrate" leader_only: true 99customize: command: "scripts/customize.sh" ``` # Exemple : utilisation de CloudWatch métriques Amazon personnalisées Cette rubrique fournit un exemple de configuration qui intègre les métriques d'Elastic Beanstalk à l'agent Amazon pour CloudWatch les plateformes basées sur Amazon Linux 2 et versions ultérieures. L'exemple de configuration utilise des fichiers et des commandes dans un fichier `.ebextensions` de configuration. Amazon CloudWatch est un service Web qui vous permet de surveiller, de gérer et de publier diverses métriques, ainsi que de configurer des actions d'alarme en fonction des données issues des métriques. Vous pouvez définir des métriques personnalisées pour votre propre usage, et Elastic Beanstalk transmettra ces métriques à Amazon. CloudWatch Une fois qu'Amazon CloudWatch contient vos statistiques personnalisées, vous pouvez les consulter dans la CloudWatch console Amazon. **L' CloudWatch agent Amazon** L' CloudWatch agent Amazon permet la collecte de CloudWatch métriques et de journaux à la fois depuis les EC2 instances Amazon et les serveurs sur site sur tous les systèmes d'exploitation. L'agent prend en charge les métriques collectées au niveau du système. Il prend également en charge la collecte personnalisée de journaux et de métriques à partir de vos applications ou services. Pour plus d'informations sur l' CloudWatch agent Amazon, consultez la section [Collecte de métriques et de journaux avec l' CloudWatch agent](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html) dans le *guide de CloudWatch l'utilisateur Amazon*. **Note** Elastic [Beanstalk Enhanced](health-enhanced.md) Health Reporting prend en charge de manière native la publication d'un large éventail de métriques relatives aux instances et à l'environnement sur. CloudWatch Consultez [Publication de métriques CloudWatch personnalisées Amazon pour un environnement](health-enhanced-cloudwatch.md) pour plus de détails. **Topics** + [Fichier de configuration .Ebextensions](#customize-containers-cw-update-roles) + [Permissions](#customize-containers-cw-policy) + [Afficher les métriques dans la CloudWatch console](#customize-containers-cw-console) ## Fichier de configuration .Ebextensions Cet exemple utilise les fichiers et les commandes d'un fichier de configuration .ebextensions pour configurer et exécuter l' CloudWatch agent Amazon sur la plateforme Amazon Linux 2. L'agent est préemballé avec Amazon Linux 2. Si vous utilisez un autre système d'exploitation, des étapes supplémentaires pour installer l'agent peuvent être nécessaires. Pour plus d'informations, consultez la section [Installation de l' CloudWatch agent](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/install-CloudWatch-Agent-on-EC2-Instance.html) dans le *guide de CloudWatch l'utilisateur Amazon*. Pour utiliser cet exemple, enregistrez-le dans un fichier nommé `cloudwatch.config`, dans un répertoire nommé `.ebextensions` au niveau supérieur de votre répertoire de projet. Déployez ensuite votre application via la console Elastic Beanstalk (en incluant le répertoire .ebextensions dans votre [bundle de fichiers source](applications-sourcebundle.md)) ou via l'[interface de ligne de commande EB](eb-cli3.md). Pour plus d'informations sur les fichiers de configuration, consultez [Personnalisation d'environnement avancée avec fichiers de configuration (`.ebextensions`)](ebextensions.md). Ce fichier contient deux sections : + `files` — Cette section ajoute le fichier de configuration d'agent. Il indique les métriques et les journaux que l'agent doit envoyer à Amazon CloudWatch. Dans cet exemple, nous envoyons uniquement la métrique *mem\$1used\$1percent*. Pour une liste complète des métriques au niveau du système prises en charge par l' CloudWatch agent Amazon, consultez la section [Mesures collectées par l' CloudWatch agent](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/metrics-collected-by-CloudWatch-agent.html) dans le *guide de CloudWatch l'utilisateur Amazon*. + `container_commands` — Cette section contient la commande qui démarre l'agent, en transmettant le fichier de configuration en tant que paramètre. Pour en savoir plus sur `container_commands`, consultez [Commandes de conteneur](customize-containers-ec2.md#linux-container-commands). **.ebextensions/cloudwatch.config** ``` files: "/opt/aws/amazon-cloudwatch-agent/bin/config.json": mode: "000600" owner: root group: root content: | { "agent": { "metrics_collection_interval": 60, "run_as_user": "root" }, "metrics": { "namespace": "System/Linux", "append_dimensions": { "AutoScalingGroupName": "${aws:AutoScalingGroupName}" }, "metrics_collected": { "mem": { "measurement": [ "mem_used_percent" ] } } } } container_commands: start_cloudwatch_agent: command: /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a append-config -m ec2 -s -c file:/opt/aws/amazon-cloudwatch-agent/bin/config.json ``` ## Permissions Les instances de votre environnement ont besoin des autorisations IAM appropriées pour publier des CloudWatch métriques Amazon personnalisées à l'aide de l' CloudWatch agent Amazon. Vous accordez des autorisations aux instances de votre environnement en les ajoutant au [profil d'instance](concepts-roles-instance.md) de l'environnement. Vous pouvez ajouter des autorisations au profil d'instance avant ou après le déploiement de votre application. **Pour accorder l'autorisation de publier CloudWatch des métriques** 1. Ouvrez la console IAM à l’adresse [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. Dans le panneau de navigation, choisissez **Rôles**. 1. Sélectionnez le rôle de profil d'instance de votre environnement. Par défaut, lorsque vous créez un environnement via la console Elastic Beanstalk ou l'[interface de ligne de commande EB](eb-cli3.md), il s'agit de `aws-elasticbeanstalk-ec2-role`. 1. Sélectionnez l’onglet **Autorisations**. 1. Sous **Politiques d'autorisations**, dans la section **Autorisations**, choisissez **Attacher des politiques**. 1. Sous **Autorisations d'attachement**, choisissez la politique AWS gérée **CloudWatchAgentServerPolicy**. Cliquez ensuite sur **Attacher une politique**. Pour plus d'informations sur la gestion des politiques, consultez [Utilisation des politiques](https://docs.aws.amazon.com/IAM/latest/UserGuide/ManagingPolicies.html) dans le *Guide de l'utilisateur IAM*. ## Afficher les métriques dans la CloudWatch console Après avoir déployé le fichier de CloudWatch configuration dans votre environnement, consultez la [ CloudWatchconsole Amazon](https://console.aws.amazon.com/cloudwatch/home) pour consulter vos statistiques. Les métriques personnalisées seront situées dans l'espace de **CWAgent**noms. Pour plus d'informations, consultez la section [Affichage des statistiques disponibles](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/viewing_metrics_with_cloudwatch.html) dans le *guide de CloudWatch l'utilisateur Amazon*.