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.
# Planification de votre CloudWatch déploiement
La complexité et la portée d'une solution de journalisation et de surveillance dépendent de plusieurs facteurs, notamment :
+ Combien d'environnements, de régions et de comptes sont utilisés et comment ce nombre pourrait augmenter.
+ La variété et les types de vos charges de travail et architectures existantes.
+ Les types de calcul et OSs ceux qui doivent être enregistrés et surveillés.
+ S'il existe à la fois des sites et une AWS infrastructure sur site.
+ Les exigences d'agrégation et d'analyse de plusieurs systèmes et applications.
+ Exigences de sécurité qui empêchent l'exposition non autorisée de journaux et de mesures.
+ Produits et solutions qui doivent s'intégrer à votre solution de journalisation et de surveillance pour soutenir les processus opérationnels.
Vous devez régulièrement revoir et mettre à jour votre solution de journalisation et de surveillance avec des déploiements de charge de travail nouveaux ou actualisés. Les mises à jour de votre journalisation, de votre surveillance et de vos alarmes doivent être identifiées et appliquées lorsque des problèmes sont observés. Ces problèmes peuvent ensuite être identifiés de manière proactive et évités à l'avenir.
Vous devez vous assurer que vous installez et configurez systématiquement les logiciels et les services permettant de capturer et d'ingérer les journaux et les mesures. Une approche de journalisation et de surveillance établie utilise des services et des solutions de fournisseurs de logiciels (ISV) multiples AWS ou indépendants pour différents domaines (par exemple, la sécurité, les performances, la mise en réseau ou l'analyse). Chaque domaine a ses propres exigences en matière de déploiement et de configuration.
Nous vous recommandons CloudWatch de l'utiliser pour capturer et ingérer des journaux et des métriques pour plusieurs OSs types de calcul. De nombreux AWS services sont utilisés CloudWatch pour enregistrer, surveiller et publier des journaux et des métriques, sans nécessiter de configuration supplémentaire. CloudWatch fournit un [agent logiciel](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html) qui peut être installé et configuré pour différents OSs environnements. Les sections suivantes expliquent comment déployer, installer et configurer l' CloudWatch agent pour plusieurs comptes, régions et configurations :
**Topics**
+ [
# Utilisation CloudWatch dans des comptes centralisés ou distribués
](cloudwatch-centralized-distributed-accounts.md)
+ [
# Gestion des fichiers de configuration des CloudWatch agents
](create-store-cloudwatch-configurations.md)
# Utilisation CloudWatch dans des comptes centralisés ou distribués
Bien qu' CloudWatch il soit conçu pour surveiller les AWS services ou les ressources d'un seul compte et d'une seule région, vous pouvez utiliser un compte central pour capturer les journaux et les statistiques de plusieurs comptes et régions. Si vous utilisez plusieurs comptes ou régions, vous devez déterminer s'il convient d'utiliser l'approche des comptes centralisés ou un compte individuel pour capturer les journaux et les statistiques. Généralement, une approche hybride est requise pour les déploiements multicomptes et multirégions afin de répondre aux exigences des responsables de la sécurité, de l'analyse, des opérations et de la charge de travail.
Le tableau suivant indique les points à prendre en compte lors du choix d'une approche centralisée, distribuée ou hybride.
****
| | |
| --- |--- |
| Structures de comptes | Votre organisation peut avoir plusieurs comptes distincts (par exemple, des comptes pour les charges de travail hors production et de production) ou des milliers de comptes pour des applications uniques dans des environnements spécifiques. Nous vous recommandons de conserver les journaux et les métriques des applications dans le compte sur lequel s'exécute la charge de travail, afin que les propriétaires de la charge de travail puissent y accéder. Cela leur permet de jouer un rôle actif dans la journalisation et la surveillance. Nous vous recommandons également d'utiliser un compte de journalisation distinct pour agréger tous les journaux de charge de travail à des fins d'analyse, d'agrégation, de tendances et d'opérations centralisées. Des comptes de journalisation distincts peuvent également être utilisés à des fins de sécurité, d'archivage, de surveillance et d'analyse. |
| Exigences en matière d'accès | Les membres de l'équipe (par exemple, les propriétaires de charges de travail ou les développeurs) doivent avoir accès aux journaux et aux métriques pour résoudre les problèmes et apporter des améliorations. Les journaux doivent être conservés dans le compte de la charge de travail pour faciliter l'accès et le dépannage. Si les journaux et les métriques sont conservés dans un compte distinct de celui de la charge de travail, les utilisateurs peuvent avoir besoin d'alterner régulièrement entre les comptes. L'utilisation d'un compte centralisé fournit des informations de journal aux utilisateurs autorisés sans accorder l'accès au compte de charge de travail. Cela peut simplifier les exigences d'accès pour les charges de travail analytiques où l'agrégation est requise pour les charges de travail exécutées sur plusieurs comptes. Le compte de journalisation centralisé peut également proposer d'autres options de recherche et d'agrégation, telles qu'un cluster Amazon OpenSearch Service. Amazon OpenSearch Service [fournit un contrôle d'accès précis](https://docs.aws.amazon.com//opensearch-service/latest/developerguide/fgac.html) jusqu'au niveau du terrain pour vos journaux. Un contrôle d'accès précis est important lorsque vous avez des données sensibles ou confidentielles qui nécessitent un accès et des autorisations spécialisés. |
| Opérations | De nombreuses organisations disposent d'une équipe centralisée chargée des opérations et de la sécurité ou d'une organisation externe chargée du support opérationnel qui a besoin d'accéder aux journaux à des fins de surveillance. La journalisation et la surveillance centralisées peuvent faciliter l'identification des tendances, la recherche, l'agrégation et l'exécution d'analyses sur tous les comptes et charges de travail. Si votre organisation utilise l'approche « [vous le créez, vous l'exécutez](https://aws.amazon.com//blogs/enterprise-strategy/enterprise-devops-why-you-should-run-what-you-build/) » DevOps, les responsables de la charge de travail ont besoin de consigner et de surveiller les informations dans leur compte. Une approche hybride peut être nécessaire pour répondre aux besoins des opérations et des analyses centralisées, en plus de la propriété distribuée de la charge de travail. |
| Environnement | Vous pouvez choisir d'héberger les journaux et les métriques dans un emplacement central pour les comptes de production et de conserver les journaux et les métriques pour d'autres environnements (par exemple, le développement ou les tests) dans le même compte ou dans des comptes distincts, en fonction des exigences de sécurité et de l'architecture du compte. Cela permet d'empêcher un public plus large d'accéder aux données sensibles créées pendant la production. |
CloudWatch propose [plusieurs options](https://docs.aws.amazon.com//AmazonCloudWatch/latest/logs/Subscriptions.html) pour traiter les journaux en temps réel grâce à des filtres CloudWatch d'abonnement. Vous pouvez utiliser des filtres d'abonnement pour diffuser les journaux en temps réel vers AWS des services à des fins de traitement, d'analyse et de chargement personnalisés vers d'autres systèmes. Cela peut être particulièrement utile si vous adoptez une approche hybride dans laquelle vos journaux et statistiques sont disponibles dans des comptes individuels et des régions, en plus d'un compte et d'une région centralisés. La liste suivante fournit des exemples de AWS services pouvant être utilisés à cette fin :
+ [Amazon Data Firehose — Firehose](https://docs.aws.amazon.com//firehose/latest/dev/what-is-this-service.html) fournit une solution de streaming qui s'adapte et se redimensionne automatiquement en fonction du volume de données produit. Vous n'avez pas besoin de gérer le nombre de partitions dans un flux de données Amazon Kinesis et vous pouvez vous connecter directement à Amazon Simple Storage Service (Amazon S3) OpenSearch , Amazon Service ou Amazon Redshift sans codage supplémentaire. Firehose est une solution efficace si vous souhaitez centraliser vos logs dans ces services. AWS
+ [Amazon Kinesis Data](https://docs.aws.amazon.com//streams/latest/dev/introduction.html) Streams — Kinesis Data Streams est une solution appropriée si vous devez intégrer un service non pris en charge par Firehose et implémenter une logique de traitement supplémentaire. Vous pouvez créer une destination Amazon CloudWatch Logs dans vos comptes et régions qui spécifie un flux de données Kinesis dans un compte central et un rôle Gestion des identités et des accès AWS (IAM) lui octroyant l'autorisation de placer des enregistrements dans le flux. Kinesis Data Streams fournit une zone d'atterrissage flexible et illimitée pour vos données de journal, qui peuvent ensuite être consommées par différentes options. Vous pouvez lire les données du journal Kinesis Data Streams dans votre compte, effectuer un prétraitement et envoyer les données vers la destination de votre choix.
Cependant, vous devez configurer les partitions du flux de manière à ce qu'il soit correctement dimensionné pour les données de journal produites. Kinesis Data Streams agit comme un intermédiaire ou une file d'attente temporaire pour vos données de journal, et vous pouvez stocker les données dans le flux Kinesis pendant un à 365 jours. Kinesis Data Streams prend également en charge la fonctionnalité de rediffusion, ce qui signifie que vous pouvez rejouer des données qui n'ont pas été consommées.
+ [Amazon OpenSearch Service](https://docs.aws.amazon.com//opensearch-service/latest/developerguide/what-is.html) — CloudWatch Logs peut diffuser les journaux d'un groupe de journaux vers un OpenSearch cluster via un compte individuel ou centralisé. Lorsque vous configurez un groupe de journaux pour diffuser des données vers un OpenSearch cluster, une fonction Lambda est créée dans le même compte et dans la même région que votre groupe de journaux. La fonction Lambda doit disposer d'une connexion réseau avec le OpenSearch cluster. Vous pouvez personnaliser la fonction Lambda pour effectuer un prétraitement supplémentaire, en plus de personnaliser l'ingestion dans Amazon Service. OpenSearch La journalisation centralisée avec Amazon OpenSearch Service facilite l'analyse, la recherche et le dépannage des problèmes liés aux multiples composants de votre architecture cloud.
+ [Lambda](https://docs.aws.amazon.com//lambda/latest/dg/welcome.html) — Si vous utilisez Kinesis Data Streams, vous devez fournir et gérer les ressources de calcul qui consomment les données de votre flux. Pour éviter cela, vous pouvez transmettre les données du journal directement à Lambda pour traitement et les envoyer vers une destination en fonction de votre logique. Cela signifie que vous n'avez pas besoin de provisionner et de gérer des ressources informatiques pour traiter les données entrantes. [Si vous choisissez d'utiliser Lambda, assurez-vous que votre solution est compatible avec les quotas Lambda.](https://docs.aws.amazon.com//lambda/latest/dg/gettingstarted-limits.html)
Il se peut que vous deviez traiter ou partager des données de journal stockées dans CloudWatch des journaux au format de fichier. Vous pouvez créer une tâche d'exportation pour [exporter un groupe de journaux vers Amazon S3](https://docs.aws.amazon.com//AmazonCloudWatch/latest/logs/S3Export.html) pour une date ou une plage horaire spécifique. Par exemple, vous pouvez choisir d'exporter les journaux quotidiennement vers Amazon S3 à des fins d'analyse et d'audit. Lambda peut être utilisé pour automatiser cette solution. Vous pouvez également associer cette solution à la réplication Amazon S3 pour expédier et centraliser vos journaux provenant de plusieurs comptes et régions vers un compte et une région centralisés.
La configuration de l' CloudWatch agent peut également spécifier un `credentials` champ dans la [`agent`section](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-Configuration-File-Details.html#CloudWatch-Agent-Configuration-File-Agentsection). Cela indique un rôle IAM à utiliser lors de l'envoi de métriques et de journaux vers un autre compte. S'il est spécifié, ce champ contient le `role_arn` paramètre. Ce champ peut être utilisé lorsque vous n'avez besoin que d'une journalisation et d'une surveillance centralisées dans un compte centralisé et une région spécifiques.
Vous pouvez également utiliser le [AWS SDK](https://aws.amazon.com/developer/tools/) pour écrire votre propre application de traitement personnalisée dans la langue de votre choix, lire les journaux et les indicateurs de vos comptes et envoyer des données vers un compte centralisé ou une autre destination pour un traitement et une surveillance ultérieurs.
# Gestion des fichiers de configuration des CloudWatch agents
Nous vous recommandons de créer une configuration d' CloudWatch agent Amazon standard qui inclut les journaux système et les métriques que vous souhaitez capturer sur toutes vos instances Amazon Elastic Compute Cloud (Amazon EC2) et sur tous vos serveurs sur site. Vous pouvez utiliser l'[assistant du fichier de configuration](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create-cloudwatch-agent-configuration-file-wizard.html) de l' CloudWatch agent pour vous aider à créer le fichier de configuration. Vous pouvez exécuter l'assistant de configuration plusieurs fois afin de générer des configurations uniques pour différents systèmes et environnements. Vous pouvez également modifier le fichier de configuration ou créer des variantes à l'[aide du schéma du fichier de configuration](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-Configuration-File-Details.html). Le fichier de configuration de l' CloudWatch agent peut être stocké dans les paramètres [d'AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html). Vous pouvez créer des paramètres de magasin de paramètres distincts si vous disposez de [plusieurs fichiers de configuration d' CloudWatch agent](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-common-scenarios.html#CloudWatch-Agent-multiple-config-files). Si vous utilisez plusieurs comptes AWS ou régions AWS, vous devez gérer et mettre à jour les paramètres du magasin de paramètres dans chaque compte et région. Vous pouvez également gérer vos CloudWatch configurations de manière centralisée sous forme de fichiers dans Amazon S3 ou dans un outil de contrôle de version de votre choix.
Le `amazon-cloudwatch-agent-ctl` script inclus dans l' CloudWatch agent vous permet de spécifier un fichier de configuration, un paramètre Parameter Store ou la configuration par défaut de l'agent. La configuration par défaut s'aligne sur l'ensemble de mesures de base prédéfini et configure l'agent pour qu'il communique les métriques de mémoire et d'espace disque à. CloudWatch Cependant, il n'inclut aucune configuration de fichier journal. La configuration par défaut est également appliquée si vous utilisez la [configuration rapide de Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-quick-setup.html) pour l' CloudWatch agent.
Étant donné que la configuration par défaut n'inclut pas la journalisation et n'est pas personnalisée en fonction de vos besoins, nous vous recommandons de créer et d'appliquer vos propres CloudWatch configurations, personnalisées en fonction de vos besoins.
## Gestion des CloudWatch configurations
Par défaut, les CloudWatch configurations peuvent être stockées et appliquées sous forme de paramètres de magasin de paramètres ou de fichiers CloudWatch de configuration. Le meilleur choix dépendra de vos besoins. Dans cette section, nous discutons des avantages et des inconvénients de ces deux options. Une solution représentative est également détaillée pour gérer les fichiers CloudWatch de configuration pour plusieurs comptes AWS et régions AWS.
**Paramètres du magasin de paramètres de Systems Manager**
L'utilisation des paramètres du magasin de paramètres pour gérer les CloudWatch configurations fonctionne bien si vous avez un seul fichier de configuration d' CloudWatch agent standard que vous souhaitez appliquer et gérer dans un petit ensemble de comptes et de régions AWS. Lorsque vous stockez vos CloudWatch configurations sous forme de paramètres de magasin de paramètres, vous pouvez utiliser l'outil de configuration de l' CloudWatch agent (sous Linux) pour lire et appliquer la configuration depuis le magasin de paramètres sans avoir à copier le fichier de configuration `amazon-cloudwatch-agent-ctl` sur votre instance. Vous pouvez utiliser le document de commande **AmazonCloudWatch- ManageAgent ** Systems Manager pour mettre à jour la CloudWatch configuration sur plusieurs instances EC2 en une seule fois. Les paramètres du magasin de paramètres étant régionaux, vous devez mettre à jour et gérer les CloudWatch paramètres du magasin de paramètres dans chaque région AWS et chaque compte AWS. Si vous souhaitez appliquer plusieurs CloudWatch configurations à chaque instance, vous devez personnaliser le document **AmazonCloudWatch- ManageAgent** Command**** pour inclure ces paramètres.
**CloudWatch fichiers de configuration**
La gestion de vos CloudWatch configurations sous forme de fichiers peut fonctionner correctement si vous possédez de nombreux comptes et régions AWS et si vous gérez plusieurs fichiers CloudWatch de configuration. Grâce à cette approche, vous pouvez les parcourir, les organiser et les gérer dans une structure de dossiers. Vous pouvez appliquer des règles de sécurité à des dossiers ou à des fichiers individuels afin de limiter et d'accorder l'accès, par exemple des autorisations de mise à jour et de lecture. Vous pouvez les partager et les transférer en dehors d'AWS à des fins de collaboration. Vous pouvez contrôler les versions des fichiers pour suivre et gérer les modifications. Vous pouvez appliquer des CloudWatch configurations collectivement en copiant les fichiers de configuration dans le répertoire de configuration de l' CloudWatch agent sans appliquer chaque fichier de configuration individuellement. Pour Linux, le répertoire CloudWatch de configuration se trouve à l'adresse`/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d`. Pour Windows, le répertoire de configuration se trouve à l'adresse`C:\ProgramData\Amazon\AmazonCloudWatchAgent\Configs`.
Lorsque vous démarrez l' CloudWatch agent, celui-ci ajoute automatiquement chaque fichier présent dans ces répertoires pour créer un fichier de configuration CloudWatch composite. Les fichiers de configuration doivent être stockés dans un emplacement central (par exemple, un compartiment S3) auquel les comptes et régions requis peuvent accéder. Un exemple de solution utilisant cette approche est fourni.
**Organisation des CloudWatch configurations**
Quelle que soit l'approche utilisée pour gérer vos CloudWatch configurations, CloudWatch organisez-les. Vous pouvez organiser vos configurations en chemins de fichier ou de magasin de paramètres en utilisant une approche telle que la suivante.
| | |
| --- |--- |
| */config/standard/windows/ec2* | Stockez les fichiers de CloudWatch configuration standard spécifiques à Windows pour Amazon EC2. Vous pouvez également classer les configurations standard de votre système d'exploitation (OS) pour différentes versions de Windows, différents types d'instances EC2 et différents environnements dans ce dossier. |
| */config/standard/windows/onpremises* | Stockez des fichiers de CloudWatch configuration standard spécifiques à Windows pour les serveurs locaux. Vous pouvez également classer vos configurations de système d'exploitation standard pour les différentes versions de Windows, les différents types de serveurs et les différents environnements dans ce dossier. |
| */config/standard/linux/ec2* | Stockez vos fichiers de CloudWatch configuration standard spécifiques à Linux pour Amazon EC2. Vous pouvez également classer votre configuration de système d'exploitation standard pour différentes distributions Linux, types d'instances EC2 et environnements dans ce dossier. |
| */config/standard/linux/onpremises* | Stockez vos fichiers de CloudWatch configuration standard spécifiques à Linux pour les serveurs locaux. Vous pouvez également classer votre configuration de système d'exploitation standard pour différentes distributions Linux, types de serveurs et environnements dans ce dossier. |
| */config/ecs* | Stockez les fichiers de CloudWatch configuration spécifiques à Amazon Elastic Container Service (Amazon ECS) si vous utilisez des instances de conteneur Amazon ECS. Ces configurations peuvent être ajoutées aux configurations standard d'Amazon EC2 pour la journalisation et la surveillance au niveau des systèmes spécifiques à Amazon ECS. |
| */configuration/* | Stockez les fichiers de CloudWatch configuration spécifiques à votre application. Vous pouvez mieux classer vos applications à l'aide de dossiers et de préfixes supplémentaires pour les environnements et les versions. |
## Exemple : stockage des fichiers CloudWatch de configuration dans un compartiment S3
Cette section fournit un exemple d'utilisation d'Amazon S3 pour stocker les fichiers de CloudWatch configuration et un runbook personnalisé de Systems Manager pour récupérer et appliquer les fichiers CloudWatch de configuration. Cette approche permet de relever certains des défis liés à l'utilisation des paramètres du magasin de paramètres de Systems Manager pour une CloudWatch configuration à grande échelle :
+ Si vous utilisez plusieurs régions, vous devez synchroniser les mises à jour CloudWatch de configuration dans le magasin de paramètres de chaque région. Parameter Store est un service régional et le même paramètre doit être mis à jour dans chaque région qui utilise l' CloudWatch agent.
+ Si vous avez plusieurs CloudWatch configurations, vous devez lancer la récupération et l'application de chaque configuration du magasin de paramètres. Vous devez récupérer chaque CloudWatch configuration individuellement dans le magasin de paramètres et également mettre à jour la méthode de récupération chaque fois que vous ajoutez une nouvelle configuration. En revanche, CloudWatch fournit un répertoire de configuration pour stocker les fichiers de configuration et applique chaque configuration du répertoire, sans qu'il soit nécessaire de les spécifier individuellement.
+ Si vous utilisez plusieurs comptes, vous devez vous assurer que chaque nouveau compte possède les CloudWatch configurations requises dans son magasin de paramètres. Vous devez également vous assurer que toute modification de configuration sera appliquée à ces comptes et à leurs régions à l'avenir.
Vous pouvez stocker CloudWatch les configurations dans un compartiment S3 accessible depuis tous vos comptes et régions. Vous pouvez ensuite copier ces configurations depuis le compartiment S3 vers le répertoire de CloudWatch configuration à l'aide des runbooks Systems Manager Automation et de Systems Manager State Manager. Vous pouvez utiliser le modèle CloudFormation AWS [cloudwatch-config-s3-bucket.yaml](https://github.com/aws-samples/logging-monitoring-apg-guide-examples/blob/main/cloudwatch-config-s3-bucket.yaml) pour créer un compartiment S3 accessible depuis plusieurs comptes au sein d'une organisation dans AWS Organizations. Le modèle inclut un `OrganizationID` paramètre qui accorde un accès en lecture à tous les comptes de votre [organisation](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html).
L'exemple augmenté du runbook Systems Manager, fourni dans la section [Set up State Manager and Distributor pour le déploiement et la configuration des CloudWatch agents](https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/install-cloudwatch-systems-manager.html#set-up-systems-manager-distributor) de ce guide, est configuré pour récupérer des fichiers à l'aide du compartiment S3 créé par le modèle AWS [cloudwatch-config-s3-bucket.yaml.](https://github.com/aws-samples/logging-monitoring-apg-guide-examples/blob/main/cloudwatch-config-s3-bucket.yaml) CloudFormation
Vous pouvez également utiliser un système de contrôle de version (par exemple, GitHub) pour stocker vos fichiers de configuration. Si vous souhaitez récupérer automatiquement les fichiers de configuration stockés dans un système de contrôle de version, vous devez gérer ou centraliser le stockage des informations d'identification et mettre à jour le runbook Systems Manager Automation utilisé pour récupérer les informations d'identification sur vos comptes et. Régions AWS