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 dans Amazon EKS
Amazon Elastic Kubernetes Service (Amazon EKS) CloudWatch s'intègre aux journaux pour le plan de contrôle Kubernetes. Le plan de contrôle est fourni en tant que service géré par Amazon EKS et vous pouvez [activer la journalisation sans installer d' CloudWatchagent](https://docs.aws.amazon.com//eks/latest/userguide/control-plane-logs.html). L' CloudWatch agent peut également être déployé pour capturer les journaux des nœuds et des conteneurs Amazon EKS. [Fluent Bit et Fluentd](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/Container-Insights-EKS-logs.html) sont également pris en charge pour envoyer les journaux de vos conteneurs à CloudWatch Logs.
CloudWatch Container Insights fournit une solution complète de surveillance des métriques pour Amazon EKS au niveau du cluster, du nœud, du pod, de la tâche et du service. Amazon EKS prend également en charge plusieurs options pour la capture des métriques avec [Prometheus](https://prometheus.io/). Le plan de contrôle Amazon EKS [fournit un point de terminaison de métriques](https://docs.aws.amazon.com//eks/latest/userguide/prometheus.html) qui expose les métriques au format Prometheus. Vous pouvez déployer Prometheus dans votre cluster Amazon EKS pour utiliser ces métriques.
Vous pouvez également [configurer l' CloudWatch agent pour extraire les métriques Prometheus](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/ContainerInsights-Prometheus-Setup-configure.html) et CloudWatch créer des métriques, en plus de consommer d'autres points de terminaison Prometheus. [La surveillance de Container Insights pour Prometheus](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/ContainerInsights-Prometheus.html) permet également de découvrir et de capturer automatiquement les métriques Prometheus à partir de charges de travail et de systèmes conteneurisés pris en charge.
Vous pouvez installer et configurer l' CloudWatch agent sur vos nœuds Amazon EKS, de la même manière que l'approche utilisée pour Amazon EC2 avec Distributor et State Manager, afin d'aligner vos nœuds Amazon EKS sur les configurations standard de journalisation et de surveillance de votre système.
# Journalisation pour Amazon EKS
La journalisation Kubernetes peut être divisée en journalisation du plan de contrôle, journalisation des nœuds et journalisation des applications. Le [plan de contrôle Kubernetes](https://kubernetes.io/docs/concepts/overview/components/#control-plane-components) est un ensemble de composants qui gèrent les clusters Kubernetes et produisent des journaux utilisés à des fins d'audit et de diagnostic. Avec Amazon EKS, vous pouvez [activer les journaux pour les différents composants du plan de contrôle](https://docs.aws.amazon.com//eks/latest/userguide/control-plane-logs.html) et les envoyer à CloudWatch.
Kubernetes exécute également des composants système tels que `kubelet` et `kube-proxy` sur chaque nœud Kubernetes qui exécute vos pods. Ces composants rédigent des journaux au sein de chaque nœud et vous pouvez configurer CloudWatch Container Insights pour capturer ces journaux pour chaque nœud Amazon EKS.
Les conteneurs sont regroupés sous forme de [pods](https://kubernetes.io/docs/concepts/workloads/pods/) au sein d'un cluster Kubernetes et sont planifiés pour s'exécuter sur vos nœuds Kubernetes. La plupart des applications conteneurisées écrivent en sortie standard et en erreur standard, et le moteur de conteneur redirige la sortie vers un pilote de journalisation. Dans Kubernetes, les journaux des conteneurs se trouvent dans le `/var/log/pods` répertoire d'un nœud. Vous pouvez configurer CloudWatch Container Insights pour capturer ces journaux pour chacun de vos pods Amazon EKS.
## Journalisation de plan de contrôle d'Amazon EKS
Un cluster Amazon EKS consiste en un plan de contrôle à haute disponibilité à locataire unique pour votre cluster Kubernetes et les nœuds Amazon EKS qui exécutent vos conteneurs. Les nœuds du plan de contrôle s'exécutent dans un compte géré par AWS. Les nœuds du plan de contrôle du cluster Amazon EKS sont intégrés CloudWatch et vous pouvez activer la journalisation pour des composants spécifiques du plan de contrôle.
Des journaux sont fournis pour chaque instance de composant du plan de contrôle Kubernetes. AWS gère l'état de santé des nœuds de votre plan de contrôle et fournit un [accord de niveau de service (SLA) pour](https://aws.amazon.com//eks/sla/) le point de terminaison Kubernetes.
## Journalisation des applications et des nœuds Amazon EKS
Nous vous recommandons d'utiliser [CloudWatchContainer Insights](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/Container-Insights-setup-logs.html) pour capturer les journaux et les métriques pour Amazon EKS. Container Insights implémente des métriques au niveau du cluster, du nœud et du pod avec l' CloudWatch agent, et Fluent Bit ou Fluentd pour la capture des journaux. CloudWatch Container Insights fournit également des tableaux de bord automatiques avec des vues en couches de vos CloudWatch indicateurs capturés. Container Insights est déployé sous forme CloudWatch DaemonSet de Fluent Bit DaemonSet qui s'exécute sur chaque nœud Amazon EKS. Les nœuds Fargate ne sont pas pris en charge par Container Insights car ils sont gérés AWS par et ne sont pas pris en charge. DaemonSets La journalisation Fargate pour Amazon EKS est traitée séparément dans ce guide.
Le tableau suivant indique les CloudWatch groupes de journaux et les journaux capturés par la [configuration de capture de journaux Fluentd ou Fluent Bit par défaut](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/Container-Insights-setup-logs-FluentBit.html) pour Amazon EKS.
| | |
| --- |--- |
| /aws/containerinsights/Cluster\$1Name/application | Tous les fichiers journaux sont enregistrés/var/log/containers. Ce répertoire fournit des liens symboliques vers tous les journaux des conteneurs Kubernetes dans la structure du /var/log/pods répertoire. Cela capture les journaux du conteneur de votre application écrivant dans stdout oustderr. Il inclut également des journaux pour les conteneurs du système Kubernetes tels queaws-vpc-cni-init, etkube-proxy. coreDNS |
| /aws/containerinsights/Cluster\$1Name/host | Journaux provenant de /var/log/dmesg/var/log/secure, et/var/log/messages. |
| /aws/containerinsights/Cluster\$1Name/dataplane | Les journaux dans /var/log/journal pour kubelet.service, kubeproxy.service et docker.service. |
Si vous ne souhaitez pas utiliser Container Insights avec Fluent Bit ou Fluentd pour la journalisation, vous pouvez capturer les journaux des nœuds et des conteneurs avec l' CloudWatch agent installé sur les nœuds Amazon EKS. Les nœuds Amazon EKS sont des instances EC2, ce qui signifie que vous devez les inclure dans votre approche standard de journalisation au niveau du système pour Amazon EC2. Si vous installez l' CloudWatch agent à l'aide de Distributor et State Manager, les nœuds Amazon EKS sont également inclus dans l'installation, la configuration et la mise à jour de l' CloudWatch agent.
Le tableau suivant indique les journaux spécifiques à Kubernetes que vous devez capturer si vous n'utilisez pas Container Insights avec Fluent Bit ou Fluentd pour la journalisation.
| | |
| --- |--- |
| /var/log/containers | Ce répertoire fournit des liens symboliques vers tous les journaux des conteneurs Kubernetes dans la structure du /var/log/pods répertoire. Cela capture efficacement les journaux du conteneur de votre application qui écrivent dans stdout oustderr. Cela inclut les journaux pour les conteneurs du système Kubernetes tels queaws-vpc-cni-init, etkube-proxy. coreDNS Important : cela n'est pas obligatoire si vous utilisez Container Insights. |
| var/log/aws-routed-eni/ipamd.log/var/log/aws-routed-eni/plugin.log | Les journaux du démon L-IPAM se trouvent ici |
Vous devez vous assurer que les nœuds Amazon EKS installent et configurent l' CloudWatch agent pour envoyer les journaux et mesures appropriés au niveau du système. Cependant, l'AMI optimisée pour Amazon EKS n'inclut pas l'agent Systems Manager. À l'aide de [modèles de lancement](https://docs.aws.amazon.com//eks/latest/userguide/launch-templates.html), vous pouvez automatiser l'installation de l'agent Systems Manager et une CloudWatch configuration par défaut qui capture les journaux importants spécifiques à Amazon EKS à l'aide d'un script de démarrage implémenté via la section des données utilisateur. Les nœuds Amazon EKS sont déployés à l'aide d'un groupe Auto Scaling en tant que [groupe de nœuds gérés](https://docs.aws.amazon.com//eks/latest/userguide/managed-node-groups.html) ou en tant que [nœuds autogérés](https://docs.aws.amazon.com//eks/latest/userguide/worker.html).
Avec les groupes de nœuds gérés, vous fournissez un [modèle de lancement](https://docs.aws.amazon.com//eks/latest/userguide/launch-templates.html) qui inclut la section des données utilisateur pour automatiser l'installation et la CloudWatch configuration de l'agent Systems Manager. Vous pouvez personnaliser et utiliser le modèle [amazon\$1eks\$1managed\$1node\$1group\$1launch\$1config.yaml](https://github.com/aws-samples/logging-monitoring-apg-guide-examples/blob/main/examples/eks/amazon_eks_managed_node_group_launch_config.yaml) pour créer un CloudFormation modèle de lancement qui installe l'agent Systems Manager, l'agent, et ajoute également une configuration de journalisation spécifique à Amazon EKS dans le répertoire de configuration. CloudWatch CloudWatch Ce modèle peut être utilisé pour mettre à jour votre modèle de lancement de groupes de nœuds gérés Amazon EKS avec une approche infrastructure-as-code (iAc). Chaque mise à jour du CloudFormation modèle fournit une nouvelle version du modèle de lancement. Vous pouvez ensuite mettre à jour le groupe de nœuds pour utiliser la nouvelle version du modèle et demander au [processus de gestion du cycle](https://docs.aws.amazon.com//eks/latest/userguide/managed-node-update-behavior.html) de vie de mettre à jour vos nœuds sans interruption de service. Assurez-vous que le rôle IAM et le profil d'instance appliqués à votre groupe de nœuds gérés incluent les politiques `AmazonSSMManagedInstanceCore` AWS gérées `CloudWatchAgentServerPolicy` et.
Avec les nœuds autogérés, vous provisionnez et gérez directement le cycle de vie et la stratégie de mise à jour de vos nœuds Amazon EKS. [Les nœuds autogérés vous permettent d'exécuter des nœuds Windows sur votre cluster Amazon EKS et sur [Bottlerocket, entre](https://aws.amazon.com//bottlerocket/) autres options.](https://docs.aws.amazon.com//eks/latest/userguide/eks-compute.html) Vous pouvez utiliser CloudFormation pour déployer des nœuds autogérés dans vos clusters Amazon EKS, ce qui signifie que vous pouvez utiliser une approche iAc et une approche de modification gérée pour vos clusters Amazon EKS. AWS fournit le CloudFormation modèle [amazon-eks-nodegroup.yaml](https://github.com/aws-samples/logging-monitoring-apg-guide-examples/blob/main/examples/eks/amazon-eks-nodegroup.yaml) que vous pouvez utiliser tel quel ou personnaliser. Le modèle fournit toutes les ressources requises pour les nœuds Amazon EKS d'un cluster (par exemple, un rôle IAM distinct, un groupe de sécurité, un groupe Amazon EC2 Auto Scaling et un modèle de lancement). Le CloudFormation modèle [amazon-eks-nodegroup.yaml](https://github.com/aws-samples/logging-monitoring-apg-guide-examples/blob/main/examples/eks/amazon-eks-nodegroup.yaml) est une version mise à jour qui installe l'agent Systems Manager requis, l' CloudWatch agent, et ajoute également une configuration de journalisation spécifique à Amazon EKS dans le CloudWatch répertoire de configuration.
## Journalisation pour Amazon EKS sur Fargate
Avec Amazon EKS sur Fargate, vous pouvez déployer des pods sans allouer ni gérer vos nœuds Kubernetes. Il n'est donc plus nécessaire de capturer des journaux au niveau du système pour vos nœuds Kubernetes. Pour capturer les journaux de vos pods Fargate, vous pouvez utiliser Fluent Bit pour les transférer directement vers. CloudWatch Cela vous permet d'acheminer automatiquement les journaux CloudWatch sans autre configuration ou vers un conteneur annexe pour vos pods Amazon EKS sur Fargate. Pour plus d'informations à ce sujet, consultez [Fargate logging](https://docs.aws.amazon.com//eks/latest/userguide/fargate-logging.html) dans la documentation Amazon EKS [et Fluent Bit pour Amazon](https://aws.amazon.com//blogs/containers/fluent-bit-for-amazon-eks-on-aws-fargate-is-here/) EKS sur le blog. AWS Cette solution capture les flux `STDOUT` et `STDERR` input/output (E/S) de votre conteneur et les envoie CloudWatch via Fluent Bit, sur la base de la configuration Fluent Bit établie pour le cluster Amazon EKS sur Fargate.
# Métriques pour Amazon EKS et Kubernetes
Kubernetes fournit une API de métriques qui vous permet d'accéder aux métriques d'utilisation des ressources (par exemple, l'utilisation du processeur et de la mémoire pour les nœuds et les pods), mais l'API fournit uniquement des point-in-time informations et non des métriques historiques. [Le serveur de [métriques Kubernetes est](https://github.com/kubernetes-sigs/metrics-server) généralement utilisé pour les déploiements Amazon EKS et Kubernetes pour agréger les métriques, fournir des informations historiques à court terme sur les métriques et prendre en charge des fonctionnalités telles que Horizontal Pod Autoscaler.](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/)
Amazon EKS expose les métriques du plan de contrôle via le serveur d'API Kubernetes au [format Prometheus et peut capturer et ingérer](https://docs.aws.amazon.com//eks/latest/userguide/prometheus.html) ces métriques. CloudWatch CloudWatch et Container Insights peut également être configuré pour fournir une capture, une analyse et des alarmes complètes de mesures pour vos nœuds et pods Amazon EKS.
## Métriques du plan de contrôle Kubernetes
Kubernetes expose les métriques du plan de contrôle au format Prometheus en utilisant le point de terminaison de l'API HTTP. `/metrics` Vous devez installer [Prometheus](https://prometheus.io/) dans votre cluster Kubernetes pour représenter graphiquement et visualiser ces métriques dans un navigateur Web. Vous pouvez également [ingérer les métriques exposées par le](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/ContainerInsights-Prometheus-Setup-configure.html#ContainerInsights-Prometheus-Setup-new-exporters) serveur d'API Kubernetes dans. CloudWatch
## Métriques relatives aux nœuds et au système pour Kubernetes
Kubernetes fournit le module de [serveur de mesures Prometheus que vous pouvez déployer et exécuter sur vos clusters](https://github.com/kubernetes-sigs/metrics-server) [Kubernetes pour obtenir des statistiques sur le processeur et](https://docs.aws.amazon.com//eks/latest/userguide/metrics-server.html) la mémoire au niveau des clusters, des nœuds et des pods. Ces mesures sont utilisées avec le [Horizontal Pod Autoscaler et le [Vertical Pod](https://docs.aws.amazon.com/eks/latest/userguide/vertical-pod-autoscaler.html) Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/). CloudWatch peut également fournir ces métriques.
Vous devez installer le serveur Kubernetes Metrics si vous utilisez le tableau de [bord Kubernetes](https://github.com/kubernetes/dashboard) ou les autoscalers horizontaux et verticaux. Le tableau de bord Kubernetes vous permet de parcourir et de configurer votre cluster Kubernetes, vos nœuds, vos pods et la configuration associée, et de visualiser les métriques du processeur et de la mémoire à partir du serveur de métriques Kubernetes.
Les métriques fournies par le serveur de métriques Kubernetes ne peuvent pas être utilisées à des fins autres que le dimensionnement automatique (par exemple, pour la surveillance). Les métriques sont destinées à l' point-in-timeanalyse et non à l'analyse historique. Le tableau de bord Kubernetes déploie les métriques de stockage `dashboard-metrics-scraper` à partir du serveur de métriques Kubernetes pendant une courte période.
Container Insights utilise une version conteneurisée de l' CloudWatch agent qui s'exécute dans un Kubernetes DaemonSet pour découvrir tous les conteneurs en cours d'exécution dans un cluster et fournir des métriques au niveau des nœuds. Il collecte des données de performance à chaque niveau de la pile de performances. Vous pouvez utiliser le Quick Start à partir de AWS Quick Starts ou configurer Container Insights séparément. Le Quick Start configure la surveillance des métriques avec l' CloudWatch agent et la journalisation avec Fluent Bit, de sorte que vous n'avez besoin de le déployer qu'une seule fois pour la journalisation et la surveillance.
Les nœuds Amazon EKS étant des instances EC2, vous devez capturer les métriques au niveau des systèmes, en plus des métriques capturées par Container Insights, en utilisant les normes que vous avez définies pour Amazon EC2. Vous pouvez utiliser la même 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 pour installer et configurer l' CloudWatch agent pour vos clusters Amazon EKS. Vous pouvez mettre à jour votre fichier de CloudWatch configuration spécifique à Amazon EKS pour inclure des métriques ainsi que la configuration de journal spécifique à Amazon EKS.
[L' CloudWatch agent prenant en charge Prometheus peut automatiquement découvrir et extraire les métriques Prometheus à partir de charges de travail et de systèmes conteneurisés pris en charge.](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/ContainerInsights-Prometheus.html) Il les ingère sous forme de CloudWatch journaux au format métrique intégré à des fins d'analyse avec CloudWatch Logs Insights et crée automatiquement CloudWatch des métriques.
**Important**
Vous devez [déployer une version spécialisée](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/ContainerInsights-Prometheus-Setup.html#ContainerInsights-Prometheus-Setup-install-agent) de l' CloudWatch agent pour collecter les métriques Prometheus. Il s'agit d'un agent distinct de l' CloudWatch agent déployé pour Container Insights. Vous pouvez utiliser l'exemple d'application Java [prometheus\$1jmx](https://github.com/aws-samples/logging-monitoring-apg-guide-examples/tree/main/examples/eks/prometheus_jmx), qui inclut les fichiers de déploiement et de configuration pour le déploiement de l'agent CloudWatch et du pod Amazon EKS pour démontrer la découverte des métriques Prometheus. Pour plus d'informations, consultez la section [Configurer un Java/JMX exemple de charge de travail sur Amazon EKS et Kubernetes](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/ContainerInsights-Prometheus-Sample-Workloads-javajmx.html) dans la documentation. CloudWatch Vous pouvez également configurer l' CloudWatch agent pour qu'il capture les métriques d'autres cibles Prometheus exécutées dans votre cluster Amazon EKS.
## Métriques d'application
Vous pouvez créer vos propres métriques personnalisées avec le [format de métrique CloudWatch intégré.](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format.html) Pour ingérer des instructions au format métrique intégré, vous devez envoyer des entrées au format métrique intégré à un point de terminaison au format métrique intégré. L' CloudWatch agent peut être configuré en tant que [conteneur annexe dans votre pod Amazon EKS](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format_Generation_CloudWatch_Agent.html). La configuration de l' CloudWatch agent est stockée sous forme de Kubernetes ConfigMap et lue par le conteneur annexe de votre CloudWatch agent pour démarrer le point de terminaison au format métrique intégré.
Vous pouvez également configurer votre application en tant que cible Prometheus et configurer CloudWatch l'agent, avec l'assistance de Prometheus, pour découvrir, extraire et intégrer vos indicateurs. CloudWatch Par exemple, vous pouvez utiliser l'[exportateur JMX open source](https://github.com/prometheus/jmx_exporter) avec vos applications Java pour exposer les haricots JMX destinés à la consommation de Prometheus par l'agent. CloudWatch
Si vous ne souhaitez pas utiliser le format de métrique intégré, vous pouvez également créer et mettre à jour des CloudWatch métriques à l'aide de l'[AWS API](https://docs.aws.amazon.com//AmazonCloudWatch/latest/APIReference/Welcome.html) ou du [AWS SDK](https://aws.amazon.com/developer/tools/). Cependant, nous ne recommandons pas cette approche, car elle mélange la surveillance et la logique de l'application.
## Métriques pour Amazon EKS sur Fargate
Fargate provisionne automatiquement les nœuds Amazon EKS pour exécuter vos pods Kubernetes. Vous n'avez donc pas besoin de surveiller et de collecter des métriques au niveau des nœuds. Cependant, vous devez surveiller les métriques des pods exécutés sur vos nœuds Amazon EKS sur Fargate. Container Insights n'est actuellement pas disponible pour Amazon EKS sur Fargate car il nécessite les fonctionnalités suivantes qui ne sont pas prises en charge actuellement :
+ DaemonSets ne sont pas pris en charge actuellement. Container Insights est déployé en exécutant l' CloudWatch agent DaemonSet en tant que nœud de cluster.
+ HostPath les volumes persistants ne sont pas pris en charge. Le conteneur CloudWatch d'agents utilise les volumes persistants HostPath comme condition préalable à la collecte des données métriques du conteneur.
+ Fargate empêche les conteneurs privilégiés et l'accès aux informations de l'hôte.
Vous pouvez utiliser le [routeur de log intégré auquel Fargate](https://docs.aws.amazon.com//eks/latest/userguide/fargate-logging.html) envoie des instructions au format métrique intégré. CloudWatch Le routeur de log utilise Fluent Bit, qui possède un CloudWatch plugin qui peut être configuré pour prendre en charge les instructions au format métrique intégrées.
Vous pouvez récupérer et capturer des métriques au niveau des pods pour vos nœuds Fargate en déployant le serveur Prometheus dans votre cluster Amazon EKS afin de recueillir des métriques à partir de vos nœuds Fargate. Prometheus nécessitant un stockage persistant, vous pouvez déployer Prometheus sur Fargate si vous utilisez Amazon Elastic File System (Amazon EFS) pour le stockage persistant. Vous pouvez également déployer Prometheus sur un nœud soutenu par Amazon EC2. Pour plus d'informations, consultez la section [Surveillance d'Amazon EKS sur AWS Fargate l'utilisation de Prometheus et](https://aws.amazon.com//blogs/containers/monitoring-amazon-eks-on-aws-fargate-using-prometheus-and-grafana/) Grafana sur le blog. AWS