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. # Journalisation et surveillance sur Amazon ECS Amazon Elastic Container Service (Amazon ECS) [propose deux types de lancement](https://docs.aws.amazon.com//AmazonECS/latest/developerguide/launch_types.html) pour exécuter des conteneurs et qui déterminent le type d'infrastructure hébergeant les tâches et les services. Ces types de lancement AWS Fargate sont Amazon EC2. Les deux types de lancement s'intègrent CloudWatch , mais les configurations et le support varient. Les sections suivantes vous aident à comprendre comment les utiliser CloudWatch pour la journalisation et la surveillance sur Amazon ECS. **Topics** + [Configuration CloudWatch avec un type de lancement EC2](configure-cloudwatch-ec2-launch-type.md) + [Journaux de conteneurs Amazon ECS pour les types de lancement EC2 et Fargate](ec2-fargate-logs.md) + [Utilisation du routage personnalisé des journaux avec FireLens pour Amazon ECS](firelens-custom-log-routing.md) + [Métriques pour Amazon ECS](ecs-metrics.md) # Configuration CloudWatch avec un type de lancement EC2 Avec un type de lancement EC2, vous mettez en service un cluster Amazon ECS d'instances EC2 qui utilisent l' CloudWatchagent pour la journalisation et la surveillance. Une AMI optimisée pour Amazon ECS est préinstallée avec l'[agent de conteneur Amazon ECS](https://docs.aws.amazon.com//AmazonECS/latest/developerguide/ECS_agent.html) et fournit des CloudWatch métriques pour le cluster Amazon ECS. Ces mesures par défaut sont incluses dans le coût d'Amazon ECS, mais la configuration par défaut d'Amazon ECS ne surveille pas les fichiers journaux ni les mesures supplémentaires (par exemple, l'espace disque disponible). Vous pouvez utiliser le AWS Management Console pour approvisionner un cluster Amazon ECS avec le type de lancement EC2. Cela crée une CloudFormation pile qui déploie un Amazon EC2 Auto Scaling groupe avec une configuration de lancement. Toutefois, cette approche signifie que vous ne pouvez pas choisir une AMI personnalisée ou personnaliser la configuration de lancement avec des paramètres différents ou des scripts de démarrage supplémentaires. Pour surveiller des journaux et des métriques supplémentaires, vous devez installer l' CloudWatch agent sur vos instances de conteneur Amazon ECS. Vous pouvez utiliser l'approche d'installation pour les instances EC2 décrite dans la [Installation de l' CloudWatch agent à l'aide de Systems Manager Distributor et State Manager](install-cloudwatch-systems-manager.md) section de ce guide. Cependant, l'AMI Amazon ECS n'inclut pas l'agent Systems Manager requis. Vous devez utiliser une configuration de lancement personnalisée avec un script de données utilisateur qui installe l'agent Systems Manager lorsque vous créez votre cluster Amazon ECS. Cela permet à vos instances de conteneur de s'enregistrer auprès de Systems Manager et d'appliquer les associations State Manager pour installer, configurer et mettre à jour l' CloudWatch agent. Lorsque State Manager exécute et met à jour la configuration de votre CloudWatch agent, il applique également votre configuration standardisée au niveau du système pour CloudWatch Amazon EC2. Vous pouvez également stocker des CloudWatch configurations standardisées pour Amazon ECS dans le compartiment S3 correspondant à votre CloudWatch configuration et les appliquer automatiquement avec State Manager. Vous devez vous assurer que le rôle ou le profil d'instance IAM appliqué à vos instances de conteneur Amazon ECS inclut les exigences `CloudWatchAgentServerPolicy` et `AmazonSSMManagedInstanceCore` les politiques. Vous pouvez utiliser le modèle [ecs\$1cluster\$1with\$1cloudwatch\$1linux.yaml pour CloudFormation provisionner](https://github.com/aws-samples/logging-monitoring-apg-guide-examples/blob/main/examples/ecs/ecs_cluster_with_cloudwatch_linux.yaml) des clusters Amazon ECS basés sur Linux. Ce modèle crée un cluster Amazon ECS avec une configuration de lancement personnalisée qui installe Systems Manager et déploie une CloudWatch configuration personnalisée pour surveiller les fichiers journaux spécifiques à Amazon ECS. Vous devez capturer les journaux suivants pour vos instances de conteneur Amazon ECS, ainsi que vos journaux d'instance EC2 standard : + **Résultat de démarrage de l'agent Amazon ECS** : `/var/log/ecs/ecs-init.log` + **Sortie de l'agent Amazon ECS** : `/var/log/ecs/ecs-agent.log` + Journal des **demandes du fournisseur d'informations d'identification IAM** — `/var/log/ecs/audit.log` Pour plus d'informations sur le niveau de sortie, le formatage et les options de configuration supplémentaires, consultez [les emplacements des fichiers journaux Amazon](https://docs.aws.amazon.com//AmazonECS/latest/developerguide/logs.html) ECS dans la documentation Amazon ECS. **Important** L'installation ou la configuration de l'agent n'est pas requise pour le type de lancement Fargate, car vous n'exécutez ni ne gérez les instances de conteneur EC2. Les instances de conteneur Amazon ECS doivent utiliser le dernier agent de conteneur optimisé AMIs et optimisé pour Amazon ECS. AWS stocke les paramètres publics du magasin de paramètres Systems Manager avec les informations de l'AMI optimisées pour Amazon ECS, y compris l'ID de l'AMI. Vous pouvez récupérer l'AMI optimisée la plus récente depuis le magasin de paramètres en utilisant le [format de paramètres du magasin de paramètres](https://docs.aws.amazon.com//AmazonECS/latest/developerguide/retrieve-ecs-optimized_AMI.html) pour Amazon ECS optimisé AMIs. Vous pouvez faire référence au paramètre public Parameter Store qui fait référence à l'AMI la plus récente ou à une version d'AMI spécifique dans vos CloudFormation modèles. AWS fournit les mêmes paramètres de magasin de paramètres dans chaque région prise en charge. Cela signifie que les CloudFormation modèles faisant référence à ces paramètres peuvent être réutilisés entre les régions et les comptes sans que l'AMI ne soit mise à jour. Vous pouvez contrôler le déploiement de la nouvelle version d'Amazon ECS AMIs dans votre organisation en vous référant à une version spécifique, ce qui vous permet d'empêcher l'utilisation d'une nouvelle AMI optimisée pour Amazon ECS tant que vous ne l'avez pas testée. # Journaux de conteneurs Amazon ECS pour les types de lancement EC2 et Fargate Amazon ECS utilise une définition de tâche pour déployer et gérer des conteneurs sous forme de tâches et de services. Vous configurez les conteneurs que vous souhaitez lancer dans votre cluster Amazon ECS dans le cadre d'une définition de tâche. La journalisation est configurée avec un pilote de journal au niveau du conteneur. Plusieurs options de pilote de journal fournissent à vos conteneurs différents systèmes de journalisation (par exemple `awslogs``fluentd`,`gelf`,`json-file`,`journald`,`logentries`, `splunk``syslog`, ou`awsfirelens`) selon que vous utilisez le type de lancement EC2 ou Fargate. Le type de lancement Fargate fournit un sous-ensemble des options `awslogs` de pilote de journal suivantes :, et. `splunk` `awsfirelens` AWS fournit le pilote de `awslogs` journal pour capturer et transmettre la sortie du conteneur à CloudWatch Logs. Les paramètres du pilote de journal vous permettent de personnaliser le groupe de journaux, la région et le préfixe du flux de journaux, ainsi que de nombreuses autres options. Le nom par défaut pour les groupes de journaux et l'option utilisée par l'option **Configuration automatique CloudWatch des journaux** sur le AWS Management Console sont`/ecs/`. Le nom du flux de journal utilisé par Amazon ECS est au `//` format suivant. Nous vous recommandons d'utiliser un nom de groupe qui regroupe vos journaux en fonction des besoins de votre organisation. Dans le tableau suivant, les `image_name` et `image_tag` sont inclus dans le nom du flux de log. | | | | --- |--- | | Nom du groupe de journaux | ///// | | Préfixe du nom du flux de log | `//` | Ces informations sont également disponibles dans la définition de la tâche. Cependant, les tâches sont régulièrement mises à jour avec de nouvelles révisions, ce qui signifie que la définition de tâche peut avoir utilisé une version différente `image_name` de `image_tag` celle que la définition de tâche utilise actuellement. Pour plus d'informations et pour des suggestions de dénomination, consultez la [Planification de votre CloudWatch déploiement](planning-cloudwatch-deployment.md) section de ce guide. Si vous utilisez un CI/CD) pipeline or automated process, you can create a new task definition revision for your application with each new Docker image build. For example, you can include the Docker image name, image tag, GitHub revision, or other important information in your task definition revision and logging configuration as a part of your CI/CD processus (processus) d'intégration et de livraison continues. # Utilisation du routage personnalisé des journaux avec FireLens pour Amazon ECS FireLens pour Amazon ECS vous permet d'acheminer les journaux vers [Fluentd](https://www.fluentd.org/) ou [Fluent Bit](https://docs.fluentbit.io/manual) afin que vous puissiez envoyer directement les journaux des conteneurs vers les AWS services et les destinations du réseau de AWS partenaires (APN) et prendre en charge l'expédition des journaux vers Logs. CloudWatch AWS fournit une [image Docker pour Fluent Bit](https://docs.aws.amazon.com//AmazonECS/latest/developerguide/firelens-using-fluentbit.html) avec des plugins préinstallés pour Amazon Kinesis Data Streams, Amazon Data Firehose et Logs. CloudWatch Vous pouvez utiliser le pilote de FireLens journal au lieu du pilote de `awslogs` journal pour une personnalisation et un contrôle accrus des journaux envoyés à CloudWatch Logs. Par exemple, vous pouvez utiliser le pilote de FireLens journal pour contrôler le format de sortie du journal. Cela signifie que les CloudWatch journaux d'un conteneur Amazon ECS sont automatiquement formatés sous forme d'objets JSON et incluent des propriétés au format JSON pour`ecs_cluster`,,, `ecs_task_arn``ecs_task_definition`, `container_id` et. `container_name` `ec2_instance_id` L'hôte fluide est exposé à votre conteneur via les variables d'`FLUENT_PORT`environnement `FLUENT_HOST` et lorsque vous spécifiez le `awsfirelens` pilote. Cela signifie que vous pouvez vous connecter directement au routeur de journalisation à partir de votre code en utilisant les bibliothèques Fluent Logger. Par exemple, votre application peut inclure la `fluent-logger-python` bibliothèque permettant de se connecter à Fluent Bit en utilisant les valeurs disponibles à partir des variables d'environnement. Si vous choisissez de l'utiliser FireLens pour Amazon ECS, vous pouvez configurer les mêmes paramètres que le pilote de `awslogs` journal [et utiliser d'autres paramètres également](https://github.com/aws/amazon-cloudwatch-logs-for-fluent-bit). Par exemple, vous pouvez utiliser la définition de tâche Amazon ECS [ecs-task-nginx-firelense.json](https://github.com/aws-samples/logging-monitoring-apg-guide-examples/blob/main/examples/ecs/ecs-task-nginx-firelense.json) qui lance un serveur NGINX configuré pour être utilisé FireLens pour la connexion à. CloudWatch Il lance également un conteneur FireLens Fluent Bit en tant que sidecar pour l'exploitation forestière. # Métriques pour Amazon ECS [Amazon ECS fournit des CloudWatch métriques standard](https://docs.aws.amazon.com//AmazonECS/latest/developerguide/cloudwatch-metrics.html) (par exemple, l'utilisation du processeur et de la mémoire) pour les types de lancement EC2 et Fargate au niveau du cluster et du service avec l'agent de conteneur Amazon ECS. Vous pouvez également capturer des métriques pour vos services, tâches et conteneurs à l'aide de CloudWatch Container Insights, ou capturer vos propres métriques de conteneur personnalisées à l'aide du format de métrique intégré. Container Insights est une CloudWatch fonctionnalité qui fournit des mesures telles que l'utilisation du processeur, l'utilisation de la mémoire, le trafic réseau et le stockage au niveau du cluster, de l'instance de conteneur, du service et des tâches. Container Insights crée également des tableaux de bord automatiques qui vous aident à analyser les services et les tâches, et à voir l'utilisation moyenne de la mémoire ou du processeur au niveau du conteneur. Container Insights publie des métriques personnalisées dans l'espace de [noms `ECS/ContainerInsights` personnalisé](https://docs.aws.amazon.com//AmazonECS/latest/developerguide/cloudwatch-metrics.html) que vous pouvez utiliser pour les graphiques, les alarmes et les tableaux de bord. Vous pouvez activer les métriques Container Insight en activant Container Insights pour chaque cluster Amazon ECS individuel. Si vous souhaitez également consulter les métriques au niveau de l'instance de conteneur, vous pouvez [lancer l' CloudWatch agent en tant que conteneur de démons sur votre cluster Amazon ECS](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/deploy-container-insights-ECS-instancelevel.html). Vous pouvez utiliser le CloudFormation modèle [cwagent-ecs-instance-metric-cfn.yaml](https://github.com/aws-samples/logging-monitoring-apg-guide-examples/blob/main/examples/ecs/cwagent-ecs-instance-metric-cfn.yaml) pour déployer l'agent en CloudWatch tant que service Amazon ECS. Il est important de noter que cet exemple suppose que vous avez créé une configuration d' CloudWatchagent personnalisée appropriée et que vous l'avez stockée dans Parameter Store avec la clé`ecs-cwagent-daemon-service`. L'[CloudWatchagent](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-ECS.html) déployé en tant que conteneur de démons pour CloudWatch Container Insights inclut des métriques supplémentaires relatives au disque, à la mémoire et au processeur, telles que `instance_cpu_reserved_capacity` et `instance_memory_reserved_capacity` avec les `InstanceId` dimensions `ClusterName``ContainerInstanceId`,. Les métriques au niveau de l'instance de conteneur sont mises en œuvre par Container Insights en utilisant le format de métrique CloudWatch intégré. Vous pouvez configurer des métriques supplémentaires au niveau du système pour vos instances de conteneur Amazon ECS en utilisant l'approche décrite dans la [Configurer State Manager et Distributor pour le déploiement et la configuration de l' CloudWatch agent](install-cloudwatch-systems-manager.md#set-up-systems-manager-distributor) section de ce guide. ## Création de métriques d'application personnalisées dans Amazon ECS Vous pouvez créer des métriques personnalisées pour vos applications en utilisant le [format de métrique CloudWatch intégré](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format.html). Le pilote de `awslogs` journal peut interpréter les instructions de format métrique CloudWatch intégrées. Dans l'exemple suivant, la variable d'`CW_CONFIG_CONTENT`environnement est définie sur le contenu du paramètre `cwagentconfig` Systems Manager Parameter Store. Vous pouvez exécuter l'agent avec cette configuration de base pour le configurer en tant que point de terminaison au format métrique intégré. Toutefois, ce n'est plus nécessaire. ``` { "logs": { "metrics_collected": { "emf": { } } } } ``` Si vous déployez Amazon ECS sur plusieurs comptes et régions, vous pouvez utiliser un AWS Secrets Manager secret pour stocker votre CloudWatch configuration et configurer la politique secrète afin de la partager avec votre organisation. Vous pouvez utiliser l'option secrets dans votre définition de tâche pour définir la `CW_CONFIG_CONTENT` variable. Vous pouvez utiliser les [bibliothèques de formats métriques intégrés open source AWS](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format_Libraries.html) fournies dans votre application et spécifier la variable d'`AWS_EMF_AGENT_ENDPOINT`environnement à connecter au conteneur annexe de votre CloudWatch agent agissant comme un point de terminaison au format métrique intégré. Par exemple, vous pouvez utiliser l'exemple d'application Python [ecs\$1cw\$1emf\$1example](https://github.com/aws-samples/logging-monitoring-apg-guide-examples/tree/main/examples/ecs/ecs_cw_emf_example) pour envoyer des métriques au format métrique intégré à CloudWatch un conteneur d'agent configuré comme point de terminaison au format métrique intégré. Le [plugin Fluent Bit](https://github.com/aws/amazon-cloudwatch-logs-for-fluent-bit) pour CloudWatch peut également être utilisé pour envoyer des messages au format métrique intégré. Vous pouvez également utiliser l'exemple d'application Python [ecs\$1firelense\$1emf\$1example](https://github.com/aws-samples/logging-monitoring-apg-guide-examples/tree/main/examples/ecs/ecs_firelense_emf_example) pour envoyer des métriques au format métrique intégré à un conteneur annexe Firelens for Amazon ECS. Si vous ne souhaitez pas utiliser le format de métrique intégré, vous pouvez créer et mettre à jour CloudWatch des métriques via l'[AWS API](https://docs.aws.amazon.com//AmazonCloudWatch/latest/APIReference/Welcome.html) ou le [AWS SDK](https://aws.amazon.com/developer/tools/). Nous ne recommandons pas cette approche, sauf si vous avez un cas d'utilisation spécifique, car elle ajoute des frais de maintenance et de gestion à votre code.