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.
# Installation de l' CloudWatch agent
Vous pouvez installer l' CloudWatch agent sur vos instances Amazon EC2, sur vos serveurs locaux et dans des environnements conteneurisés pour collecter des métriques, des journaux et des traces. L'agent prend en charge les systèmes d'exploitation Linux, Windows et macOS. Il existe plusieurs méthodes pour installer l'agent, notamment à l'aide de Systems Manager, depuis la CloudWatch console, depuis la ligne de commande ou à l'aide d'un fichier de configuration. Avant de procéder à l’installation, assurez-vous que les autorisations IAM et l’accès réseau requis sont correctement configurés.
**Topics**
+ [
# Installation et configuration d'Amazon CloudWatch Agent avec détection de charge de travail dans la CloudWatch console
](install-cloudwatch-agent-workload-detection.md)
+ [
# Installation manuelle sur Amazon EC2
](manual-installation.md)
+ [
# Installez l' CloudWatch agent à l'aide de AWS Systems Manager
](installing-cloudwatch-agent-ssm.md)
+ [
# Installation de l' CloudWatch agent sur les serveurs locaux
](install-CloudWatch-Agent-on-premise.md)
+ [
# Installez l' CloudWatch agent sur les nouvelles instances à l'aide de CloudFormation
](Install-CloudWatch-Agent-New-Instances-CloudFormation.md)
+ [
# Installez l' CloudWatch agent avec le module complémentaire Amazon CloudWatch Observability EKS ou le graphique Helm
](install-CloudWatch-Observability-EKS-addon.md)
# Installation et configuration d'Amazon CloudWatch Agent avec détection de charge de travail dans la CloudWatch console
## Introduction
Vous pouvez utiliser la console CloudWatch Getting Started pour installer et configurer l' CloudWatch agent sur les instances Amazon EC2. L' CloudWatch agent Amazon est un composant logiciel léger qui collecte des métriques, des journaux et des traces au niveau du système à partir de vos instances Amazon EC2. En automatisant la collecte et la transmission des données de surveillance CloudWatch, l'agent vous permet d'obtenir des informations exploitables, d'optimiser l'utilisation des ressources et de garantir le bon fonctionnement de vos applications avec un minimum d'efforts de configuration.
Configurez l' CloudWatch agent avec des configurations prédéfinies spécifiques à la charge de travail qui tirent parti de la détection automatique de la charge de travail pour identifier les applications et les services en cours d'exécution sur vos instances. Vous pouvez personnaliser la collecte de données à l'aide de métriques, de journaux et de traces spécifiques, ce qui vous permet de surveiller les performances des applications et de résoudre les problèmes de manière efficace.
## Fonctionnement
L' CloudWatch agent détecte les charges de travail exécutées sur vos instances Amazon EC2 grâce à des fonctionnalités de détection automatique des charges de travail. Cette fonctionnalité identifie les applications et les services en cours d'exécution sur vos instances, permettant ainsi une surveillance intelligente sans configuration manuelle.
Les solutions d'observabilité fournissent des configurations prédéfinies spécifiques à la charge de travail adaptées aux applications courantes telles qu'Apache Kafka, Apache Tomcat, les machines virtuelles Java (JVM), NGINX et les charges de travail GPU NVIDIA. Ces solutions rationalisent la configuration de la surveillance en collectant automatiquement les indicateurs, journaux et traces appropriés spécifiques à chaque charge de travail détectée, éliminant ainsi le besoin d'instrumentation et de configuration manuelles.
Lorsque la détection de la charge de travail est activée, l'agent analyse l'environnement de votre instance et sélectionne automatiquement les modèles de surveillance préconfigurés pertinents. Ces configurations sont optimisées par des experts AWS en la matière pour capturer les données de télémétrie les plus importantes pour chaque type de charge de travail, vous garantissant ainsi une observabilité complète dès le départ.
## Conditions préalables
### Installation de l'agent SSM (obligatoire)
L'agent AWS Systems Manager (SSM) doit être installé sur vos instances Amazon EC2. L'agent SSM est préinstallé sur la plupart des Amazon Machine Images AMIs () AWS fournies. Si vous devez installer ou mettre à jour manuellement l'agent SSM, reportez-vous à la documentation de Systems [Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html).
**Note**
La configuration DHMC (Default Host Management Configuration) est une fonctionnalité de Systems Manager qui accorde automatiquement aux instances Amazon EC2 l'autorisation de se connecter à Systems Manager sans que vous ayez à associer manuellement un profil d'instance IAM à chaque instance. Si vos instances Amazon EC2 utilisent DHMC et que le processus d'installation de l' CloudWatch agent attache la CloudWatch politique à vos instances, l'entrée en vigueur de la nouvelle politique peut prendre jusqu'à 30 minutes. Ce délai peut retarder la publication des métriques, des journaux et des traces de CloudWatch. [Pour pallier ce problème, vous pouvez créer vos instances Amazon EC2 avec un rôle IAM contenant la politique Amazon. SSMManaged InstanceCore](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSSMManagedInstanceCore.html)
### Détection de la charge de travail (recommandée)
La détection de la charge de travail est une fonctionnalité optionnelle qui identifie automatiquement les applications et les services en cours d'exécution sur vos instances. Nous vous recommandons d'activer la détection de la charge de travail pour tirer parti des modèles de surveillance préconfigurés spécifiques à la charge de travail. Vous pouvez activer la détection de la charge de travail dans les [paramètres de la CloudWatch console](https://console.aws.amazon.com/cloudwatch/home#settings).
## Prise en main
Ouvrez la page Getting Started with Amazon CloudWatch agent dans la CloudWatch console Amazon : [https://console.aws.amazon.com/cloudwatch/home \$1cloudwatch -agent](https://console.aws.amazon.com/cloudwatch/home#cloudwatch-agent)
**Déploiement manuel d'instance pour CloudWatch l'agent**
Sélectionnez manuellement jusqu'à 50 instances pour l'installation et la configuration de l' CloudWatch agent. Cette approche ciblée vous permet d'améliorer la surveillance d'instances Amazon EC2 spécifiques.
**Déploiement basé sur des balises pour l'agent CloudWatch **
Utilisez le déploiement basé sur des balises pour installer et configurer l' CloudWatch agent sur des flottes d'instances Amazon EC2. Cette méthode s'applique à toutes les instances actuelles et futures avec des balises correspondantes.
**Configuration basée sur des balises**
Les configurations basées sur des balises vous permettent d'organiser, de visualiser et de modifier efficacement les configurations, ce qui vous aide à gérer CloudWatch l'agent et sa configuration dans les flottes d'instances Amazon EC2.
**CloudWatch installation de l'agent**
Installez l' CloudWatch agent pour collecter des métriques, des journaux et des traces à partir d'instances Amazon EC2 et d'hôtes sur site. Cette télémétrie fournit des données importantes sur l'état et les performances de votre infrastructure et de vos applications.
**CloudWatch configuration de l'agent**
Configurez l' CloudWatch agent avec des configurations prédéfinies spécifiques à la charge de travail. Vous pouvez personnaliser la collecte de données à l'aide de métriques, de journaux et de traces spécifiques, ce qui vous permet de surveiller les performances des applications et de résoudre les problèmes de manière efficace.
## Coûts
Les métriques supplémentaires que vous ajoutez au cours de ce processus sont facturées en tant que métriques personnalisées. Pour plus d'informations sur la tarification des CloudWatch métriques, consultez [Amazon CloudWatch Pricing](https://aws.amazon.com/cloudwatch/pricing).
# Installation manuelle sur Amazon EC2
**Note**
Assurez-vous que les conditions préalables sont remplies avant d'installer l' CloudWatch agent pour la première fois.
**Topics**
+ [
## Installation sur Amazon Linux à l’aide du gestionnaire de packages
](#amazon-linux-package)
+ [
## Installation sur Amazon Linux via la ligne de commande
](#linux-manual-install)
+ [
## Installation sur Windows
](#windows-installation)
+ [
## Installation sur macOS
](#macos-installation)
## Installation sur Amazon Linux à l’aide du gestionnaire de packages
L' CloudWatch agent est disponible sous forme de package dans Amazon Linux 2023 et Amazon Linux 2. Si vous utilisez l’un de ces systèmes d’exploitation, vous pouvez installer le package en entrant la commande suivante :
```
sudo yum install amazon-cloudwatch-agent
```
Vous devez également vous assurer que le rôle IAM attaché à l'instance possède le rôle **CloudWatchAgentServerPolicy**attaché.
## Installation sur Amazon Linux via la ligne de commande
Sur tous les systèmes d'exploitation Linux pris en charge, vous pouvez télécharger et installer l' CloudWatch agent à l'aide de la ligne de commande.
1. Téléchargez l' CloudWatch agent. Pour un serveur Linux, saisissez la commande suivante. Pour `download-link`, utilisez le lien de téléchargement approprié dans le tableau ci-dessous.
```
wget download-link
```
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/manual-installation.html)
1. Une fois que vous avez téléchargé le package, vous pouvez, si vous le souhaitez, vérifier la signature du package. Pour de plus amples informations, consultez [Vérification de la signature du package de l' CloudWatch agent](verify-CloudWatch-Agent-Package-Signature.md).
1. Installez le package . Si vous avez téléchargé un package RPM sur un serveur Linux, accédez au répertoire contenant le package et saisissez ce qui suit :
```
sudo rpm -U ./amazon-cloudwatch-agent.rpm
```
Si vous avez téléchargé un package DEB sur un serveur Linux, accédez au répertoire contenant le package et saisissez ce qui suit :
```
sudo dpkg -i -E ./amazon-cloudwatch-agent.deb
```
## Installation sur Windows
Sur Windows Server, vous pouvez télécharger et installer l' CloudWatch agent à l'aide de la ligne de commande.
1. Téléchargez le fichier suivant :
```
https://amazoncloudwatch-agent.s3.amazonaws.com/windows/amd64/latest/amazon-cloudwatch-agent.msi
```
1. Une fois que vous avez téléchargé le package, vous pouvez, si vous le souhaitez, vérifier la signature du package. Pour de plus amples informations, consultez [Vérification de la signature du package de l' CloudWatch agent](verify-CloudWatch-Agent-Package-Signature.md).
1. Installez le package . Accédez au répertoire contenant le package et saisissez la commande suivante :
```
msiexec /i amazon-cloudwatch-agent.msi
```
Cette commande fonctionne également de l'intérieur PowerShell. Pour plus d'informations sur les options de ligne de commande MSI, consultez [Command-Line Options (Options de ligne de commande)](https://docs.microsoft.com/en-us/windows/desktop/Msi/command-line-options) dans la documentation Microsoft Windows.
## Installation sur macOS
Sur les ordinateurs macOS, vous pouvez télécharger et installer l' CloudWatch agent à l'aide de la ligne de commande.
1. Téléchargez le package adapté à votre architecture :
```
https://amazoncloudwatch-agent.s3.amazonaws.com/darwin/amd64/latest/amazon-cloudwatch-agent.pkg
```
Pour ARM64 l'architecture :
```
https://amazoncloudwatch-agent.s3.amazonaws.com/darwin/arm64/latest/amazon-cloudwatch-agent.pkg
```
1. Une fois que vous avez téléchargé le package, vous pouvez, si vous le souhaitez, vérifier la signature du package. Pour de plus amples informations, consultez [Vérification de la signature du package de l' CloudWatch agent](verify-CloudWatch-Agent-Package-Signature.md).
1. Installez le package . Accédez au répertoire contenant le package et saisissez la commande suivante :
```
sudo installer -pkg ./amazon-cloudwatch-agent.pkg -target /
```
# Installez l' CloudWatch agent à l'aide de AWS Systems Manager
L'utilisation AWS Systems Manager facilite l'installation de l' CloudWatch agent sur un parc d'instances Amazon EC2. Vous pouvez télécharger l'agent sur un serveur et créer votre fichier de configuration d' CloudWatch agent pour tous les serveurs du parc. Vous pouvez ensuite utiliser Systems Manager pour installer l’agent sur les autres serveurs à l’aide du fichier de configuration que vous avez créé. Utilisez les rubriques suivantes pour installer et exécuter l' CloudWatch agent à l'aide de AWS Systems Manager.
**Topics**
+ [
## Installation ou mise à jour de l’agent SSM
](#update-SSM-Agent-EC2instance-first)
+ [
## Vérification des prérequis de Systems Manager
](#install-CloudWatch-Agent-minimum-requirements-first)
+ [
## Vérification de l'accès Internet
](#install-CloudWatch-Agent-internet-access-first)
+ [
## Téléchargez le package de CloudWatch l'agent sur votre première instance
](#install-CloudWatch-Agent-EC2-first)
+ [
## Créer et modifier le fichier de configuration d'agent
](#CW-Agent-Instance-Create-Configuration-File-first)
+ [
## Installez et démarrez l' CloudWatch agent sur des instances EC2 supplémentaires à l'aide de la configuration de votre agent
](#install-CloudWatch-Agent-on-EC2-Instance-fleet)
+ [
## Installez l' CloudWatch agent sur des instances EC2 supplémentaires à l'aide de la configuration de votre agent
](#install-CloudWatch-Agent-on-EC2-Instance-fleet)
+ [
## (Facultatif) Modifiez la configuration commune et le profil nommé de CloudWatch l'agent
](#CloudWatch-Agent-profile-instance-fleet)
## Installation ou mise à jour de l’agent SSM
Sur une instance Amazon EC2, l' CloudWatch agent doit exécuter la version 2.2.93.0 ou ultérieure de l'agent SSM. Avant d'installer l' CloudWatch agent, mettez à jour ou installez l'agent SSM sur l'instance si ce n'est pas déjà fait.
Pour plus d'informations sur l'installation ou la mise à jour de l'agent SSM sur une instance exécutant Linux, consultez [Installation et configuration de l'agent SSM Agent sur les instances Linux](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html) dans le *Guide de l'utilisateur AWS Systems Manager *.
Pour plus d'informations sur l'installation ou la mise à jour de l'agent, consultez [Utilisation de l'agent SSM Agent](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html) dans le *Guide de l'utilisateur AWS Systems Manager *.
## Vérification des prérequis de Systems Manager
Avant d'utiliser Systems Manager Run Command pour installer et configurer l' CloudWatch agent, vérifiez que vos instances répondent aux exigences minimales de Systems Manager. Pour plus d'informations, consultez [Systems Manager Prerequisites (Prérequis de Systems Manager)](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up.html#systems-manager-prereqs) dans le *Guide de l'utilisateur AWS Systems Manager *.
## Vérification de l'accès Internet
Vos instances Amazon EC2 doivent être en mesure de se connecter aux CloudWatch points de terminaison. Cela peut se faire par le biais d'Internet Gateway, d'une passerelle NAT ou de points de CloudWatch terminaison VPC d'interface. Pour plus d'informations sur la configuration de l'accès à Internet, consultez [Internet Gateways (Passerelles Internet)](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html) dans le *Guide de l'utilisateur Amazon VPC*.
Les points de terminaison et les ports à configurer sur votre proxy sont les suivants :
+ Si vous utilisez l'agent pour collecter des métriques, vous devez autoriser la liste des CloudWatch points de terminaison pour les régions appropriées. Ces points de terminaison sont répertoriés [sur Amazon CloudWatch](https://docs.aws.amazon.com/general/latest/gr/rande.html#cw_region) dans le *Référence générale d'Amazon Web Services*.
+ Si vous utilisez l'agent pour collecter des journaux, vous devez autoriser la liste des points de terminaison des CloudWatch journaux pour les régions appropriées. Ces points de terminaison sont répertoriés dans [Amazon CloudWatch Logs](https://docs.aws.amazon.com/general/latest/gr/rande.html#cwl_region) dans le *Référence générale d'Amazon Web Services*.
+ Si vous utilisez Systems Manager pour installer l'agent ou le Parameter Store pour stocker votre fichier de configuration, vous devez permettre d'énumérer les points de terminaison Systems Manager pour les régions appropriées. Ces points de terminaison sont répertoriés dans la rubrique [AWS Systems Manager](https://docs.aws.amazon.com/general/latest/gr/rande.html#ssm_region) du document *Référence générale d'Amazon Web Services*.
## Téléchargez le package de CloudWatch l'agent sur votre première instance
Procédez comme suit pour télécharger le package de l' CloudWatch agent à l'aide de Systems Manager.
**Pour télécharger l' CloudWatch agent à l'aide de Systems Manager**
1. Ouvrez la console Systems Manager à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Dans le panneau de navigation, choisissez **Run Command (Fonctionnalité Exécuter la commande)**.
-ou-
Si la page d' AWS Systems Manager accueil s'ouvre, faites défiler la page vers le bas et choisissez **Explore Run Command**.
1. Sélectionnez **Run Command (Exécuter la commande)**.
1. Dans la liste du **document de commande**, choisissez **AWSPackageAWS-Configure**.
1. Dans la zone **Cibles**, choisissez l'instance sur laquelle installer l'agent CloudWatch. Si vous ne voyez pas d'instance spécifique, c'est qu'elle n'est peut-être pas configurée en tant qu'instance gérée à utiliser avec Systems Manager. Pour plus d'informations, consultez la section [Configuration AWS Systems Manager pour les environnements hybrides](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-managedinstances.html) dans le *guide de AWS Systems Manager l'utilisateur*.
1. Dans la liste **Action**, choisissez **Install (Installer)**.
1. Dans le champ **Nom**, saisissez *AmazonCloudWatchAgent*.
1. Conservez la définition de **Version** sur **Dernière** pour installer la dernière version de l'agent.
1. Cliquez sur **Exécuter**.
1. Il est également possible, dans les zones **Targets and outputs (Cibles et sorties)** de sélectionner le bouton en regard d'un nom d'instance et de choisir **View output (Afficher les sorties)**. Systems Manager doit indiquer que l'agent a été correctement installé.
## Créer et modifier le fichier de configuration d'agent
Après avoir téléchargé l' CloudWatch agent, vous devez créer le fichier de configuration avant de démarrer l'agent sur n'importe quel serveur.
Si vous allez enregistrer votre fichier de configuration d'agent dans le Parameter Store du Systems Manager, vous devez utiliser une instance EC2 pour enregistrer le Parameter Store. En outre, vous devez d'abord attacher à cette instance le rôle IAM `CloudWatchAgentAdminRole`. Pour plus d’informations sur l’association de rôles, consultez [Association d’un rôle IAM à une instance](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/iam-roles-for-amazon-ec2.html#attach-iam-role) dans le *Guide de l’utilisateur Amazon EC2*.
Pour plus d'informations sur la création du fichier de configuration de l' CloudWatch agent, consultez[Création du fichier de configuration de CloudWatch l'agent](create-cloudwatch-agent-configuration-file.md).
## Installez et démarrez l' CloudWatch agent sur des instances EC2 supplémentaires à l'aide de la configuration de votre agent
Une fois la configuration de CloudWatch l'agent enregistrée dans Parameter Store, vous pouvez l'utiliser lorsque vous installez l'agent sur d'autres serveurs.
Pour chacun de ces serveurs, suivez les étapes répertoriées précédemment dans cette section pour vérifier les prérequis pour Systems Manager, la version de l’agent SSM et l’accès à Internet. Suivez ensuite les instructions suivantes pour installer l' CloudWatch agent sur les instances supplémentaires, à l'aide du fichier de configuration de l' CloudWatch agent que vous avez créé.
**Étape 1 : télécharger et installer l' CloudWatch agent**
Pour pouvoir envoyer les CloudWatch données vers une autre région, assurez-vous que le rôle IAM que vous avez attaché à cette instance est autorisé à écrire les CloudWatch données dans cette région.
Voici un exemple d'utilisation de la `aws configure` commande pour créer un profil nommé pour l' CloudWatch agent. Cet exemple suppose que vous utilisez le nom de profil par défaut de `AmazonCloudWatchAgent`.
**Pour créer le AmazonCloudWatchAgent profil de l' CloudWatch agent**
+ Sur les serveurs Linux, tapez la commande suivante, puis suivez les invites :
```
sudo aws configure --profile AmazonCloudWatchAgent
```
Sur Windows Server, ouvrez PowerShell en tant qu'administrateur, tapez la commande suivante et suivez les instructions.
```
aws configure --profile AmazonCloudWatchAgent
```
## Installez l' CloudWatch agent sur des instances EC2 supplémentaires à l'aide de la configuration de votre agent
Une fois la configuration de CloudWatch l'agent enregistrée dans Parameter Store, vous pouvez l'utiliser lorsque vous installez l'agent sur d'autres serveurs.
Pour chacun de ces serveurs, suivez les étapes répertoriées précédemment dans cette section pour vérifier les prérequis pour Systems Manager, la version de l’agent SSM et l’accès à Internet. Suivez ensuite les instructions suivantes pour installer l' CloudWatch agent sur les instances supplémentaires, à l'aide du fichier de configuration de l' CloudWatch agent que vous avez créé.
**Étape 1 : télécharger et installer l' CloudWatch agent**
Vous devez installer l'agent sur chaque serveur où vous allez exécuter l'agent. L' CloudWatch agent est disponible sous forme de package dans Amazon Linux 2023 et Amazon Linux 2. Si vous utilisez ce système d’exploitation, vous pouvez installer le package à l’aide de Systems Manager, en suivant les étapes ci-dessous.
**Note**
Vous devez également vous assurer que le rôle IAM attaché à l'instance possède le rôle **CloudWatchAgentServerPolicy**attaché. Pour plus d'informations, consultez[Conditions préalables](prerequisites.md).
**Pour installer le package de l' CloudWatch agent à l'aide de Systems Manager**
1. Ouvrez la console Systems Manager à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Dans le panneau de navigation, choisissez **Run Command (Fonctionnalité Exécuter la commande)**.
-ou-
Si la page d' AWS Systems Manager accueil s'ouvre, faites défiler la page vers le bas et choisissez **Explore Run Command**.
1. Sélectionnez **Run Command (Exécuter la commande)**.
1. Dans la liste des **documents de commande**, sélectionnez **AWS- RunShellScript**. Collez ensuite ce qui suit dans les **Paramètres de commande**.
```
sudo yum install amazon-cloudwatch-agent
```
1. Cliquez sur **Run** (Exécuter).
Sur tous les systèmes d'exploitation pris en charge, vous pouvez télécharger le package de l' CloudWatch agent à l'aide de la commande Systems Manager Run ou d'un lien de téléchargement Amazon S3.
**Note**
Lorsque vous installez ou mettez à jour l' CloudWatch agent, seule l'option de **désinstallation et de réinstallation** est prise en charge. Vous ne pouvez pas utiliser l'option **In-place update (Mises à jour sur place)**.
La fonctionnalité Exécuter la commande de Systems Manager vous permet de gérer la configuration de vos instances. Spécifiez un document Systems Manager, fournissez des paramètres et exécutez la commande sur une ou plusieurs instances. L'agent SSM Agent sur l'instance traite la commande et configure l'instance comme indiqué.
**Pour télécharger l' CloudWatch agent à l'aide de la commande Exécuter**
1. Ouvrez la console Systems Manager à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Dans le panneau de navigation, choisissez **Run Command (Fonctionnalité Exécuter la commande)**.
-ou-
Si la page d' AWS Systems Manager accueil s'ouvre, faites défiler la page vers le bas et choisissez **Explore Run Command**.
1. Sélectionnez **Run Command (Exécuter la commande)**.
1. Dans la liste du **document de commande**, choisissez **AWSPackageAWS-Configure**.
1. Dans la zone **Cibles**, choisissez l'instance sur laquelle vous souhaitez installer l' CloudWatch agent. Si vous ne voyez pas d'instance spécifique, c'est qu'elle n'est peut-être pas configurée pour la fonctionnalité Exécuter la commande. Pour plus d'informations, consultez la section [Configuration AWS Systems Manager pour les environnements hybrides](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-managedinstances.html) dans le *guide de AWS Systems Manager l'utilisateur*.
1. Dans la liste **Action**, choisissez **Install (Installer)**.
1. Dans la case **Nom**, saisissez *AmazonCloudWatchAgent*.
1. Conservez la définition de **Version** sur **Dernière** pour installer la dernière version de l'agent.
1. Cliquez sur **Exécuter**.
1. Il est également possible, dans les zones **Targets and outputs (Cibles et sorties)** de sélectionner le bouton en regard d'un nom d'instance et de choisir **View output (Afficher les sorties)**. Systems Manager doit indiquer que l'agent a été correctement installé.
**Étape 2 : démarrer l' CloudWatch agent à l'aide de votre fichier de configuration**
Procédez comme suit pour démarrer l'agent à l'aide de la commande Exécuter la commande Systems Manager.
Pour plus d'informations sur la configuration de l'agent sur un système sur lequel Linux (SELinux) amélioré en termes de sécurité est activé, consultez. [Configuration de l' CloudWatch agent avec Linux renforcé en termes de sécurité () SELinux](CloudWatch-Agent-SELinux.md)
**Pour démarrer l' CloudWatch agent à l'aide de la commande Exécuter**
1. Ouvrez la console Systems Manager à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Dans le panneau de navigation, choisissez **Run Command (Fonctionnalité Exécuter la commande)**.
-ou-
Si la page d' AWS Systems Manager accueil s'ouvre, faites défiler la page vers le bas et choisissez **Explore Run Command**.
1. Sélectionnez **Run Command (Exécuter la commande)**.
1. Dans la liste du **document de commande**, choisissez **AmazonCloudWatch- ManageAgent**.
1. Dans la zone **Cibles**, choisissez l'instance sur laquelle vous avez installé l' CloudWatch agent.
1. Dans la liste **Action**, choisissez **configure (configurer)**.
1. Dans la liste **Optional Configuration Source** (Source de configuration facultative), choisissez **ssm**.
1. Dans la zone **Emplacement de configuration facultative**, saisissez le nom du paramètre Systems Manager du fichier de configuration d'agent que vous avez créé et enregistré dans le Parameter Store du Systems Manager, tel que décrit dans [Création du fichier de configuration de CloudWatch l'agent](create-cloudwatch-agent-configuration-file.md).
1. Dans la liste **Optional Restart** (Redémarrage facultatif), choisissez **oui** pour démarrer l'agent une fois que vous avez terminé ces étapes.
1. Cliquez sur **Exécuter**.
1. Il est également possible, dans les zones **Targets and outputs (Cibles et sorties)** de sélectionner le bouton en regard d'un nom d'instance et de choisir **View output (Afficher les sorties)**. Systems Manager doit indiquer que l'agent a été correctement démarré.
## (Facultatif) Modifiez la configuration commune et le profil nommé de CloudWatch l'agent
L' CloudWatch agent inclut un fichier de configuration appelé`common-config.toml`. Le cas échéant, vous pouvez utiliser ce fichier pour spécifier le proxy et les informations de région.
Sur un serveur exécutant Linux, ce fichier se trouve dans le répertoire `/opt/aws/amazon-cloudwatch-agent/etc`. Sur un serveur exécutant Windows Server, ce fichier se trouve dans le répertoire `C:\ProgramData\Amazon\AmazonCloudWatchAgent`.
Le `common-config.toml` par défaut est comme suit :
```
# This common-config is used to configure items used for both ssm and cloudwatch access
## Configuration for shared credential.
## Default credential strategy will be used if it is absent here:
## Instance role is used for EC2 case by default.
## AmazonCloudWatchAgent profile is used for onPremise case by default.
# [credentials]
# shared_credential_profile = "{profile_name}"
# shared_credential_file= "{file_name}"
## Configuration for proxy.
## System-wide environment-variable will be read if it is absent here.
## i.e. HTTP_PROXY/http_proxy; HTTPS_PROXY/https_proxy; NO_PROXY/no_proxy
## Note: system-wide environment-variable is not accessible when using ssm run-command.
## Absent in both here and environment-variable means no proxy will be used.
# [proxy]
# http_proxy = "{http_url}"
# https_proxy = "{https_url}"
# no_proxy = "{domain}"
```
Toutes les lignes comportent initialement un commentaire. Pour définir le profil des informations d'identification ou les paramètres de proxy, retirez `#` de cette ligne et indiquez une valeur. Vous pouvez éditer ce fichier manuellement ou en utilisant la fonctionnalité Exécuter la commande `RunShellScript` dans Systems Manager :
+ `shared_credential_profile`— Pour les serveurs locaux, cette ligne indique le profil d'identification de l'utilisateur IAM à utiliser pour envoyer des données. CloudWatch Si vous conservez les commentaires de cette ligne, `AmazonCloudWatchAgent` est utilisé.
Sur une instance EC2, vous pouvez utiliser cette ligne pour que l' CloudWatch agent envoie des données depuis cette instance vers CloudWatch une autre AWS région. Pour ce faire, spécifiez un profil nommé qui inclut un champ `region` en spécifiant le nom de la région destinataire.
Si vous spécifiez une ligne `shared_credential_profile`, vous devez également supprimer le `#` au début de la ligne `[credentials]`.
+ `shared_credential_file` – Pour que l'agent cherche des informations d'identification dans un fichier situé sur un chemin autre que le chemin par défaut, spécifiez ici le chemin d'accès complet et le nom de fichier. Le chemin d'accès par défaut est `/root/.aws` sous Linux et `C:\\Users\\Administrator\\.aws` sous Windows Server.
Le premier exemple ci-après montre la syntaxe d'une ligne `shared_credential_file` valide pour les serveurs Linux et le deuxième exemple est valide pour Windows Server. Sous Windows Server, vous devez utiliser le caractère d'échappement \$1.
```
shared_credential_file= "/usr/username/credentials"
```
```
shared_credential_file= "C:\\Documents and Settings\\username\\.aws\\credentials"
```
Si vous spécifiez une ligne `shared_credential_file`, vous devez également supprimer le `#` au début de la ligne `[credentials]`.
+ Paramètres de proxy – Si vos serveurs utilisent des proxys HTTP ou HTTPS pour contacter les services AWS , indiquez ces proxys dans les champs `http_proxy` et `https_proxy`. S'il y en a URLs qui doivent être exclus de la transmission par proxy, spécifiez-les dans le `no_proxy` champ, en les séparant par des virgules.
# Installation de l' CloudWatch agent sur les serveurs locaux
Si vous avez téléchargé l' CloudWatch agent sur un ordinateur et créé le fichier de configuration de l'agent, vous pouvez utiliser ce fichier de configuration pour installer l'agent sur d'autres serveurs locaux.
## Téléchargez l' CloudWatch agent sur un serveur local
Vous pouvez télécharger le package de l' CloudWatch agent à l'aide de la commande Run de Systems Manager ou d'un lien de téléchargement Amazon S3.
### Téléchargement à l'aide de Systems Manager
Pour utiliser la fonctionnalité Exécuter la commande de Systems Manager, vous devez enregistrer votre serveur sur site auprès d'Amazon EC2 Systems Manager. Pour plus d'informations, consultez [Setting Up Systems Manager in Hybrid Environments (Configuration de Systems Manager dans des environnements hybrides)](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-managedinstances.html) dans le *Guide de l'utilisateur AWS Systems Manager *.
Si vous avez déjà enregistré votre serveur, mettez à jour l'agent SSM Agent vers la dernière version.
Pour plus d'informations sur la mise à jour de l'agent SSM sur un serveur exécutant Linux, consultez [Installation de l'agent SSM Agent pour un environnement hybride (Linux)](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-managedinstances.html#sysman-install-managed-linux) dans le *Guide de l'utilisateur AWS Systems Manager *.
Pour plus d'informations sur la mise à jour de l'agent SSM sur un serveur exécutant Windows Server, consultez [Installation de l'agent SSM Agent pour un environnement hybride (Windows)](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-managedinstances.html#sysman-install-managed-win) dans le *Guide de l'utilisateur AWS Systems Manager *.
**Pour utiliser l'agent SSM pour télécharger le package de l' CloudWatch agent sur un serveur local**
1. Ouvrez la console Systems Manager à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Dans le panneau de navigation, choisissez **Run Command (Fonctionnalité Exécuter la commande)**.
-ou-
Si la page d' AWS Systems Manager accueil s'ouvre, faites défiler la page vers le bas et choisissez **Explore Run Command**.
1. Sélectionnez **Run Command (Exécuter la commande)**.
1. Dans la liste du **document de commande**, sélectionnez le bouton à côté de **AWSPackageAWS-Configure**.
1. Dans la zone **Cibles**, sélectionnez le serveur sur lequel installer l'agent CloudWatch. Si vous ne voyez pas de serveur spécifique, c'est qu'il n'est peut-être pas configuré pour la fonctionnalité Exécuter la commande. Pour plus d'informations, consultez la section [Configuration AWS Systems Manager pour les environnements hybrides](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-managedinstances.html) dans le *guide de AWS Systems Manager l'utilisateur*.
1. Dans la liste **Action**, choisissez **Install (Installer)**.
1. Dans la case **Nom**, saisissez *AmazonCloudWatchAgent*.
1. Conservez **Version** vide pour installer la dernière version de l'agent.
1. Cliquez sur **Exécuter**.
Le package d'agents est téléchargé et les étapes suivantes permettent de le configurer et de le démarrer.
## (Installation sur un serveur local) Spécifiez les informations d'identification IAM et la région AWS
Pour permettre à l' CloudWatch agent d'envoyer des données depuis un serveur local, vous devez spécifier la clé d'accès et la clé secrète de l'utilisateur IAM que vous avez créé précédemment.
Vous devez également spécifier la AWS région à laquelle envoyer les métriques, à l'aide du `region` champ.
Voici un exemple de ce fichier.
```
[AmazonCloudWatchAgent]
aws_access_key_id=my_access_key
aws_secret_access_key=my_secret_key
region = us-west-1
```
Pour *my\$1access\$1key* et*my\$1secret\$1key*, utilisez les clés de l'utilisateur IAM qui n'est pas autorisé à écrire dans le magasin de paramètres de Systems Manager.
Aucune autre action n'est requise de votre part si vous nommez ce profil `AmazonCloudWatchAgent`. Le cas échéant, vous pouvez lui attribuer un nom différent et spécifier ce nom comme valeur pour `shared_credential_profile` dans le fichier ` common-config.toml`, ce qui est détaillé dans la section suivante.
Voici un exemple d'utilisation de la **aws configure** commande pour créer un profil nommé pour l' CloudWatch agent. Cet exemple suppose que vous utilisez le nom de profil par défaut de `AmazonCloudWatchAgent`.
**Pour créer le AmazonCloudWatchAgent profil de l' CloudWatch agent**
1. Si ce n'est pas déjà fait, installez-le AWS Command Line Interface sur le serveur. Pour plus d'informations, consultez [Installing the AWS CLI(Installation de)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html).
1. Sur les serveurs Linux, saisissez la commande suivante, puis suivez les invites :
```
sudo aws configure --profile AmazonCloudWatchAgent
```
Sur Windows Server, ouvrez PowerShell en tant qu'administrateur, entrez la commande suivante et suivez les instructions.
```
aws configure --profile AmazonCloudWatchAgent
```
## (Facultatif) Modification de la configuration commune et du profil nommé de CloudWatch l'agent
L' CloudWatch agent inclut un fichier de configuration appelé`common-config.toml`. Le cas échéant, vous pouvez utiliser ce fichier pour spécifier le proxy et les informations de région.
Sur un serveur exécutant Linux, ce fichier se trouve dans le répertoire `/opt/aws/amazon-cloudwatch-agent/etc`. Sur un serveur exécutant Windows Server, ce fichier se trouve dans le répertoire `C:\ProgramData\Amazon\AmazonCloudWatchAgent`.
Le `common-config.toml` par défaut est comme suit :
```
# This common-config is used to configure items used for both ssm and cloudwatch access
## Configuration for shared credential.
## Default credential strategy will be used if it is absent here:
## Instance role is used for EC2 case by default.
## AmazonCloudWatchAgent profile is used for onPremise case by default.
# [credentials]
# shared_credential_profile = "{profile_name}"
# shared_credential_file= "{file_name}"
## Configuration for proxy.
## System-wide environment-variable will be read if it is absent here.
## i.e. HTTP_PROXY/http_proxy; HTTPS_PROXY/https_proxy; NO_PROXY/no_proxy
## Note: system-wide environment-variable is not accessible when using ssm run-command.
## Absent in both here and environment-variable means no proxy will be used.
# [proxy]
# http_proxy = "{http_url}"
# https_proxy = "{https_url}"
# no_proxy = "{domain}"
```
Toutes les lignes comportent initialement un commentaire. Pour définir le profil des informations d'identification ou les paramètres de proxy, retirez `#` de cette ligne et indiquez une valeur. Vous pouvez éditer ce fichier manuellement ou en utilisant la fonctionnalité Exécuter la commande `RunShellScript` dans Systems Manager :
+ `shared_credential_profile`— Pour les serveurs locaux, cette ligne indique le profil d'identification de l'utilisateur IAM à utiliser pour envoyer des données. CloudWatch Si vous conservez les commentaires de cette ligne, `AmazonCloudWatchAgent` est utilisé. Pour plus d'informations sur la création de ce profil, consultez la page [(Installation sur un serveur local) Spécifiez les informations d'identification IAM et la région AWS](#install-CloudWatch-Agent-iam_user-SSM-onprem).
Sur une instance EC2, vous pouvez utiliser cette ligne pour que l' CloudWatch agent envoie des données depuis cette instance vers CloudWatch une autre AWS région. Pour ce faire, spécifiez un profil nommé qui inclut un champ `region` en spécifiant le nom de la région destinataire.
Si vous spécifiez une ligne `shared_credential_profile`, vous devez également supprimer le `#` au début de la ligne `[credentials]`.
+ `shared_credential_file` – Pour que l'agent cherche des informations d'identification dans un fichier situé sur un chemin autre que le chemin par défaut, spécifiez ici le chemin d'accès complet et le nom de fichier. Le chemin d'accès par défaut est `/root/.aws` sous Linux et `C:\\Users\\Administrator\\.aws` sous Windows Server.
Le premier exemple ci-après montre la syntaxe d'une ligne `shared_credential_file` valide pour les serveurs Linux et le deuxième exemple est valide pour Windows Server. Sous Windows Server, vous devez utiliser le caractère d'échappement \$1.
```
shared_credential_file= "/usr/username/credentials"
```
```
shared_credential_file= "C:\\Documents and Settings\\username\\.aws\\credentials"
```
Si vous spécifiez une ligne `shared_credential_file`, vous devez également supprimer le `#` au début de la ligne `[credentials]`.
+ Paramètres de proxy – Si vos serveurs utilisent des proxys HTTP ou HTTPS pour contacter les services AWS , indiquez ces proxys dans les champs `http_proxy` et `https_proxy`. S'il y en a URLs qui doivent être exclus de la transmission par proxy, spécifiez-les dans le `no_proxy` champ, en les séparant par des virgules.
# Installez l' CloudWatch agent sur les nouvelles instances à l'aide de CloudFormation
Cette section décrit comment installer l' CloudWatch agent sur les nouvelles instances Amazon EC2 à l'aide de. AWS CloudFormation
**Note**
Amazon a téléchargé plusieurs CloudFormation modèles GitHub qui peuvent vous aider à installer et à mettre à jour l' CloudWatch agent sur les nouvelles instances Amazon EC2. Pour plus d'informations sur l'utilisation CloudFormation, voir [Qu'est-ce que c'est AWS CloudFormation ?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) .
L'emplacement du modèle est [Déployer l' CloudWatch agent Amazon sur les instances EC2 à l'aide CloudFormation](https://github.com/aws-cloudformation/aws-cloudformation-templates/tree/main/Solutions/AmazonCloudWatchAgent) de. Cet emplacement inclut à la fois les répertoires `inline` et `ssm`. Chacun de ces répertoires contient des modèles pour les instances Linux et Windows.
+ La configuration de l' CloudWatch agent est intégrée aux CloudFormation modèles du `inline` répertoire. Par défaut, les modèles Linux collectent les métriques `mem_used_percent` et `swap_used_percent` et les modèles Windows collectent `Memory % Committed Bytes In Use` et `Paging File % Usage`.
Modifiez la section suivante du modèle afin de modifier ces modèles pour la collecte de différentes métriques. L'exemple suivant est issu du modèle pour les serveurs Linux. Respectez le format et la syntaxe du fichier de configuration de l'agent pour effectuer ces modifications. Pour de plus amples informations, consultez [Création ou modification manuelle du fichier de configuration de CloudWatch l'agent](CloudWatch-Agent-Configuration-File-Details.md).
```
{
"metrics":{
"append_dimensions":{
"AutoScalingGroupName":"${!aws:AutoScalingGroupName}",
"ImageId":"${!aws:ImageId}",
"InstanceId":"${!aws:InstanceId}",
"InstanceType":"${!aws:InstanceType}"
},
"metrics_collected":{
"mem":{
"measurement":[
"mem_used_percent"
]
},
"swap":{
"measurement":[
"swap_used_percent"
]
}
}
}
}
```
**Note**
Dans les modèles en ligne, toutes les variables d'espace réservé doivent commencer par un point d'exclamation (\$1) comme caractère d'échappement. Vous pouvez le constater dans l'exemple de modèle. Si vous ajoutez d'autres variables d'espace réservé, veillez à ajouter un point d'exclamation avant le nom.
+ Les modèles dans le répertoire `ssm` chargent un fichier de configuration d'agent à partir du Parameter Store. Pour utiliser ces modèles, vous devez d'abord créer un fichier de configuration et le charger dans le Parameter Store. Ensuite, vous indiquez le nom du Parameter Store du fichier dans le modèle. Vous pouvez créer le fichier de configuration manuellement ou à l'aide de l'assistant. Pour de plus amples informations, veuillez consulter [Création du fichier de configuration de CloudWatch l'agent](create-cloudwatch-agent-configuration-file.md).
Vous pouvez utiliser les deux types de modèles pour installer l' CloudWatch agent et pour mettre à jour la configuration de l'agent.
Pour plus d'informations sur la configuration de l'agent sur un système sur lequel Linux (SELinux) amélioré en termes de sécurité est activé, consultez. [Configuration de l' CloudWatch agent avec Linux renforcé en termes de sécurité () SELinux](CloudWatch-Agent-SELinux.md)
## Tutoriel : Installation et configuration de l' CloudWatch agent à l'aide d'un CloudFormation modèle intégré
Ce didacticiel explique comment CloudFormation installer l' CloudWatch agent sur une nouvelle instance Amazon EC2. Ce didacticiel s'installe sur une nouvelle instance qui exécute Amazon Linux 2 à l'aide de modèles en ligne qui ne nécessitent pas l'utilisation de fichier de configuration JSON ou du Parameter Store. Le modèle en ligne inclut la configuration de l'agent dans le modèle. Dans ce tutoriel, vous utilisez la configuration de l'agent par défaut contenue dans le modèle.
Après la procédure d'installation de l'agent, le tutoriel vous explique comment mettre à jour l'agent.
**À utiliser CloudFormation pour installer l' CloudWatch agent sur une nouvelle instance**
1. Téléchargez le modèle depuis GitHub. Dans ce didacticiel, téléchargez le modèle en ligne pour Amazon Linux 2 comme suit :
```
curl -O https://raw.githubusercontent.com/aws-cloudformation/aws-cloudformation-templates/main/Solutions/AmazonCloudWatchAgent/inline/amazon_linux.yaml
```
1. Ouvrez la CloudFormation console à l'adresse [https://console.aws.amazon.com/cloudformation.](https://console.aws.amazon.com/cloudformation/)
1. Sélectionnez **Créer la pile**.
1. Pour **Choisir un modèle**, sélectionnez **Télécharger un modèle sur Amazon S3**, choisissez le modèle téléchargé, puis **Next (Suivant)**.
1. Sur la page **Spécifier les détails**, renseignez les paramètres suivants, puis choisissez **Next (Suivant)** :
+ **Nom de pile** : Choisissez un nom de pile pour votre CloudFormation pile.
+ **IAMRole**: Choisissez un rôle IAM autorisé à écrire des CloudWatch métriques, des journaux et des traces. Pour de plus amples informations, veuillez consulter [Conditions préalables](prerequisites.md).
+ **InstanceAMI** : choisissez une AMI valide dans la région dans laquelle vous allez lancer votre pile.
+ **InstanceType**: Choisissez un type d'instance valide.
+ **KeyName**: Pour activer l'accès SSH à la nouvelle instance, choisissez une paire de clés Amazon EC2 existante. Si vous ne possédez pas déjà une paire de clés Amazon EC2, vous pouvez en créer une dans l' AWS Management Console. Pour plus d’informations, consultez [Paires de clés Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) dans le *Guide de l’utilisateur Amazon EC2*.
+ **SSHLocation**: Spécifie la plage d'adresses IP qui peut être utilisée pour se connecter à l'instance via SSH. La valeur par défaut autorise l'accès depuis n'importe quelle adresse IP.
1. Dans la page **Options**, vous pouvez étiqueter les ressources de votre pile. Choisissez **Next (Suivant)**.
1. Sur la page **Review (Vérification)**, vérifiez vos informations, reconnaissez que la pile peut créer des ressources IAM, puis choisissez **Create (Créer)**.
Si vous actualisez la console, vous voyez que la nouvelle pile présente l'état `CREATE_IN_PROGRESS`.
1. Une fois l'instance créée, vous pouvez la voir dans la console Amazon EC2. Ensuite, vous pouvez vous connecter à l'hôte et vérifier la progression.
Utilisez la commande suivante pour confirmer que l'agent est installé :
```
rpm -qa amazon-cloudwatch-agent
```
Utilisez la commande suivante pour confirmer que l'agent est en cours d'exécution :
```
ps aux | grep amazon-cloudwatch-agent
```
La procédure suivante explique comment mettre CloudFormation à jour l' CloudWatch agent à l'aide d'un modèle intégré. Par défaut, le modèle en ligne collecte la métrique `mem_used_percent`. Dans ce tutoriel, vous modifiez la configuration de l'agent pour arrêter la collecte de cette métrique.
**À utiliser CloudFormation pour mettre à jour l' CloudWatch agent**
1. Dans le modèle que vous avez téléchargé lors de la procédure précédente, supprimez les lignes suivantes, puis enregistrez le modèle :
```
"mem": {
"measurement": [
"mem_used_percent"
]
},
```
1. Ouvrez la CloudFormation console à l'adresse [https://console.aws.amazon.com/cloudformation.](https://console.aws.amazon.com/cloudformation/)
1. Sur le CloudFormation tableau de bord, sélectionnez la pile que vous avez créée et choisissez **Update Stack**.
1. Pour **Select Template (Sélectionner un modèle)**, sélectionnez **Télécharger un modèle sur Amazon S3**, choisissez le modèle modifié, puis **Next (Suivant)**.
1. Sur la page **Options**, choisissez **Next (Suivant)**, puis **Next**.
1. Dans la page **Review (Révision)**, passez en revue vos informations et choisissez **Update (Mettre à jour)**.
Après un certain temps, `UPDATE_COMPLETE` s'affiche.
## Tutoriel : Installation de l' CloudWatch agent à l'aide CloudFormation d'un magasin de paramètres
Ce didacticiel explique comment CloudFormation installer l' CloudWatch agent sur une nouvelle instance Amazon EC2. Ce didacticiel s'installe sur une nouvelle instance qui exécute Amazon Linux 2 à l'aide d'un fichier de configuration de l'agent que vous créez et enregistrez dans le Parameter Store.
Après la procédure d'installation de l'agent, le tutoriel vous explique comment mettre à jour l'agent.
**À utiliser CloudFormation pour installer l' CloudWatch agent sur une nouvelle instance à l'aide d'une configuration provenant du Parameter Store**
1. Si ce n'est pas déjà fait, téléchargez le package de l' CloudWatch agent sur l'un de vos ordinateurs afin de créer le fichier de configuration de l'agent. Pour plus d'informations et pour télécharger l'agent à l'aide du Parameter Store, consultez [Téléchargez le package de CloudWatch l'agent](download-CloudWatch-Agent-on-EC2-Instance-commandline-first.md).
1. Créez le fichier de configuration d'agent et enregistrez-le dans le Parameter Store. Pour de plus amples informations, veuillez consulter [Création du fichier de configuration de CloudWatch l'agent](create-cloudwatch-agent-configuration-file.md).
1. Téléchargez le modèle GitHub comme suit :
```
curl -O https://raw.githubusercontent.com/awslabs/aws-cloudformation-templates/master/aws/solutions/AmazonCloudWatchAgent/ssm/amazon_linux.template
```
1. Ouvrez la CloudFormation console à l'adresse [https://console.aws.amazon.com/cloudformation.](https://console.aws.amazon.com/cloudformation/)
1. Sélectionnez **Créer la pile**.
1. Pour **Choisir un modèle**, sélectionnez **Télécharger un modèle sur Amazon S3**, choisissez le modèle que vous avez téléchargé, puis **Next (Suivant)**.
1. Sur la page **Specify Details (Spécifier les détails)**, renseignez les paramètres suivants en conséquence, puis choisissez **Next (Suivant)**.
+ **Nom de pile** : Choisissez un nom de pile pour votre CloudFormation pile.
+ **IAMRole**: Choisissez un rôle IAM autorisé à écrire des CloudWatch métriques, des journaux et des traces. Pour de plus amples informations, veuillez consulter [Conditions préalables](prerequisites.md).
+ **InstanceAMI** : choisissez une AMI valide dans la région dans laquelle vous allez lancer votre pile.
+ **InstanceType**: Choisissez un type d'instance valide.
+ **KeyName**: Pour activer l'accès SSH à la nouvelle instance, choisissez une paire de clés Amazon EC2 existante. Si vous ne possédez pas déjà une paire de clés Amazon EC2, vous pouvez en créer une dans l' AWS Management Console. Pour plus d’informations, consultez [Paires de clés Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) dans le *Guide de l’utilisateur Amazon EC2*.
+ **SSHLocation**: Spécifie la plage d'adresses IP qui peut être utilisée pour se connecter à l'instance via SSH. La valeur par défaut autorise l'accès depuis n'importe quelle adresse IP.
+ **SSMKey**: Spécifie le fichier de configuration de l'agent que vous avez créé et enregistré dans Parameter Store.
1. Dans la page **Options**, vous pouvez étiqueter les ressources de votre pile. Choisissez **Next (Suivant)**.
1. Sur la page **Review (Vérification)**, vérifiez vos informations, reconnaissez que la pile peut créer des ressources IAM, puis choisissez **Create (Créer)**.
Si vous actualisez la console, vous voyez que la nouvelle pile présente l'état `CREATE_IN_PROGRESS`.
1. Une fois l'instance créée, vous pouvez la voir dans la console Amazon EC2. Ensuite, vous pouvez vous connecter à l'hôte et vérifier la progression.
Utilisez la commande suivante pour confirmer que l'agent est installé :
```
rpm -qa amazon-cloudwatch-agent
```
Utilisez la commande suivante pour confirmer que l'agent est en cours d'exécution :
```
ps aux | grep amazon-cloudwatch-agent
```
La procédure suivante montre comment mettre CloudFormation à jour l' CloudWatch agent à l'aide d'une configuration d'agent que vous avez enregistrée dans Parameter Store.
**À utiliser pour mettre CloudFormation à jour l' CloudWatch agent à l'aide d'une configuration dans Parameter Store**
1. Modifiez le fichier de configuration de l'agent stocké dans le Parameter Store avec la nouvelle configuration de votre choix.
1. Dans le CloudFormation modèle que vous avez téléchargé dans la [Tutoriel : Installation de l' CloudWatch agent à l'aide CloudFormation d'un magasin de paramètres](#installing-CloudWatch-Agent-using-CloudFormation-Templates) rubrique, modifiez le numéro de version. Par exemple, vous pouvez remplacer `VERSION=1.0` par `VERSION=2.0`.
1. Ouvrez la CloudFormation console à l'adresse [https://console.aws.amazon.com/cloudformation.](https://console.aws.amazon.com/cloudformation/)
1. Sur le CloudFormation tableau de bord, sélectionnez la pile que vous avez créée et choisissez **Update Stack**.
1. Pour **Sélectionner un modèle**, sélectionnez **Télécharger un modèle sur Amazon S3**, sélectionnez le modèle que vous venez de modifier, puis **Next (Suivant)**.
1. Sur la page **Options**, choisissez **Next (Suivant)**, puis **Next**.
1. Dans la page **Review (Révision)**, passez en revue vos informations et choisissez **Update (Mettre à jour)**.
Après un certain temps, `UPDATE_COMPLETE` s'affiche.
## Résolution des problèmes liés à l'installation de CloudWatch l'agent avec CloudFormation
Cette section vous aide à résoudre les problèmes liés à l'installation et à la mise à jour de l' CloudWatch agent à l'aide CloudFormation de.
### Détection de l'échec d'une mise à jour
Si vous avez l' CloudFormation habitude de mettre à jour la configuration de votre CloudWatch agent et que vous utilisez une configuration non valide, l'agent arrête d'envoyer des métriques à CloudWatch. Pour vérifier rapidement si la mise à jour de la configuration d'un agent a réussi, consultez le fichier `cfn-init-cmd.log`. Sur un serveur Linux, le fichier se situe à l'emplacement `/var/log/cfn-init-cmd.log`. Sur une instance Windows, le fichier se situe à l'emplacement `C:\cfn\log\cfn-init-cmd.log`.
### Métriques manquantes
Si vous ne voyez pas les métriques prévues après l'installation ou la mise à jour de l'agent, vérifiez que l'agent est configuré pour collecter cette métrique. Pour cela, vérifiez le fichier `amazon-cloudwatch-agent.json` pour vous assurer que la métrique est répertoriée, et que vous recherchez dans le bon espace de noms de métrique. Pour de plus amples informations, veuillez consulter [CloudWatch fichiers et emplacements des agents](troubleshooting-CloudWatch-Agent.md#CloudWatch-Agent-files-and-locations).
# Installez l' CloudWatch agent avec le module complémentaire Amazon CloudWatch Observability EKS ou le graphique Helm
Vous pouvez utiliser le module complémentaire Amazon CloudWatch Observability EKS ou le graphique Amazon CloudWatch Observability Helm pour installer l' CloudWatch agent et l'agent Fluent-bit sur un cluster Amazon EKS. Vous pouvez également utiliser le graphique Helm pour installer l' CloudWatch agent et l'agent Fluent-bit sur un cluster Kubernetes qui n'est pas hébergé sur Amazon EKS.
L'utilisation de l'une ou l'autre méthode sur un cluster Amazon EKS permet à [Container Insights](ContainerInsights.md) de bénéficier d'une observabilité améliorée pour Amazon EKS et [CloudWatch d'Application Signals](CloudWatch-Application-Monitoring-Sections.md) par défaut. Ces deux fonctionnalités vous permettent de collecter des métriques d’infrastructure, des données de performance applicative et des journaux de conteneurs provenant du cluster.
Avec la version `v6.0.1-eksbuild.1` ou une version ultérieure du module complémentaire, Container Insights with OpenTelemetry metrics est activé. Il collecte les métriques à l'aide du OpenTelemetry protocole (OTLP) et prend en charge les requêtes ProMQL. Pour de plus amples informations, veuillez consulter [Container Insights avec OpenTelemetry métriques pour Amazon EKS](container-insights-otel-metrics.md).
Grâce à Container Insights avec observabilité améliorée pour Amazon EKS, les métriques de Container Insights sont facturées par observation au lieu d'être facturées par métrique stockée ou par journal ingéré. Pour Application Signals, la facturation est basée sur les demandes entrantes adressées à vos applications, les demandes sortantes provenant de vos applications et sur chaque objectif de niveau de service (SLO) configuré. Chaque requête entrante reçue génère un signal d’application, et chaque requête sortante effectuée génère un signal d’application. Chaque SLO crée deux signaux d’application par période de mesure. Pour plus d'informations sur CloudWatch les tarifs, consultez [Amazon CloudWatch Pricing](https://aws.amazon.com/cloudwatch/pricing/).
Les deux méthodes permettent d’activer Container Insights sur les nœuds de calcul Linux et Windows d’un cluster Amazon EKS. Pour activer Container Insights sur Windows, vous devez utiliser la version 1.5.0 ou ultérieure du module complémentaire Amazon EKS ou des Charts de Helm. La vigie applicative n’est pas prise en charge sur Windows dans les clusters Amazon EKS.
Le module complémentaire Amazon CloudWatch Observability EKS est pris en charge sur les clusters Amazon EKS exécutés avec Kubernetes version 1.23 ou ultérieure.
Lorsque vous installez le module complémentaire ou le graphique Helm, vous devez également accorder des autorisations IAM pour permettre à l' CloudWatch agent d'envoyer des métriques, des journaux et des traces à CloudWatch. Il existe deux façons de procéder :
+ Attachez une politique au rôle IAM de vos composants master. Cette option accorde des autorisations aux nœuds de travail auxquels envoyer des données télémétriques. CloudWatch
+ Utilisez un rôle IAM pour les comptes de service des pods d'agent et attachez la politique à ce rôle. Cela ne fonctionne que pour les clusters Amazon EKS. Cette option donne CloudWatch accès uniquement aux modules d'agent appropriés.
**Topics**
+ [
## Option 1 : installation à l’aide de l’identité du pod EKS
](#install-CloudWatch-Observability-EKS-pod-identity)
+ [
## Option 2 : Installation avec des autorisations IAM sur les nœuds de travail
](#install-CloudWatch-Observability-EKS-addon-workernodes)
+ [
## Option 3 : installation à l’aide d’un rôle de compte de service IAM (valable uniquement pour le module complémentaire)
](#install-CloudWatch-Observability-EKS-addon-serviceaccountrole)
+ [
## Considérations relatives aux nœuds hybrides Amazon EKS
](#install-CloudWatch-Observability-EKS-addon-hybrid)
+ [
## (Facultatif) Configuration supplémentaire
](#install-CloudWatch-Observability-EKS-addon-configuration)
+ [
## Collecte des métriques Java Management Extensions (JMX)
](#install-CloudWatch-Observability-EKS-addon-JMX-metrics)
+ [
## Activation des métriques Kueue
](#enable-Kueue-metrics)
+ [
## Ajout de fichiers de configuration du OpenTelemetry collecteur
](#install-CloudWatch-Observability-EKS-addon-OpenTelemetry)
+ [
## Activation de l'APM via des signaux d'application pour votre cluster Amazon EKS
](#Container-Insights-setup-EKS-appsignalsconfiguration)
+ [
## Résolution des problèmes liés au module complémentaire Amazon CloudWatch Observability EKS ou au graphique Helm
](#Container-Insights-setup-EKS-addon-troubleshoot)
+ [
## Désactiver les signaux d'application
](#Opting-out-App-Signals)
## Option 1 : installation à l’aide de l’identité du pod EKS
Si vous utilisez la version 3.1.0 ou ultérieure du module complémentaire, vous pouvez utiliser l’identité du pod EKS pour accorder les autorisations requises au module complémentaire. L’identité du pod EKS est l’option recommandée, car elle offre plusieurs avantages, notamment le moindre privilège, la rotation des informations d’identification et l’auditabilité. De plus, l’utilisation de l’identité du pod EKS vous permet d’installer le module complémentaire EKS dès la création du cluster.
Pour utiliser cette méthode, commencez par suivre les étapes de la section [Association d’identité du pod EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-association.html#pod-id-association-create/) afin de créer le rôle IAM et de configurer l’agent d’identité du pod EKS.
Installez ensuite le module complémentaire Amazon CloudWatch Observability EKS. Pour installer le module complémentaire, vous pouvez utiliser la AWS CLI console Amazon EKS ou Terraform. CloudFormation
------
#### [ AWS CLI ]
**Pour utiliser le module complémentaire Amazon CloudWatch Observability EKS AWS CLI pour installer le module complémentaire Amazon Observability**
Entrez les commandes suivantes : Remplacez `my-cluster-name` par le nom de votre cluster et remplacez *111122223333* par votre identifiant de compte. *my-role*Remplacez-le par le rôle IAM que vous avez créé à l'étape d'association d'EKS Pod Identity.
```
aws iam attach-role-policy \
--role-name my-role \
--policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
aws eks create-addon \
--addon-name amazon-cloudwatch-observability \
--cluster-name my-cluster-name \
--pod-identity-associations serviceAccount=cloudwatch-agent,roleArn=arn:aws:iam::111122223333:role/my-role
```
------
#### [ Amazon EKS console ]
**Pour utiliser la console Amazon EKS afin d'ajouter le module complémentaire Amazon CloudWatch Observability EKS**
1. Ouvrez la console Amazon EKS à l'adresse [https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters).
1. Dans le volet de navigation de gauche, choisissez **Clusters**.
1. Choisissez le nom du cluster pour lequel vous souhaitez configurer le module complémentaire Amazon CloudWatch Observability EKS.
1. Choisissez l’onglet **Modules complémentaires**.
1. Choisissez **Obtenez plus de modules complémentaires**.
1. Sur la page **Sélectionner des modules complémentaires**, procédez comme suit :
1. Dans la section **Amazon EKS-Addons**, cochez la case **Amazon CloudWatch Observability**.
1. Choisissez **Suivant**.
1. Sur la page **Configurer les paramètres des modules complémentaires sélectionnés**, procédez comme suit :
1. Sélectionnez la **version** que vous souhaitez utiliser.
1. Pour **Accès au module complémentaire**, sélectionnez **Identité du pod EKS**
1. Si aucun rôle IAM n’est configuré, sélectionnez **Créer un rôle recommandé**, puis cliquez sur **Suivant** jusqu’à ce que vous soyez à l’**Étape 3 : nom, vérification et création**. Vous pouvez modifier le nom de votre rôle si vous le souhaitez. Sinon, sélectionnez **Créer un rôle**, puis revenez à la page du module complémentaire et sélectionnez le rôle IAM que vous venez de créer.
1. (Facultatif) Vous pouvez développer les **paramètres de configuration facultatifs**. Si vous sélectionnez **Remplacer** pour la **méthode de résolution des conflits**, un ou plusieurs des paramètres du module complémentaire existant peuvent être remplacés par les paramètres du module complémentaire Amazon EKS. Si vous n'activez pas cette option et qu'il y a un conflit avec vos paramètres existants, l'opération échoue. Vous pouvez utiliser le message d'erreur qui en résulte pour résoudre le conflit. Avant de sélectionner cette option, assurez-vous que le module complémentaire Amazon EKS ne gère pas les paramètres que vous devez gérer vous-même.
1. Choisissez **Suivant**.
1. Sur la page **Vérifier et ajouter**, choisissez **Créer**. Une fois l'installation du module complémentaire terminée, vous pouvez voir le module complémentaire installé.
------
#### [ CloudFormation ]
**À utiliser CloudFormation pour installer le module complémentaire Amazon CloudWatch Observability EKS**
1. Exécutez d'abord la AWS CLI commande suivante pour associer la politique IAM nécessaire à votre rôle IAM. *my-role*Remplacez-le par le rôle que vous avez créé à l'étape d'association d'EKS Pod Identity.
```
aws iam attach-role-policy \
--role-name my-role \
--policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
```
1. Ensuite, créez lea ressource suivante. Remplacez `my-cluster-name` par le nom de votre cluster, remplacez *111122223333* par votre identifiant de compte et remplacez par le rôle IAM créé *my-role* à l'étape d'association d'EKS Pod Identity. Pour plus d'informations, consultez [ AWS::EKS::Addon](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-eks-addon.html).
```
{
"Resources": {
"EKSAddOn": {
"Type": "AWS::EKS::Addon",
"Properties": {
"AddonName": "amazon-cloudwatch-observability",
"ClusterName": "my-cluster-name",
"PodIdentityAssociations": [
{
"ServiceAccount": "cloudwatch-agent",
"RoleArn": "arn:aws:iam::111122223333:role/my-role"
}
]
}
}
}
}
```
------
#### [ Terraform ]
**Pour utiliser Terraform pour installer le module complémentaire Amazon CloudWatch Observability EKS**
1. Utilisez ce qui suit. Remplacez `my-cluster-name` par le nom de votre cluster, remplacez *111122223333* par votre identifiant de compte et remplacez par le rôle IAM créé *my-service-account-role* à l'étape d'association d'EKS Pod Identity.
Pour plus d’informations, consultez [Ressource : aws\$1eks\$1addon](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/eks_addon) dans la documentation Terraform.
1.
```
resource "aws_iam_role_policy_attachment" "CloudWatchAgentServerPolicy" {
policy_arn = "arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy"
role = "my-role"
}
resource "aws_eks_addon" "example" {
cluster_name = "my-cluster-name"
addon_name = "amazon-cloudwatch-observability"
pod_identity_associations {
roleArn = "arn:aws:iam::111122223333:role/my-role"
serviceAccount = "cloudwatch-agent"
}
}
```
------
## Option 2 : Installation avec des autorisations IAM sur les nœuds de travail
Pour utiliser cette méthode, associez d'abord la politique **CloudWatchAgentServerPolicy**IAM à vos nœuds de travail en saisissant la commande suivante. Dans cette commande, remplacez-le *my-worker-node-role* par le rôle IAM utilisé par vos nœuds de travail Kubernetes.
```
aws iam attach-role-policy \
--role-name my-worker-node-role \
--policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
```
Installez ensuite le module complémentaire Amazon CloudWatch Observability EKS. Pour installer le module complémentaire, vous pouvez utiliser la AWS CLI console ou Terraform. CloudFormation
------
#### [ AWS CLI ]
**Pour utiliser le module complémentaire Amazon CloudWatch Observability EKS AWS CLI pour installer le module complémentaire Amazon Observability**
Entrez la commande suivante. Remplacez `my-cluster-name` par le nom de votre cluster.
```
aws eks create-addon --addon-name amazon-cloudwatch-observability --cluster-name my-cluster-name
```
------
#### [ Amazon EKS console ]
**Pour utiliser la console Amazon EKS afin d'ajouter le module complémentaire Amazon CloudWatch Observability EKS**
1. Ouvrez la console Amazon EKS à l'adresse [https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters).
1. Dans le volet de navigation de gauche, choisissez **Clusters**.
1. Choisissez le nom du cluster pour lequel vous souhaitez configurer le module complémentaire Amazon CloudWatch Observability EKS.
1. Choisissez l’onglet **Modules complémentaires**.
1. Choisissez **Obtenez plus de modules complémentaires**.
1. Sur la page **Sélectionner des modules complémentaires**, procédez comme suit :
1. Dans la section **Amazon EKS-Addons**, cochez la case **Amazon CloudWatch Observability**.
1. Choisissez **Suivant**.
1. Sur la page **Configurer les paramètres des modules complémentaires sélectionnés**, procédez comme suit :
1. Sélectionnez la **version** que vous souhaitez utiliser.
1. (Facultatif) Vous pouvez développer les **paramètres de configuration facultatifs**. Si vous sélectionnez **Remplacer** pour la **méthode de résolution des conflits**, un ou plusieurs des paramètres du module complémentaire existant peuvent être remplacés par les paramètres du module complémentaire Amazon EKS. Si vous n'activez pas cette option et qu'il y a un conflit avec vos paramètres existants, l'opération échoue. Vous pouvez utiliser le message d'erreur qui en résulte pour résoudre le conflit. Avant de sélectionner cette option, assurez-vous que le module complémentaire Amazon EKS ne gère pas les paramètres que vous devez gérer vous-même.
1. Choisissez **Suivant**.
1. Sur la page **Vérifier et ajouter**, choisissez **Créer**. Une fois l'installation du module complémentaire terminée, vous pouvez voir le module complémentaire installé.
------
#### [ CloudFormation ]
**À utiliser CloudFormation pour installer le module complémentaire Amazon CloudWatch Observability EKS**
Remplacez `my-cluster-name` par le nom de votre cluster. Pour plus d'informations, consultez [ AWS::EKS::Addon](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-eks-addon.html).
```
{
"Resources": {
"EKSAddOn": {
"Type": "AWS::EKS::Addon",
"Properties": {
"AddonName": "amazon-cloudwatch-observability",
"ClusterName": "my-cluster-name"
}
}
}
}
```
------
#### [ Helm chart ]
**Pour utiliser les Charts de Helm `amazon-cloudwatch-observability`**
1. Vous devez avoir Helm installé pour pouvoir utiliser ce graphique. Pour plus d’informations sur l’installation de Helm, consultez la [documentation Helm](https://helm.sh/docs/).
1. Une fois Helm installé, saisissez les commandes suivantes. Remplacez *my-cluster-name* par le nom de votre cluster et remplacez *my-cluster-region* par la région dans laquelle le cluster s'exécute.
```
helm repo add aws-observability https://aws-observability.github.io/helm-charts
helm repo update aws-observability
helm install --wait --create-namespace --namespace amazon-cloudwatch amazon-cloudwatch-observability aws-observability/amazon-cloudwatch-observability --set clusterName=my-cluster-name --set region=my-cluster-region
```
------
#### [ Terraform ]
**Pour utiliser Terraform pour installer le module complémentaire Amazon CloudWatch Observability EKS**
Remplacez `my-cluster-name` par le nom de votre cluster. Pour plus d'informations, veuillez consulter [Ressource : aws\$1eks\$1addon](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/eks_ad) (langue française non garantie).
```
resource "aws_eks_addon" "example" {
addon_name = "amazon-cloudwatch-observability"
cluster_name = "my-cluster-name"
}
```
------
## Option 3 : installation à l’aide d’un rôle de compte de service IAM (valable uniquement pour le module complémentaire)
Cette méthode n'est valide que si vous utilisez le module complémentaire Amazon CloudWatch Observability EKS. Avant d'utiliser cette méthode, vérifiez que les conditions préalables suivantes sont respectées :
+ Vous disposez d'un cluster Amazon EKS fonctionnel avec des nœuds rattachés à l'une des Régions AWS prenant en charge Container Insights. Pour obtenir la liste des régions prises en charge, consultez [Container Insights](ContainerInsights.md).
+ `kubectl` est installé et configuré pour le cluster. Pour plus d'informations, consultez [Installation de `kubectl`](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html) dans le *Guide de l'utilisateur Amazon EKS*.
+ `eksctl` est installé. Pour plus d'informations, veuillez consulter [Installation ou mise à jour de `eksctl`](https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html) dans le *Guide de l'utilisateur Amazon EKS*.
------
#### [ AWS CLI ]
**Pour utiliser le AWS CLI pour installer le module complémentaire Amazon CloudWatch Observability EKS à l'aide du rôle de compte de service IAM**
1. Saisissez la commande suivante pour créer un fournisseur OpenID Connect (OIDC), si le cluster n'en possède pas déjà un. Pour plus d'informations, veuillez consulter [Configuration d'un compte de service Kubernetes pour assumer un rôle IAM](https://docs.aws.amazon.com/eks/latest/userguide/associate-service-account-role.html) dans le *Guide de l'utilisateur Amazon EKS*.
```
eksctl utils associate-iam-oidc-provider --cluster my-cluster-name --approve
```
1. Entrez la commande suivante pour créer le rôle IAM avec la **CloudWatchAgentServerPolicy**politique attachée, et configurez le compte de service de l'agent pour qu'il assume ce rôle à l'aide d'OIDC. Remplacez *my-cluster-name* par le nom de votre cluster, *my-service-account-role* puis par le nom du rôle auquel vous souhaitez associer le compte de service. Si le rôle n'existe pas encore, `eksctl` le crée pour vous.
```
eksctl create iamserviceaccount \
--name cloudwatch-agent \
--namespace amazon-cloudwatch --cluster my-cluster-name \
--role-name my-service-account-role \
--attach-policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy \
--role-only \
--approve
```
1. Installez l'add-on en saisissant la commande suivante. Remplacez *my-cluster-name* par le nom de votre cluster, remplacez *111122223333* par votre ID de compte et remplacez *my-service-account-role* par le rôle IAM créé à l'étape précédente.
```
aws eks create-addon --addon-name amazon-cloudwatch-observability --cluster-name my-cluster-name --service-account-role-arn arn:aws:iam::111122223333:role/my-service-account-role
```
------
#### [ Amazon EKS console ]
**Pour utiliser la console afin d'installer le module complémentaire Amazon CloudWatch Observability EKS à l'aide du rôle de compte de service IAM**
1. Ouvrez la console Amazon EKS à l'adresse [https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters).
1. Dans le volet de navigation de gauche, choisissez **Clusters**.
1. Choisissez le nom du cluster pour lequel vous souhaitez configurer le module complémentaire Amazon CloudWatch Observability EKS.
1. Choisissez l’onglet **Modules complémentaires**.
1. Choisissez **Obtenez plus de modules complémentaires**.
1. Sur la page **Sélectionner des modules complémentaires**, procédez comme suit :
1. Dans la section **Amazon EKS-Addons**, cochez la case **Amazon CloudWatch Observability**.
1. Choisissez **Suivant**.
1. Sur la page **Configurer les paramètres des modules complémentaires sélectionnés**, procédez comme suit :
1. Sélectionnez la **version** que vous souhaitez utiliser.
1. Pour **Accès au module complémentaire**, sélectionnez **Rôles IAM pour les comptes de service (IRSA)**
1. Sélectionnez le rôle IAM dans la zone **Accès au module complémentaire**.
1. (Facultatif) Vous pouvez développer les **paramètres de configuration facultatifs**. Si vous sélectionnez **Remplacer** pour la **méthode de résolution des conflits**, un ou plusieurs des paramètres du module complémentaire existant peuvent être remplacés par les paramètres du module complémentaire Amazon EKS. Si vous n'activez pas cette option et qu'il y a un conflit avec vos paramètres existants, l'opération échoue. Vous pouvez utiliser le message d'erreur qui en résulte pour résoudre le conflit. Avant de sélectionner cette option, assurez-vous que le module complémentaire Amazon EKS ne gère pas les paramètres que vous devez gérer vous-même.
1. Choisissez **Suivant**.
1. Sur la page **Vérifier et ajouter**, choisissez **Créer**. Une fois l'installation du module complémentaire terminée, vous pouvez voir le module complémentaire installé.
------
## Considérations relatives aux nœuds hybrides Amazon EKS
Les métriques au niveau des nœuds ne sont pas disponibles pour les nœuds hybrides, car [Container Insights](ContainerInsights.md) dépend de la disponibilité du [Service de métadonnées d’instance (IMDS) EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html). Les métriques au niveau du cluster, de la charge de travail, du Pod et du conteneur sont disponibles pour les nœuds hybrides.
Après avoir installé le module complémentaire en suivant les étapes des sections précédentes, vous devez mettre à jour le manifeste du module complémentaire afin que l’agent puisse s’exécuter correctement sur les nœuds hybrides. Modifiez la ressource `amazoncloudwatchagents` dans le cluster afin d’ajouter la variable d’environnement `RUN_WITH_IRSA`, comme illustré ci-dessous.
```
kubectl edit amazoncloudwatchagents -n amazon-cloudwatch cloudwatch-agent
```
```
apiVersion: v1
items:
- apiVersion: cloudwatch.aws.amazon.com/v1alpha1
kind: AmazonCloudWatchAgent
metadata:
...
name: cloudwatch-agent
namespace: amazon-cloudwatch
...
spec:
...
env:
- name: RUN_WITH_IRSA # <-- Add this
value: "True" # <-- Add this
- name: K8S_NODE_NAME
valueFrom:
fieldRef:
fieldPath: spec.nodeName
...
```
## (Facultatif) Configuration supplémentaire
**Topics**
+ [
### Désactivation de la collecte des journaux de conteneurs
](#CloudWatch-Observability-EKS-addon-OptOutContainerLogs)
+ [
### Utilisation d’une configuration Fluent Bit personnalisée
](#CloudWatch-Observability-EKS-addon-CustomFluentBit)
+ [
### Gestion des tolérances Kubernetes pour les charges de travail des pods installés
](#CloudWatch-Observability-EKS-addon-Tolerations)
+ [
### Désactivation de la collecte des métriques de calcul accéléré
](#CloudWatch-Observability-EKS-addon-OptOutAccelerated)
+ [
### Utiliser une configuration d' CloudWatch agent personnalisée
](#CloudWatch-Observability-EKS-addon-CustomAgentConfig)
+ [
### Gérer les certificats TLS du webhook d’admission
](#CloudWatch-Observability-EKS-addon-Webhook)
+ [
### Collectez le volume Amazon EBS IDs
](#CloudWatch-Observability-EKS-addon-VolumeIDs)
### Désactivation de la collecte des journaux de conteneurs
Par défaut, le module complémentaire utilise Fluent Bit pour collecter les journaux des conteneurs à partir de tous les pods, puis envoie les CloudWatch journaux à Logs. Pour plus d'informations sur les journaux collectés, veuillez consulter [Configuration de Fluent Bit](Container-Insights-setup-logs-FluentBit.md#Container-Insights-FluentBit-setup).
**Note**
Ni le module complémentaire ni les Charts de Helm ne gèrent les ressources Fluentd ou Fluent Bit déjà existantes dans un cluster. Vous pouvez supprimer les ressources Fluentd ou Fluent Bit existantes avant d’installer le module complémentaire ou les Charts de Helm. Sinon, pour conserver votre configuration existante et éviter que le module complémentaire ou les Charts de Helm n’installent également Fluent Bit, vous pouvez le désactiver en suivant les instructions de cette section.
Pour refuser la collecte des journaux de conteneurs si vous utilisez le module complémentaire Amazon CloudWatch Observability EKS, passez l'option suivante lorsque vous créez ou mettez à jour le module complémentaire :
```
--configuration-values '{ "containerLogs": { "enabled": false } }'
```
Pour désactiver la collecte des journaux de conteneurs lorsque vous utilisez les Charts de Helm, ajoutez l’option suivante lors de la création ou de la mise à jour du module complémentaire :
```
--set containerLogs.enabled=false
```
### Utilisation d’une configuration Fluent Bit personnalisée
À partir de la version 1.7.0 du module complémentaire Amazon CloudWatch Observability EKS, vous pouvez modifier la configuration de Fluent Bit lorsque vous créez ou mettez à jour le module complémentaire ou le graphique Helm. Vous devez fournir votre configuration personnalisée de Fluent Bit dans la section racine `containerLogs` de la configuration avancée du module complémentaire, ou dans les valeurs de substitution des Charts de Helm. Dans cette section, la configuration personnalisée de Fluent Bit doit être placée dans la section `config` (pour Linux) ou dans la section `configWindows` (pour Windows). La `config` est ensuite décomposée dans les sous-sections suivantes :
+ `service` : cette section représente la configuration `SERVICE` permettant de définir le comportement global du moteur Fluent Bit.
+ `customParsers` : cette section regroupe les `PARSER` globaux que vous souhaitez inclure, qui permettent de convertir des entrées de journaux non structurées en un format structuré, afin de faciliter leur traitement et leur filtrage.
+ `extraFiles` : cette section permet d’ajouter des fichiers `conf` supplémentaires à inclure dans Fluent Bit. Par défaut, les trois fichiers `conf` suivants sont inclus :.
+ `application-log.conf`— Un `conf` fichier permettant d'envoyer les journaux d'applications de votre cluster au groupe de CloudWatch journaux `/aws/containerinsights/my-cluster-name/application` dans Logs.
+ `dataplane-log.conf`— Un `conf` fichier permettant d'envoyer les journaux correspondant aux composants du plan de données de votre cluster, notamment les journaux CRI, les journaux kubelet, les journaux kube-proxy et les journaux Amazon VPC CNI, au groupe de journaux dans Logs. `/aws/containerinsights/my-cluster-name/dataplane` CloudWatch
+ `host-log.conf`— A `conf` pour envoyer des journaux depuis `/var/log/dmesg``/var/log/messages`, et `/var/log/secure` sous Linux, et System `winlogs` sous Windows, `/aws/containerinsights/my-cluster-name/host` au groupe de journaux CloudWatch.
**Note**
Fournissez la configuration complète pour chacune de ces sections individuelles, même si vous ne modifiez qu’un seul champ dans une sous-section. Nous vous recommandons d’utiliser la configuration par défaut ci-dessous comme base de référence, puis de la modifier selon vos besoins afin de ne pas désactiver de fonctionnalités activées par défaut. Vous pouvez utiliser la configuration YAML suivante pour modifier la configuration avancée du module complémentaire Amazon EKS ou pour fournir des valeurs de substitution lors de l’installation via les Charts de Helm.
Pour trouver la `config` section correspondant à votre cluster, consultez [aws-observability/helm-charts](https://github.com/aws-observability/helm-charts/releases) on GitHub et recherchez la version correspondant à la version du module complémentaire ou du graphique Helm que vous installez. Naviguez ensuite vers `/charts/amazon-cloudwatch-observability/values.yaml` pour trouver la section `config` (pour Linux) et la section `configWindows` (pour Windows) dans la section `fluentBit` sous `containerLogs`.
À titre d’exemple, la configuration Fluent Bit par défaut pour la version 1.7.0 est disponible [ici](https://github.com/aws-observability/helm-charts/blob/v1.7.0/charts/amazon-cloudwatch-observability/values.yaml#L44)).
Nous vous recommandons de fournir la `config` en format YAML, que ce soit via la configuration avancée du module complémentaire Amazon EKS ou les valeurs de substitution de votre installation Helm. Assurez-vous que le format YAML respecte la structure suivante.
```
containerLogs:
fluentBit:
config:
service: |
...
customParsers: |
...
extraFiles:
application-log.conf: |
...
dataplane-log.conf: |
...
host-log.conf: |
...
```
L’exemple `config` suivant modifie le paramètre global de l’intervalle de vidange à 45 secondes. Même si la seule modification concerne le champ `Flush`, vous devez fournir la définition `SERVICE` complète de la sous-section service. Comme cet exemple ne définit pas de valeurs de substitution pour les autres sous-sections, les valeurs par défaut sont utilisées pour celles-ci.
```
containerLogs:
fluentBit:
config:
service: |
[SERVICE]
Flush 45
Grace 30
Log_Level error
Daemon off
Parsers_File parsers.conf
storage.path /var/fluent-bit/state/flb-storage/
storage.sync normal
storage.checksum off
storage.backlog.mem_limit 5M
```
L’exemple de configuration suivant inclut un fichier `conf` Fluent Bit supplémentaire. Dans cet exemple, nous ajoutons une `my-service.conf` personnalisée sous `extraFiles` qui sera incluse en plus des trois `extraFiles` par défaut.
```
containerLogs:
fluentBit:
config:
extraFiles:
my-service.conf: |
[INPUT]
Name tail
Tag myservice.*
Path /var/log/containers/*myservice*.log
DB /var/fluent-bit/state/flb_myservice.db
Mem_Buf_Limit 5MB
Skip_Long_Lines On
Ignore_Older 1d
Refresh_Interval 10
[OUTPUT]
Name cloudwatch_logs
Match myservice.*
region ${AWS_REGION}
log_group_name /aws/containerinsights/${CLUSTER_NAME}/myservice
log_stream_prefix ${HOST_NAME}-
auto_create_group true
```
L’exemple suivant supprime entièrement un fichier `conf` existant de `extraFiles`. Cela exclut complètement la `application-log.conf` en la remplaçant par une chaîne vide. Le simple fait d’omettre `application-log.conf` de `extraFiles` impliquerait plutôt d’utiliser la valeur par défaut, ce que nous n’essayons pas de réaliser dans cet exemple. Il en va de même pour la suppression de tout fichier `conf` personnalisé que vous auriez pu ajouter précédemment aux `extraFiles`.
```
containerLogs:
fluentBit:
config:
extraFiles:
application-log.conf: ""
```
### Gestion des tolérances Kubernetes pour les charges de travail des pods installés
À partir de la version 1.7.0 du module complémentaire Amazon CloudWatch Observability EKS, le module complémentaire et le graphique Helm définissent par défaut des *tolérances Kubernetes afin de tolérer toutes les altérations des* charges de travail du pod installées par le module complémentaire ou le graphique Helm. Cela garantit que les daemonsets tels que l' CloudWatch agent et Fluent Bit peuvent planifier des pods sur tous les nœuds de votre cluster par défaut. Pour plus d’informations sur les tolérances et les rejets, consultez [Rejets et tolérances](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) dans la documentation de Kubernetes.
Les tolérances par défaut définies par le module complémentaire ou les Charts de Helm sont les suivantes :
```
tolerations:
- operator: Exists
```
Vous pouvez remplacer ces tolérances par défaut en définissant le champ `tolerations` à la racine de la configuration avancée du module complémentaire ou lors de l’installation ou la mise à jour des Charts de Helm avec des valeurs de substitution. Par exemple :
```
tolerations:
- key: "key1"
operator: "Exists"
effect: "NoSchedule"
```
Pour omettre complètement les tolérances, vous pouvez utiliser une configuration de ce type :
```
tolerations: []
```
Toute modification des tolérances s’applique à toutes les charges de travail des pods installées par le module complémentaire ou les Charts de Helm.
### Désactivation de la collecte des métriques de calcul accéléré
Par défaut, Container Insights, doté d'une observabilité améliorée, collecte des métriques pour la surveillance accélérée du calcul, notamment les métriques du GPU NVIDIA, les métriques AWS Neuron pour AWS Trainium et AWS Inferentia, et les métriques AWS Elastic Fabric Adapter (EFA).
Les métriques du GPU NVIDIA issues des charges de travail Amazon EKS sont collectées par défaut en commençant par la version `v1.3.0-eksbuild.1` du module complémentaire EKS ou le graphique Helm et la version `1.300034.0` de l' CloudWatch agent. Pour la liste des métriques collectées et les prérequis, consultez [Métriques des GPU NVIDIA](Container-Insights-metrics-enhanced-EKS.md#Container-Insights-metrics-EKS-GPU).
AWS Les métriques neuronales pour les accélérateurs AWS Trainium et AWS Inferentia sont collectées par défaut à partir de la version `v1.5.0-eksbuild.1` du module complémentaire EKS ou du graphique Helm et de la version `1.300036.0` de l'agent. CloudWatch Pour la liste des métriques collectées et les prérequis, consultez [AWS Métriques neuronales pour AWS Trainium et Inferentia AWS](Container-Insights-metrics-enhanced-EKS.md#Container-Insights-metrics-EKS-Neuron).
AWS Les métriques Elastic Fabric Adapter (EFA) issues des nœuds Linux des clusters Amazon EKS sont collectées par défaut en commençant par la `v1.5.2-eksbuild.1` version du module complémentaire EKS ou le graphique Helm et la `1.300037.0` version de CloudWatch l'agent. Pour la liste des métriques collectées et les prérequis, consultez [AWS Métriques de l'Elastic Fabric Adapter (EFA)](Container-Insights-metrics-enhanced-EKS.md#Container-Insights-metrics-EFA).
Vous pouvez choisir de ne pas collecter ces métriques en définissant le `accelerated_compute_metrics` champ du fichier de configuration de l' CloudWatch agent sur`false`. Ce champ se trouve dans la `kubernetes` section de la `metrics_collected` section du fichier CloudWatch de configuration. Voici un exemple de configuration avec désactivation. Pour plus d'informations sur l'utilisation des configurations d' CloudWatch agent personnalisées, consultez la section suivante,[Utiliser une configuration d' CloudWatch agent personnalisée](#CloudWatch-Observability-EKS-addon-CustomAgentConfig).
```
{
"logs": {
"metrics_collected": {
"kubernetes": {
"enhanced_container_insights": true,
"accelerated_compute_metrics": false
}
}
}
}
```
### Utiliser une configuration d' CloudWatch agent personnalisée
Pour collecter d'autres métriques, journaux ou traces à l'aide de l' CloudWatch agent, vous pouvez définir une configuration personnalisée tout en gardant Container Insights et CloudWatch Application Signals activés. Pour ce faire, intégrez le fichier de configuration de l' CloudWatch agent dans la clé de configuration située sous la clé d'agent de la configuration avancée que vous pouvez utiliser lors de la création ou de la mise à jour du module complémentaire EKS ou du graphique Helm. Ce qui suit représente la configuration par défaut de l’agent lorsque vous ne fournissez aucune configuration supplémentaire.
**Important**
Toute configuration personnalisée que vous fournissez à l’aide de paramètres de configuration supplémentaires remplace la configuration par défaut utilisée par l’agent. Veillez à ne pas désactiver involontairement les fonctionnalités activées par défaut, telles que Container Insights avec une observabilité améliorée et les signaux d' CloudWatch application. Dans le cas où vous devez fournir une configuration d’agent personnalisée, nous vous recommandons d’utiliser la configuration par défaut suivante comme référence, puis de la modifier en conséquence.
+ Pour utiliser le module complémentaire Amazon CloudWatch observability EKS
```
--configuration-values '{
"agent": {
"config": {
"logs": {
"metrics_collected": {
"application_signals": {},
"kubernetes": {
"enhanced_container_insights": true
}
}
},
"traces": {
"traces_collected": {
"application_signals": {}
}
}
}
}
}'
```
+ Example pour les Charts de Helm
```
--set agent.config='{
"logs": {
"metrics_collected": {
"application_signals": {},
"kubernetes": {
"enhanced_container_insights": true
}
}
},
"traces": {
"traces_collected": {
"application_signals": {}
}
}
}'
```
L'exemple suivant montre la configuration par défaut de l' CloudWatch agent sous Windows. L' CloudWatch agent sous Windows ne prend pas en charge la configuration personnalisée.
```
{
"logs": {
"metrics_collected": {
"kubernetes": {
"enhanced_container_insights": true
},
}
}
}
```
### Gérer les certificats TLS du webhook d’admission
Le module complémentaire Amazon CloudWatch Observability EKS et le graphique Helm exploitent les [webhooks d'admission](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) Kubernetes pour valider et muter les demandes de ressources `Instrumentation` personnalisées (CR), `AmazonCloudWatchAgent` et éventuellement les requêtes de pod Kubernetes sur le cluster si Application Signals est activé. CloudWatch Dans Kubernetes, les webhooks nécessitent que le serveur d’API soit configuré pour faire confiance à un certificat TLS afin de garantir une communication sécurisée.
Par défaut, le module complémentaire Amazon CloudWatch Observability EKS et le graphique Helm génèrent automatiquement une autorité de certification auto-signée et un certificat TLS signé par cette autorité de certification afin de sécuriser la communication entre le serveur d'API et le serveur Webhook. Ce certificat généré automatiquement a une durée de validité par défaut de 10 ans et n’est pas renouvelé automatiquement à l’expiration. De plus, le paquet CA et le certificat sont régénérés chaque fois que le module complémentaire ou les Charts de Helm sont mis à jour ou réinstallés, ce qui réinitialise la date d’expiration. Si vous souhaitez modifier la durée de validité par défaut du certificat généré automatiquement, vous pouvez utiliser les configurations supplémentaires suivantes lors de la création ou de la mise à jour du module complémentaire. *expiry-in-days*Remplacez-le par la durée de péremption souhaitée en jours.
+ Utilisez-le pour le module complémentaire Amazon CloudWatch Observability EKS
```
--configuration-values '{ "admissionWebhooks": { "autoGenerateCert": { "expiryDays": expiry-in-days } } }'
```
+ Utilisation pour les Charts de Helm
```
--set admissionWebhooks.autoGenerateCert.expiryDays=expiry-in-days
```
Pour une solution d’autorité de certification plus sécurisée et riche en fonctionnalités, le module complémentaire prend en charge [cert-manager](https://cert-manager.io/docs/), une solution largement adoptée pour la gestion des certificats TLS dans Kubernetes qui simplifie le processus d’obtention, de renouvellement, de gestion et d’utilisation de ces certificats. Il garantit que les certificats sont valides et à jour, et tente de renouveler les certificats à une heure configurée avant leur expiration. cert-manager facilite également l’émission de certificats provenant de diverses sources prises en charge, y compris l’autorité de [AWS Certificate Manager Private Certificate Authority](https://aws.amazon.com/private-ca/).
Nous vous recommandons de consulter les bonnes pratiques en matière de gestion des certificats TLS sur vos clusters et d’opter pour cert-manager pour les environnements de production. Notez que si vous acceptez d'activer cert-manager pour gérer les certificats TLS du webhook d'admission, vous devez préinstaller cert-manager sur votre cluster Amazon EKS avant d'installer le module complémentaire Amazon Observability EKS ou le graphique Helm CloudWatch . Pour plus d’informations sur les options d’installation disponibles, consultez la [documentation cert-manager](https://cert-manager.io/docs/installation/). Après l’avoir installé, vous pouvez activer son utilisation pour gérer les certificats TLS des webhooks d’admission à l’aide de la configuration supplémentaire suivante.
+ Si vous utilisez le module complémentaire Amazon CloudWatch Observability EKS
```
--configuration-values '{ "admissionWebhooks": { "certManager": { "enabled": true } } }'
```
+ Si vous utilisez les Charts de Helm
```
--set admissionWebhooks.certManager.enabled=true
```
```
--configuration-values '{ "admissionWebhooks": { "certManager": { "enabled": true } } }'
```
La configuration avancée décrite dans cette section utilisera par défaut un [ SelfSigned](https://cert-manager.io/docs/configuration/selfsigned/)émetteur.
### Collectez le volume Amazon EBS IDs
Si vous souhaitez collecter le volume Amazon EBS IDs dans les journaux de performance, vous devez ajouter une autre politique au rôle IAM qui est attaché aux nœuds de travail ou au compte de service. Ajoutez les éléments suivants en tant que politique en ligne. Pour de plus amples informations, veuillez consulter [Ajout et suppression d'autorisations basées sur l'identité IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ec2:DescribeVolumes"
],
"Resource": "*",
"Effect": "Allow"
}
]
}
```
------
## Collecte des métriques Java Management Extensions (JMX)
L' CloudWatch agent prend en charge la collecte de métriques Java Management Extensions (JMX) sur Amazon EKS. Cela vous permet de collecter des métriques supplémentaires provenant d’applications Java exécutées sur des clusters Amazon EKS, offrant ainsi une meilleure visibilité sur les performances, l’utilisation de la mémoire, le trafic et d’autres métriques essentielles. Pour de plus amples informations, veuillez consulter [Collecte des métriques Java Management Extensions (JMX)](CloudWatch-Agent-JMX-metrics.md).
## Activation des métriques Kueue
À partir de la version `v2.4.0-eksbuild.1` du module complémentaire CloudWatch Observability EKS, Container Insights for Amazon EKS prend en charge la collecte de métriques Kueue à partir de clusters Amazon EKS. Pour plus d’informations sur ces métriques, consultez [Métriques Kueue](Container-Insights-metrics-EKS.md#Container-Insights-metrics-Kueue).
Si vous utilisez le module complémentaire Amazon SageMaker AI Hyperpod Task Governance EKS, vous pouvez ignorer les étapes de la section **Prérequis** et simplement suivre les étapes décrites. [Activation de l’indicateur de configuration](#enable-Kueue-metrics-flag)
### Conditions préalables
Avant d’installer Kueue dans votre cluster Amazon EKS, effectuez les mises à jour suivantes dans le fichier manifeste :
1. Activez les métriques facultatives de ressources de file d’attente de cluster pour Kueue. Pour ce faire, modifiez le texte en ligne `controller_manager_config.yaml` dans le `kueue-system` ConfigMap. Dans la section `metrics`, ajoutez ou décommentez la ligne `enableClusterQueueResources: true`.
```
apiVersion: v1
data:
controller_manager_config.yaml: |
apiVersion: config.kueue.x-k8s.io/v1beta1
kind: Configuration
health:
healthProbeBindAddress: :8081
metrics:
bindAddress: :8080
enableClusterQueueResources: true <-- ADD/UNCOMMENT THIS LINE
```
1. Par défaut, tous les services `k8s` sont disponibles à l’échelle du cluster. Kueue crée un service `kueue-controller-manager-metrics-service` pour exposer les métriques. Pour éviter les observations en double, il est recommandé de modifier ce service afin de limiter l’accès aux métriques au service exécuté sur le même nœud uniquement. Pour ce faire, ajoutez la ligne `internalTrafficPolicy: Local` à la définition `kueue-controller-manager-metrics-service`.
```
apiVersion: v1
kind: Service
metadata:
labels:
...
name: kueue-controller-manager-metrics-service
namespace: kueue-system
spec:
ports:
- name: https
port: 8443
protocol: TCP
targetPort: https
internalTrafficPolicy: Local <-- ADD THIS LINE
selector:
control-plane: controller-manager
```
1. Enfin, le pod `kueue-controller-manager` crée un conteneur `kube-rbac-proxy`. Ce conteneur présente actuellement un niveau élevé de verbosité de journalisation, ce qui a pour effet d’enregistrer le jeton d’accès du cluster lorsque le collecteur de métriques accède à `kueue-controller-manager-metrics-service`. Nous vous recommandons de réduire cette verbosité de journalisation. La valeur par défaut du manifeste distribué par Kueue est 10, et nous vous recommandons de la remplacer par 0.
```
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
...
name: kueue-controller-manager
namespace: kueue-system
spec:
...
template:
...
spec:
containers:
...
- args:
- --secure-listen-address=0.0.0.0:8443
- --upstream=http://127.0.0.1:8080/
- --logtostderr=true
- --v=0 <-- CHANGE v=10 TO v=0
image: gcr.io/kubebuilder/kube-rbac-proxy:v0.8.0
name: kube-rbac-proxy
...
```
### Activation de l’indicateur de configuration
Pour activer les métriques Kueue, vous devez activer la configuration supplémentaire `kueue_container_insights` dans le module complémentaire. Vous pouvez le faire soit en utilisant le module complémentaire EKS Observability AWS CLI pour configurer, soit en utilisant la console Amazon EKS.
Après avoir correctement installé le module complémentaire EKS Observability à l'aide de l'une des méthodes suivantes, vous pouvez consulter les métriques de votre cluster Amazon EKS sous l'onglet **Tableau de bord** de la HyperPod console.
------
#### [ AWS CLI ]
**Pour activer les métriques Kueue à l'aide du AWS CLI**
+ Entrez la AWS CLI commande suivante pour installer le module complémentaire.
```
aws eks create-addon --cluster-name cluster-name --addon-name amazon-cloudwatch-observability --configuration-values "configuration_json_file"
```
Voici un exemple de fichier JSON contenant les valeurs de configuration.
```
{
"agent": {
"config": {
"logs": {
"metrics_collected": {
"kubernetes": {
"kueue_container_insights": true,
"enhanced_container_insights": true
},
"application_signals": { }
}
},
"traces": {
"traces_collected": {
"application_signals": { }
}
}
},
},
}
```
------
#### [ Amazon EKS console ]
**Pour activer les métriques Kueue à l’aide de la console Amazon EKS**
1. Ouvrez la console Amazon EKS à l'adresse [https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters).
1. Choisissez le nom de votre cluster.
1. Choisissez **Modules complémentaires**.
1. Recherchez le module complémentaire **Amazon CloudWatch Observability** dans la liste et installez-le. Lors de l’installation, choisissez **Configuration facultative** et incluez les valeurs de configuration JSON suivantes.
```
{
"agent": {
"config": {
"logs": {
"metrics_collected": {
"kubernetes": {
"kueue_container_insights": true,
"enhanced_container_insights": true
},
"application_signals": { }
}
},
"traces": {
"traces_collected": {
"application_signals": { }
}
}
},
},
}
```
------
## Ajout de fichiers de configuration du OpenTelemetry collecteur
L' CloudWatch agent prend en charge les fichiers de configuration de OpenTelemetry collecteurs supplémentaires en plus de ses propres fichiers de configuration. Cette fonctionnalité vous permet d'utiliser des fonctionnalités d' CloudWatch agent telles que CloudWatch Application Signals ou Container Insights dans le cadre de la configuration de l' CloudWatch agent et d'intégrer votre configuration de OpenTelemetry collecteur existante avec un seul agent.
Pour éviter les conflits de fusion avec les pipelines créés automatiquement par CloudWatch l'agent, nous vous recommandons d'ajouter un suffixe personnalisé à chacun des composants et pipelines de la configuration de votre OpenTelemetry collecteur. Cela permettra d’éviter les collisions et les conflits de fusion.
+ Si vous utilisez le module complémentaire Amazon CloudWatch Observability EKS
```
--configuration-values file://values.yaml
```
or
```
--configuration-values '
agent:
otelConfig:
receivers:
otlp/custom-suffix:
protocols:
http: {}
exporters:
awscloudwatchlogs/custom-suffix:
log_group_name: "test-group"
log_stream_name: "test-stream"
service:
pipelines:
logs/custom-suffix:
receivers: [otlp/custom-suffix]
exporters: [awscloudwatchlogs/custom-suffix]
'
```
+ Si vous utilisez les Charts de Helm
```
--set agent.otelConfig='
receivers:
otlp/custom-suffix:
protocols:
http: {}
exporters:
awscloudwatchlogs/custom-suffix:
log_group_name: "test-group"
log_stream_name: "test-stream"
service:
pipelines:
logs/custom-suffix:
receivers: [otlp/custom-suffix]
exporters: [awscloudwatchlogs/custom-suffix]
'
```
## Activation de l'APM via des signaux d'application pour votre cluster Amazon EKS
Par défaut, la surveillance des performances des applications OpenTelemetry (APM) basée sur (OTEL) est activée via les signaux d'application lors de l'installation du module complémentaire CloudWatch Observability EKS (V5.0.0 ou supérieur) ou du graphique Helm. Vous pouvez ensuite personnaliser certains paramètres spécifiques à l’aide de la configuration avancée du module complémentaire Amazon EKS ou en remplaçant certaines valeurs dans les Charts de Helm.
**Note**
Si vous utilisez une solution APM basée sur OpenTelemetry (OTEL), l'activation des signaux d'application affecte votre configuration d'observabilité existante. Passez en revue votre implémentation actuelle avant de continuer. Pour conserver votre configuration APM existante après la mise à niveau vers la version 5.0.0 ou ultérieure, consultez. [Désactiver les signaux d'application](#Opting-out-App-Signals)
**Surveillance automatique avec la vigie applicative**
La version 5.0.0 du module complémentaire CloudWatch Observability Amazon EKS et du graphique Helm introduit de nouvelles fonctionnalités. Vous pouvez désormais activer automatiquement la vigie applicative pour tous les services, ou uniquement pour certains charges de travail spécifiques de votre cluster EKS, en configurant la surveillance automatique. Les paramètres `autoMonitor` suivants peuvent être spécifiés dans la section `applicationSignals`, située sous la section `manager` de la configuration avancée.
+ *monitorAllServices*— Un indicateur booléen permettant d'activer (vrai) ou de désactiver (faux) la surveillance de toutes les charges de travail des services par Auto Monitor. La valeur par défaut est true (vrai). L'activation de cet indicateur garantit que toutes les charges de travail Kubernetes (déploiements DaemonSets, et StatefulSets) du cluster mappées à un service Kubernetes seront autorisées à activer automatiquement les signaux d'application lorsqu'ils seront affichés pour la première fois (ou lors du redémarrage pour les charges de travail existantes). Le système exclut par défaut les charges de travail dans les espaces de noms `kube-system` et `amazon-cloudwatch`.
+ *languages* : une liste de chaînes indiquant les langages de programmation que la vigie applicative doit tenter d’instrumenter automatiquement pour vos services lorsque `monitorAllServices` est activée. Valeur par défaut : tous les [langages pris en charge](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Monitoring-Sections.html).
+ *restartPods* : un indicateur booléen contrôlant le redémarrage automatique des charges de travail après une modification de la configuration. La valeur par défaut est false. Si vous activez cet indicateur en le définissant sur `true`, les charges de travail Kubernetes incluses dans la portée de la surveillance automatique seront redémarrées automatiquement lorsque vous enregistrez des modifications de configuration. Les paramètres existants dans vos charges de travail Kubernetes susceptibles d’influencer le redémarrage des pods, par exemple `updateStrategy`, seront pris en compte. Tenez compte du fait que le redémarrage peut entraîner une certaine durée d’indisponibilité du service.
+ *customSelector* : paramètres permettant de sélectionner des espaces de noms ou des charges de travail Kubernetes spécifiques pour la surveillance automatique.
+ *java* : permet de spécifier les charges de travail à instrumenter automatiquement avec Java
+ *python* : permet de spécifier les charges de travail à instrumenter automatiquement avec Python
+ *nodejs* : permet de spécifier les charges de travail à instrumenter automatiquement avec Node.js
+ *dotnet* : permet de spécifier les charges de travail à instrumenter automatiquement avec .NET
Pour chacune des langages ci-dessus, les champs suivants peuvent être configurés.
+ *namespaces* : liste des chaînes indiquant les espaces de noms à inclure. Par défaut, cette liste est vide, c’est-à-dire []
+ *deployments* : liste des chaînes spécifiant les déploiements à sélectionner. Spécifiez-les au format `namespace/deployment`. Par défaut, cette liste est vide, c’est-à-dire []
+ *daemonsets* : liste des chaînes spécifiant les daemonsets à sélectionner. Spécifiez-les au format `namespace/daemonset`. Par défaut, cette liste est vide, c’est-à-dire []
+ *statefulsets* : liste des chaînes spécifiant les statefulsets à sélectionner. Spécifiez-les au format `namespace/statefulset`. Par défaut, cette liste est vide, c’est-à-dire []
+ *exclude* : paramètres permettant d’exclure des espaces de noms ou des charges de travail Kubernetes spécifiques de la surveillance automatique. L’exclusion d’une charge de travail a priorité sur l’inclusion de la même charge de travail lorsqu’elle figure dans `monitorAllServices` ou `customSelector`.
+ *java* : permet de spécifier les charges de travail à exclure de l’instrumentation automatique avec Java
+ *python* : permet de spécifier les charges de travail à exclure de l’instrumentation automatique avec Python
+ *nodejs* : permet de spécifier les charges de travail à exclure de l’instrumentation automatique avec Node.js
+ *dotnet* : permet de spécifier les charges de travail à exclure de l’instrumentation automatique avec .NET
Pour chacune des langages ci-dessus, les champs suivants peuvent être configurés.
+ *namespaces* : liste des chaînes indiquant les espaces de noms à exclure. Par défaut, cette liste est vide, c’est-à-dire []
+ *deployments* : liste des chaînes spécifiant les déploiements à exclure. Spécifiez-les au format `namespace/deployment`. Par défaut, cette liste est vide, c’est-à-dire []
+ *daemonsets* : liste des chaînes spécifiant les daemonsets à exclure. Spécifiez-les au format `namespace/daemonset`. Par défaut, cette liste est vide, c’est-à-dire []
+ *statefulsets* : liste des chaînes spécifiant les statefulsets à exclure. Spécifiez-les au format `namespace/statefulset`. Par défaut, cette liste est vide, c’est-à-dire []
L’exemple suivant montre une configuration qui active automatiquement la vigie applicative pour toutes les charges de travail de service existantes et nouvelles dans le cluster.
```
manager:
applicationSignals:
autoMonitor:
monitorAllServices: true
restartPods: true
```
L’exemple suivant montre une configuration qui active automatiquement la vigie applicative pour toute nouvelle charge de travail de service créée, ainsi que pour toute charge de travail de service existante explicitement redémarrée dans le cluster.
```
manager:
applicationSignals:
autoMonitor:
monitorAllServices: true
```
L’exemple suivant montre une configuration qui active automatiquement la vigie applicative avec Java pour tous les pods existants et nouveaux correspondant à une charge de travail située dans l’espace de noms `pet-warehouse`.
```
manager:
applicationSignals:
autoMonitor:
restartPods: true
customSelector:
java:
namespaces: ["pet-warehouse"]
```
L’exemple suivant montre une configuration qui active automatiquement la vigie applicative avec Python pour toutes les charges de travail de service existantes et nouvelles dans le cluster, sauf pour le déploiement `pet-clinic`.
```
manager:
applicationSignals:
autoMonitor:
monitorAllServices: true
languages: ["python"]
restartPods: true
exclude:
python:
deployments: ["pet-warehouse/pet-clinic"]
```
L’exemple suivant montre une configuration qui active automatiquement la vigie applicative avec Java pour toutes les charges de travail de service du cluster, à l’exception de celles situées dans l’espace de noms `python-apps`, et qui active la vigie applicative avec Python uniquement pour le déploiement `sample-python-app` dans ce même espace de noms `python-apps`.
```
manager:
applicationSignals:
autoMonitor:
monitorAllServices: true
languages: ["java"]
restartPods: true
customSelector:
python:
deployments: ["python-apps/sample-python-app"]
exclude:
java:
namespaces: ["python-apps"]
```
## Résolution des problèmes liés au module complémentaire Amazon CloudWatch Observability EKS ou au graphique Helm
Utilisez les informations suivantes pour résoudre les problèmes liés au module complémentaire Amazon CloudWatch Observability EKS ou au graphique Helm
**Topics**
+ [
### Mise à jour et suppression du module complémentaire Amazon CloudWatch Observability EKS ou du graphique Helm
](#EKS-addon-troubleshoot-update)
+ [
### Vérifiez la version de l' CloudWatch agent utilisée par le module complémentaire Amazon CloudWatch Observability EKS ou le graphique Helm
](#EKS-addon-troubleshoot-version)
+ [
### Manipulation d'un ConfigurationConflict lors de la gestion du module complémentaire ou du graphique Helm
](#EKS-addon-troubleshoot-conflict)
### Mise à jour et suppression du module complémentaire Amazon CloudWatch Observability EKS ou du graphique Helm
Pour obtenir des instructions sur la mise à jour ou la suppression du module complémentaire Amazon CloudWatch Observability EKS, consultez [la section Gestion des modules complémentaires Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/managing-add-ons.html). Utilisez `amazon-cloudwatch-observability` comme nom du module complémentaire.
Pour supprimer les Charts de Helm d’un cluster, saisissez la commande suivante.
```
helm delete amazon-cloudwatch-observability -n amazon-cloudwatch --wait
```
### Vérifiez la version de l' CloudWatch agent utilisée par le module complémentaire Amazon CloudWatch Observability EKS ou le graphique Helm
Le module complémentaire Amazon CloudWatch Observability EKS et le graphique Helm installent une ressource personnalisée `AmazonCloudWatchAgent` qui contrôle le comportement du daemonset de l' CloudWatch agent sur le cluster, y compris la version de l' CloudWatch agent utilisée. Vous pouvez obtenir la liste de toutes les ressources `AmazonCloudWatchAgent` personnalisées installées sur votre cluster en saisissant la commande suivante :
```
kubectl get amazoncloudwatchagent -A
```
Dans le résultat de cette commande, vous devriez être en mesure de vérifier la version de l' CloudWatchagent. Vous pouvez également décrire la ressource `amazoncloudwatchagent` ou l’un des pods `cloudwatch-agent-*` exécutés sur votre cluster pour inspecter l’image utilisée.
### Manipulation d'un ConfigurationConflict lors de la gestion du module complémentaire ou du graphique Helm
Lorsque vous installez ou mettez à jour le module complémentaire Amazon CloudWatch Observability EKS ou le graphique Helm, si vous remarquez une défaillance due à des ressources existantes, c'est probablement parce que vous avez déjà ClusterRoleBinding installé l' CloudWatch agent et ses composants associés tels que le ServiceAccount, le ClusterRole et le sur le cluster.
L’erreur affichée par le module complémentaire inclura `Conflicts found when trying to apply. Will not continue due to resolve conflicts mode`,
L’erreur affichée par les Charts de Helm sera similaire à `Error: INSTALLATION FAILED: Unable to continue with install and invalid ownership metadata.`.
Lorsque le module complémentaire ou le graphique Helm tente d'installer l' CloudWatch agent et ses composants associés, s'il détecte une modification du contenu, il échoue par défaut à l'installation ou à la mise à jour afin d'éviter de modifier l'état des ressources du cluster.
Si vous essayez d'intégrer le module complémentaire Amazon CloudWatch Observability EKS et que vous constatez cet échec, nous vous recommandons de supprimer une configuration d' CloudWatch agent existante que vous aviez précédemment installée sur le cluster, puis d'installer le module complémentaire EKS ou le graphique Helm. Veillez à sauvegarder toutes les personnalisations que vous avez éventuellement apportées à la configuration d'origine de l' CloudWatch agent, telle qu'une configuration d'agent personnalisée, et à les fournir au module complémentaire ou au tableau Helm lors de sa prochaine installation ou mise à jour. Si vous avez déjà installé l' CloudWatch agent pour l'intégration à Container Insights, consultez [Suppression de l' CloudWatch agent et de Fluent Bit for Container Insights](ContainerInsights-delete-agent.md) pour plus d'informations.
Le module complémentaire prend également en charge une option de configuration de résolution des conflits capable de spécifier `OVERWRITE`. Vous pouvez utiliser cette option pour procéder à l’installation ou à la mise à jour du module complémentaire en remplaçant les conflits sur le cluster. Si vous utilisez la console Amazon EKS, vous trouverez la **Méthode de résolution des conflits** lorsque vous choisissez les **Paramètres de configuration facultatifs** lorsque vous créez ou mettez à jour le module complémentaire. Si vous utilisez le AWS CLI, vous pouvez fournir le `--resolve-conflicts OVERWRITE` à votre commande pour créer ou mettre à jour le module complémentaire.
## Désactiver les signaux d'application
Ajustez vos préférences de surveillance des services dans la CloudWatch console ou avec le SDK.
Pour les versions antérieures à la version 5.0.0, pour désactiver la surveillance automatique des signaux d'application, suivez la procédure ci-dessous :
**Utilisation de la CLI ou du SDK**
La configuration suivante peut être appliquée soit en tant que configuration avancée au module complémentaire EKS, soit en tant que remplacement de valeurs lors de l'utilisation du diagramme de barre.
```
{
"manager": {
"applicationSignals": {
"autoMonitor": {
"monitorAllServices": false
}
}
}
}
```
Redémarrez vos services pour que les modifications prennent effet.
**Utilisation de la console**
Ouvrez la CloudWatch console à l'adresse [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Dans le volet de navigation, sous **Application Signals (APM)**, sélectionnez **Services**.
1. Choisissez **Enable Application Signals** pour afficher la page d'activation.
1. Décochez la case **Surveillance automatique** pour chaque service que vous ne souhaitez pas surveiller.
1. Redémarrez vos services pour que les modifications prennent effet.