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.

# Configuration de l' CloudWatch agent pour les instances EC2 et les serveurs sur site
<a name="configure-cloudwatch-ec2-on-premises"></a>

De nombreuses entreprises exécutent des charges de travail à la fois sur des serveurs physiques et des machines virtuelles (VMs). Ces charges de travail s'exécutent généralement sur des serveurs différents, chacun OSs ayant des exigences d'installation et de configuration uniques pour la capture et l'ingestion de métriques. 

Si vous choisissez d'utiliser des instances EC2, vous pouvez avoir un haut niveau de contrôle sur la configuration de votre instance et de votre système d'exploitation. Toutefois, ce niveau supérieur de contrôle et de responsabilité vous oblige à surveiller et à ajuster les configurations pour une utilisation plus efficace. Vous pouvez améliorer votre efficacité opérationnelle en établissant des normes de journalisation et de surveillance, et en appliquant une approche d'installation et de configuration standard pour la capture et l'ingestion des journaux et des métriques. 

Organisations qui migrent ou étendent leurs investissements informatiques vers le AWS cloud peuvent tirer parti CloudWatch d'une solution de journalisation et de surveillance unifiée. CloudWatch la tarification signifie que vous payez progressivement pour les statistiques et les journaux que vous souhaitez capturer. Vous pouvez également capturer des journaux et des métriques pour les serveurs sur site en utilisant un processus d'installation d' CloudWatch agent similaire à celui d'Amazon EC2. 

Avant de commencer l'installation et le déploiement CloudWatch, assurez-vous d'évaluer les configurations de journalisation et de métrique de vos systèmes et applications. Assurez-vous de définir les journaux et les métriques standard que vous devez capturer pour OSs ce que vous souhaitez utiliser. Les journaux et les métriques du système constituent la base et la norme d'une solution de journalisation et de surveillance, car ils sont générés par le système d'exploitation et sont différents pour Linux et Windows. Des métriques et des fichiers journaux importants sont disponibles dans toutes les distributions Linux, en plus de ceux spécifiques à une version ou à une distribution Linux. Cette différence se produit également entre les différentes versions de Windows.

## Configuration de l' CloudWatch agent
<a name="configure-cloudwatch-agent-ec2"></a>

CloudWatch capture les métriques et les journaux pour Amazon EC2 et les serveurs locaux à l'aide d'[CloudWatch agents et de fichiers de configuration d'agents](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html) spécifiques à chaque système d'exploitation. Nous vous recommandons de définir la configuration standard de capture des métriques et des journaux de votre entreprise avant de commencer à installer l' CloudWatch agent à grande échelle dans vos comptes. 

Vous pouvez combiner plusieurs configurations d' CloudWatch agent pour former une configuration d' CloudWatch agent composite. L'une des approches recommandées consiste à définir et à diviser les configurations de vos journaux et métriques au niveau du système et de l'application. Le schéma suivant montre comment plusieurs types CloudWatch de fichiers de configuration répondant à différentes exigences peuvent être combinés pour former une CloudWatch configuration composite :

![\[Les configurations répondant à différentes exigences sont combinées pour former une CloudWatch configuration composite.\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/images/logging-monitoring-image-1.png)


Ces journaux et métriques peuvent également être classés et configurés de manière plus approfondie pour des environnements ou des exigences spécifiques. Par exemple, vous pouvez définir un sous-ensemble plus petit de journaux et de métriques avec une précision moindre pour les environnements de développement non réglementés, et un ensemble plus large et plus complet avec une précision supérieure pour les environnements de production réglementés.

## Configuration de la capture de journaux pour les instances EC2
<a name="log-capture-configuration-ec2"></a>

Par défaut, Amazon EC2 ne surveille ni ne capture les fichiers journaux. Au lieu de cela, les fichiers journaux sont capturés et ingérés dans les CloudWatch journaux par le logiciel CloudWatch agent installé sur votre instance EC2, votre AWS API ou AWS Command Line Interface ()AWS CLI. Nous vous recommandons d'utiliser l' CloudWatch agent pour ingérer les fichiers CloudWatch journaux dans Logs for Amazon EC2 et sur site. 

Vous pouvez rechercher et filtrer les journaux, extraire des métriques et exécuter l'automatisation en fonction de l'application de correctifs à partir des fichiers journaux. CloudWatch CloudWatch prend en charge les options de syntaxe de filtre et de modèle en texte brut, délimitées par des espaces et au format JSON, les journaux au format JSON offrant la plus grande flexibilité. Pour augmenter les options de filtrage et d'analyse, vous devez utiliser une sortie de journal formatée au lieu du texte brut.

L' CloudWatch agent utilise un fichier de configuration qui définit les journaux et les mesures à envoyer CloudWatch. CloudWatch capture ensuite chaque fichier journal sous forme de [flux de journal](https://docs.aws.amazon.com//AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html) et regroupe ces flux de journaux dans un [groupe de journaux](https://docs.aws.amazon.com//AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html). Cela vous permet d'effectuer des opérations sur les journaux de vos instances EC2, telles que la recherche d'une chaîne correspondante.

Le nom du flux de journaux par défaut est identique à l'ID d'instance EC2 et le nom du groupe de journaux par défaut est le même que le chemin du fichier journal. Le nom du flux de journaux doit être unique au sein du groupe de CloudWatch journaux. Vous pouvez utiliser`instance_id`, `hostname``local_hostname`, ou `ip_address` pour une substitution dynamique dans les noms de flux de journaux et de groupes de journaux, ce qui signifie que vous pouvez utiliser le même fichier de configuration d' CloudWatch agent sur plusieurs instances EC2. 

Le schéma suivant montre la configuration d'un CloudWatch agent pour la capture des journaux. Le groupe de journaux est défini par les fichiers journaux capturés et contient des flux de journaux distincts pour chaque instance EC2, car la `{instance_id}` variable est utilisée pour le nom du flux de journal et les instances EC2 IDs sont uniques.

![\[Configuration d' CloudWatch agent pour la capture des journaux.\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/images/cloudwatch-image-1.png)


Les groupes de journaux définissent la rétention, les balises, la sécurité, les filtres métriques et le champ de recherche des flux de journaux qu'ils contiennent. Le comportement de regroupement par défaut basé sur le nom du fichier journal vous permet de rechercher, de créer des métriques et d'émettre des alarmes sur les données spécifiques à un fichier journal sur les instances EC2 d'un compte et d'une région. Vous devez évaluer s'il est nécessaire d'affiner davantage les groupes de logs. Par exemple, votre compte peut être partagé par plusieurs unités commerciales et avoir différents responsables techniques ou opérationnels. Cela signifie que vous devez affiner davantage le nom du groupe de journaux pour refléter la séparation et la propriété. Cette approche vous permet de concentrer votre analyse et votre résolution des problèmes sur l'instance EC2 appropriée. 

Si plusieurs environnements utilisent un seul compte, vous pouvez séparer la journalisation des charges de travail exécutées dans chaque environnement. Le tableau suivant présente une convention de dénomination des groupes de journaux qui inclut l'unité commerciale, le projet ou l'application et l'environnement.


|  |  | 
| --- |--- |
| Nom du groupe de journaux | /<Business unit>/<Project or application name>/<Environment>/<Log file name> | 
| Nom du flux de log | <EC2 instance ID>  | 

Vous pouvez également regrouper tous les fichiers journaux d'une instance EC2 dans le même groupe de journaux. Cela facilite la recherche et l'analyse dans un ensemble de fichiers journaux pour une seule instance EC2. Cela est utile si la plupart de vos instances EC2 desservent une application ou une charge de travail et que chaque instance EC2 répond à un objectif spécifique. Le tableau suivant montre comment le nom de votre groupe de journaux et de votre flux de journaux peut être formaté pour prendre en charge cette approche.


|  |  | 
| --- |--- |
| Nom du groupe de journaux | /<Business unit>/<Project or application name>/<Environment>/<EC2 instance ID> | 
| Nom du flux de log | <Log file name> | 

## Configuration de la capture des métriques pour les instances EC2
<a name="metrics-configuration-ec2"></a>

Par défaut, vos instances EC2 sont activées pour la surveillance de base et un [ensemble standard de mesures](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html) (par exemple, des mesures relatives au processeur, au réseau ou au stockage) est automatiquement envoyé CloudWatch toutes les cinq minutes. CloudWatch les métriques peuvent varier en fonction de la famille d'instances. Par exemple, les [instances de performance burstable](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/burstable-performance-instances.html) disposent de métriques pour les crédits CPU. Les métriques standard Amazon EC2 sont incluses dans le prix de votre instance. Si vous activez la [surveillance détaillée de](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/using-cloudwatch-new.html) vos instances EC2, vous pouvez recevoir des données par périodes d'une minute. La fréquence des périodes a un impact sur vos CloudWatch coûts. Assurez-vous donc d'évaluer si une surveillance détaillée est requise pour toutes vos instances EC2 ou uniquement pour certaines d'entre elles. Par exemple, vous pouvez activer la surveillance détaillée des charges de travail de production, mais utiliser la surveillance de base pour les charges de travail hors production. 

Les serveurs locaux n'incluent aucune métrique par défaut CloudWatch et doivent utiliser l' CloudWatch agent ou le AWS CLI AWS SDK pour capturer les métriques. Cela signifie que vous devez définir les métriques que vous souhaitez capturer (par exemple, l'utilisation du processeur) dans le fichier CloudWatch de configuration. Vous pouvez créer un fichier de CloudWatch configuration unique qui inclut les métriques d'instance EC2 standard pour vos serveurs sur site et l'appliquer en plus de votre configuration standard CloudWatch .

Les [métriques](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/working_with_metrics.html) entrées CloudWatch sont définies de manière unique par le nom de la métrique et par zéro dimension ou plus, et sont regroupées de manière unique dans un espace de noms de métrique. Les métriques fournies par un AWS service ont un espace de noms qui commence par `AWS` (par exemple,`AWS/EC2`), et les mesures non AWS métriques sont considérées comme des métriques personnalisées. Les métriques que vous configurez et capturez avec l' CloudWatch agent sont toutes considérées comme des métriques personnalisées. Le nombre de métriques créées ayant une incidence sur vos CloudWatch coûts, vous devez déterminer si chaque métrique est requise pour toutes vos instances EC2 ou uniquement pour certaines d'entre elles. Par exemple, vous pouvez définir un ensemble complet de mesures pour les charges de travail de production, mais utiliser un sous-ensemble plus restreint de ces mesures pour les charges de travail hors production.

`CWAgent`est l'espace de noms par défaut pour les métriques publiées par l' CloudWatch agent. À l'instar des groupes de journaux, l'espace de noms des métriques organise un ensemble de métriques afin qu'elles puissent être trouvées ensemble au même endroit. Vous devez modifier l'espace de noms pour qu'il reflète une unité commerciale, un projet ou une application, ainsi qu'un environnement (par exemple,`/<Business unit>/<Project or application name>/<Environment>`). Cette approche est utile si plusieurs charges de travail indépendantes utilisent le même compte. Vous pouvez également corréler la convention de dénomination de votre espace de nommage à la convention de dénomination de votre groupe de CloudWatch journaux.

Les métriques sont également identifiées par leurs dimensions, ce qui vous permet de les analyser par rapport à un ensemble de conditions. Ce sont les propriétés par rapport auxquelles les observations sont enregistrées. Amazon EC2 inclut des [métriques distinctes pour les](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html#ec2-cloudwatch-dimensions) instances EC2 avec `InstanceId` et leurs dimensions. `AutoScalingGroupName` Vous recevez également des métriques avec les `InstanceType` dimensions `ImageId` et si vous activez le suivi détaillé. Par exemple, Amazon EC2 fournit une métrique d'instance EC2 distincte pour l'utilisation du processeur avec les `InstanceId` dimensions, en plus d'une métrique d'utilisation du processeur distincte pour la dimension. `InstanceType` Cela vous permet d'analyser l'utilisation du processeur pour chaque instance EC2 unique, en plus de toutes les instances EC2 d'un type d'[instance](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/instance-types.html) spécifique. 

L'ajout de dimensions augmente votre capacité d'analyse mais augmente également vos coûts globaux, car chaque combinaison de mesures et de valeurs de dimension uniques donne lieu à une nouvelle métrique. Par exemple, si vous créez une métrique pour le pourcentage d'utilisation de la mémoire par rapport à la `InstanceId` dimension, il s'agit d'une nouvelle métrique pour chaque instance EC2. Si votre entreprise gère des milliers d'instances EC2, cela génère des milliers de métriques et entraîne une hausse des coûts. Pour contrôler et prévoir les coûts, assurez-vous de déterminer la cardinalité de la métrique et les dimensions qui ajoutent le plus de valeur. Par exemple, vous pouvez définir un ensemble complet de dimensions pour les mesures de votre charge de travail de production, mais un sous-ensemble plus restreint de ces dimensions pour les charges de travail hors production.

Vous pouvez utiliser cette `append_dimensions` propriété pour ajouter des dimensions à une ou à toutes les métriques définies dans votre CloudWatch configuration. Vous pouvez également ajouter dynamiquement le`ImageId`, `InstanceId``InstanceType`, et `AutoScalingGroupName` à toutes les métriques de votre CloudWatch configuration. Vous pouvez également ajouter un nom et une valeur de dimension arbitraires pour des métriques spécifiques en utilisant la `append_dimensions` propriété de cette métrique. CloudWatch peut également agréger des statistiques sur les dimensions métriques que vous avez définies avec la `aggregation_dimensions` propriété. 

Par exemple, vous pouvez agréger la mémoire utilisée par rapport à la `InstanceType` dimension pour voir la mémoire moyenne utilisée par toutes les instances EC2 pour chaque type d'instance. Si vous utilisez `t2.micro` des instances exécutées dans une région, vous pouvez déterminer si les charges de travail utilisant la `t2.micro` classe surutilisent ou sous-utilisent la mémoire fournie. La sous-utilisation peut être le signe de charges de travail utilisant des classes EC2 dont la capacité de mémoire n'est pas requise. En revanche, la surutilisation peut être le signe de charges de travail utilisant des classes Amazon EC2 avec une mémoire insuffisante.

Le schéma suivant montre un exemple de configuration de CloudWatch métriques qui utilise un espace de noms personnalisé, des dimensions ajoutées et une agrégation par`InstanceType`.

![\[Exemple de configuration de CloudWatch métriques avec CloudWatch un agent.\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/images/cloudwatch-image-2.png)


# Configuration au niveau du CloudWatch système
<a name="system-level-cloudwatch-configuration"></a>

Les métriques et les journaux au niveau du système constituent un élément central d'une solution de surveillance et de journalisation, et l' CloudWatch agent dispose d'options de configuration spécifiques pour Windows et Linux. 

Nous vous recommandons d'utiliser l'[assistant de fichier CloudWatch de configuration](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/create-cloudwatch-agent-configuration-file-wizard.html) ou le schéma du fichier de configuration pour définir le fichier de configuration de l' CloudWatch agent pour chaque système d'exploitation que vous envisagez de prendre en charge. Des journaux et des métriques supplémentaires spécifiques à la charge de travail au niveau du système d'exploitation peuvent être définis dans des fichiers de CloudWatch configuration distincts et ajoutés à la configuration standard. Ces fichiers de configuration uniques doivent être stockés séparément dans un compartiment S3 où ils peuvent être récupérés par vos instances EC2. Un exemple de configuration d'un compartiment S3 à cette fin est décrit dans la [Gestion des CloudWatch configurations](create-store-cloudwatch-configurations.md#store-cloudwatch-configuration-s3) section de ce guide. Vous pouvez récupérer et appliquer automatiquement ces configurations à l'aide de State Manager et de Distributor.

## Configuration des journaux au niveau du système
<a name="system-level-logs"></a>

Les journaux au niveau du système sont essentiels pour diagnostiquer et résoudre les problèmes sur site ou dans le cloud. AWS Votre approche de capture des journaux doit inclure tous les journaux système et de sécurité générés par le système d'exploitation. Les fichiers journaux générés par le système d'exploitation peuvent être différents selon la version du système d'exploitation.

L' CloudWatch agent prend en charge la surveillance des journaux d'événements Windows en fournissant le nom du journal d'événements. Vous pouvez choisir les journaux d'événements Windows que vous souhaitez surveiller (par exemple `System``Application`, ou`Security`).

Les journaux du système, des applications et de sécurité des systèmes Linux sont généralement stockés dans le `/var/log` répertoire. Le tableau suivant définit les fichiers journaux par défaut courants que vous devez surveiller, mais vous devez vérifier le `/etc/syslog.conf` fichier `/etc/rsyslog.conf` ou pour déterminer la configuration spécifique des fichiers journaux de votre système.

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/system-level-cloudwatch-configuration.html)

Votre organisation peut également disposer d'autres agents ou composants du système qui génèrent des journaux que vous souhaitez surveiller. Vous devez évaluer et décider quels fichiers journaux sont générés par ces agents ou applications, et les inclure dans votre configuration en identifiant leur emplacement. Par exemple, vous devez inclure le Systems Manager et les journaux des CloudWatch agents dans votre configuration. Le tableau suivant indique l'emplacement de ces journaux d'agent pour Windows et Linux. 

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/system-level-cloudwatch-configuration.html)

CloudWatch ignore un fichier journal si celui-ci est défini dans la configuration de l' CloudWatch agent mais n'est pas trouvé. Cela est utile lorsque vous souhaitez conserver une configuration de journal unique pour Linux, plutôt que des configurations distinctes pour chaque distribution. C'est également utile lorsqu'un fichier journal n'existe pas tant que l'agent ou l'application logicielle ne démarre pas.

## Configuration des métriques au niveau du système
<a name="system-level-metrics"></a>

L'utilisation de la mémoire et de l'espace disque n'est pas incluse dans les métriques standard fournies par Amazon EC2. Pour inclure ces métriques, vous devez installer et configurer l' CloudWatch agent sur vos instances EC2. L'assistant de configuration de l' CloudWatch agent crée une CloudWatch configuration avec [des métriques prédéfinies](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/create-cloudwatch-agent-configuration-file-wizard.html#cloudwatch-agent-preset-metrics) et vous pouvez ajouter ou supprimer des métriques selon vos besoins. Assurez-vous de passer en revue les ensembles de mesures prédéfinis pour déterminer le niveau approprié dont vous avez besoin.

Les utilisateurs finaux et les responsables de la charge de travail doivent publier des métriques système supplémentaires en fonction des exigences spécifiques d'un serveur ou d'une instance EC2. Ces définitions de métriques doivent être stockées, versionnées et gérées dans un fichier de configuration d' CloudWatch agent distinct, puis partagées dans un emplacement central (par exemple, Amazon S3) à des fins de réutilisation et d'automatisation.

Les métriques Amazon EC2 standard ne sont pas automatiquement capturées sur les serveurs locaux. Ces métriques doivent être définies dans un fichier de configuration d' CloudWatch agent utilisé par les instances locales. Vous pouvez créer un fichier de configuration de métriques distinct pour les instances locales avec des métriques telles que l'utilisation du processeur, et ajouter ces métriques au fichier de configuration de métriques standard.

# Configuration au niveau de l'application CloudWatch
<a name="application-level-configuration"></a>

Les journaux et les métriques des applications sont générés par les applications en cours d'exécution et sont spécifiques aux applications. Assurez-vous de définir les journaux et les mesures nécessaires pour surveiller de manière adéquate les applications régulièrement utilisées par votre organisation. Par exemple, votre organisation a peut-être standardisé les applications Web sur Microsoft Internet Information Server (IIS). Vous pouvez créer une CloudWatch configuration standard de log et de métrique pour IIS qui peut également être utilisée dans l'ensemble de votre organisation. Les fichiers de configuration spécifiques à l'application peuvent être stockés dans un emplacement centralisé (par exemple, un compartiment S3) et sont accessibles par les propriétaires de charge de travail ou via une récupération automatique, puis copiés dans le CloudWatch répertoire de configuration. L' CloudWatch agent combine automatiquement les fichiers de CloudWatch configuration présents dans le répertoire des fichiers de configuration de chaque instance ou serveur EC2 dans une CloudWatch configuration composite. Le résultat final est une CloudWatch configuration qui inclut la configuration standard au niveau du système de votre entreprise, ainsi que toutes les configurations pertinentes au niveau de l'application CloudWatch . 

Les propriétaires de charges de travail doivent identifier et configurer les fichiers journaux et les mesures pour tous les composants et applications critiques. 

## Configuration des journaux au niveau de l'application
<a name="application-logs-configuration"></a>

La journalisation au niveau de l'application varie selon qu'il s'agit d'une application commerciale off-the-shelf (COTS) ou d'une application développée sur mesure. Les applications COTS et leurs composants peuvent fournir plusieurs options pour la configuration et la sortie des journaux, telles que le niveau de détail du journal, le format du fichier journal et l'emplacement du fichier journal. Cependant, la plupart des applications COTS ou tierces ne vous permettent pas de modifier fondamentalement la journalisation (par exemple, en mettant à jour le code de l'application pour inclure des instructions de journal supplémentaires ou des formats non configurables). Vous devez au minimum configurer les options de journalisation pour les applications COTS ou tierces afin de consigner les informations relatives aux avertissements et aux erreurs, de préférence au format JSON.

Vous pouvez intégrer des applications développées sur mesure à CloudWatch Logs en incluant les fichiers journaux de l'application dans votre CloudWatch configuration. Les applications personnalisées améliorent la qualité et le contrôle des journaux, car vous pouvez personnaliser le format de sortie des journaux, classer et séparer les sorties des composants pour séparer les fichiers journaux, en plus d'inclure les informations supplémentaires requises. Assurez-vous de passer en revue et de normaliser les bibliothèques de journalisation ainsi que les données et le formatage requis pour votre organisation afin de faciliter les analyses et le traitement.

Vous pouvez également écrire dans un flux de CloudWatch journal à l'aide de l'appel de `[PutLogEvents](https://docs.aws.amazon.com//AmazonCloudWatchLogs/latest/APIReference/API_PutLogEvents.html)` l'API CloudWatch Logs ou à l'aide du AWS SDK. Vous pouvez utiliser l'API ou le SDK pour des exigences de journalisation personnalisées, telles que la coordination de la journalisation dans un flux de journal unique sur un ensemble distribué de composants et de serveurs. Cependant, la solution la plus simple à gérer et la plus largement applicable consiste à configurer vos applications pour qu'elles écrivent dans des fichiers journaux, puis à utiliser l' CloudWatch agent pour lire les fichiers journaux et les diffuser en continu CloudWatch.

Vous devez également prendre en compte le type de métriques que vous souhaitez mesurer à partir des fichiers journaux de votre application. Vous pouvez utiliser des filtres métriques pour mesurer, représenter graphiquement et générer des alarmes sur ces données dans un groupe de CloudWatch journaux. Par exemple, vous pouvez utiliser un filtre métrique pour compter les tentatives de connexion infructueuses en les identifiant dans vos journaux. 

Vous pouvez également créer des métriques personnalisées pour vos applications développées sur mesure en utilisant le [format de [métrique CloudWatch intégré](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format.html)](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format.html) dans les fichiers journaux de vos applications.

## Configuration des métriques au niveau de l'application
<a name="application-metrics"></a>

Les métriques personnalisées sont des métriques qui ne sont pas directement fournies par les AWS services à CloudWatch et elles sont publiées dans un espace de noms personnalisé dans CloudWatch les métriques. Toutes les métriques d'application sont considérées comme des CloudWatch métriques personnalisées. Les métriques d'application peuvent s'aligner sur une instance EC2, un composant d'application, un appel d'API ou même une fonction métier. Vous devez également tenir compte de l'importance et de la cardinalité des dimensions que vous choisissez pour vos indicateurs. Les dimensions présentant une cardinalité élevée génèrent un grand nombre de mesures personnalisées et peuvent augmenter vos CloudWatch coûts.

CloudWatch vous permet de capturer des métriques au niveau de l'application de plusieurs manières, notamment de la manière suivante :
+ Capturez les métriques au niveau des processus en définissant les processus individuels que vous souhaitez capturer à partir du plugin [procstat](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-procstat-process-metrics.html). 
+ Une application publie une métrique dans Windows Performance Monitor et cette métrique est définie dans la CloudWatch configuration.
+ Les filtres et modèles métriques sont appliqués aux connexions d'une application CloudWatch.
+ Une application écrit dans un CloudWatch journal en utilisant le format métrique CloudWatch intégré.
+ Une application envoie une métrique CloudWatch via l'API ou le AWS SDK.
+ Une application envoie une métrique à un démon [collectd](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-custom-metrics-collectd.html) ou [StatsD](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-custom-metrics-statsd.html) avec un agent configuré. CloudWatch 

Vous pouvez utiliser procstat pour surveiller et mesurer les processus applicatifs critiques à l'aide de l' CloudWatchagent. Cela vous permet de déclencher une alarme et de prendre des mesures (par exemple, une notification ou un processus de redémarrage) si un processus critique n'est plus en cours d'exécution pour votre application. Vous pouvez également mesurer les caractéristiques de performance des processus de votre application et déclencher une alarme si un processus particulier agit de manière anormale. 

La surveillance Procstat est également utile si vous ne pouvez pas mettre à jour vos applications COTS avec des métriques personnalisées supplémentaires. Par exemple, vous pouvez créer une `my_process` métrique qui mesure `cpu_time` et inclut une `application_version` dimension personnalisée. Vous pouvez également utiliser plusieurs fichiers de configuration d' CloudWatch agent pour une application si vous avez des dimensions différentes pour différents indicateurs.

Si votre application s'exécute sous Windows, vous devez évaluer si elle publie déjà des statistiques dans Windows Performance Monitor. De nombreuses applications COTS s'intègrent à Windows Performance Monitor, qui vous permet de surveiller facilement les indicateurs des applications. CloudWatch s'intègre également à Windows Performance Monitor et vous pouvez capturer toutes les mesures qui y sont déjà disponibles.

Assurez-vous de vérifier le format de journalisation et les informations de journal fournies par vos applications afin de déterminer quelles mesures peuvent être extraites à l'aide de filtres métriques. Vous pouvez consulter les journaux historiques de l'application afin de déterminer comment les messages d'erreur et les arrêts anormaux sont représentés. Vous devez également examiner les problèmes signalés précédemment afin de déterminer si une métrique peut être capturée afin d'éviter que le problème ne se reproduise. Vous devez également consulter la documentation de l'application et demander aux développeurs de l'application de confirmer comment les messages d'erreur peuvent être identifiés.

Pour les applications développées sur mesure, collaborez avec les développeurs de l'application pour définir les mesures importantes qui peuvent être mises en œuvre à l'aide du format de métrique CloudWatch intégré, du AWS SDK ou AWS de l'API. L'approche recommandée consiste à utiliser le format métrique intégré. Vous pouvez utiliser les bibliothèques de formats métriques intégrées open source AWS fournies pour vous aider à rédiger vos instructions dans le format requis. Vous devez également mettre à jour la [ CloudWatch configuration spécifique à votre application](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format_Generation_CloudWatch_Agent.html) pour inclure l'agent de format métrique intégré. L'agent exécuté sur l'instance EC2 agit donc comme un point de terminaison local au format métrique intégré qui envoie des métriques au format métrique intégré à CloudWatch.

Si vos applications prennent déjà en charge la publication de métriques à collecter ou à indiquer, vous pouvez les exploiter pour y investir des métriques. CloudWatch