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.

Installez l' CloudWatch agent à l'aide du module complémentaire Amazon CloudWatch Observability EKS ou du graphique Helm

Vous pouvez utiliser le module complémentaire Amazon CloudWatch Observability EKS ou le Helm chart Amazon CloudWatch Observability pour installer l' CloudWatch agent et l' Fluent-bit agent sur un cluster Amazon EKS. Vous pouvez également utiliser le diagramme Helm pour installer l' CloudWatch agent et l' Fluent-bit agent sur un cluster Kubernetes qui n'est pas hébergé sur Amazon EKS.

L'utilisation de l'une ou l'autre des méthodes sur un cluster Amazon EKS active à la fois Container Insights pour Amazon EKS et CloudWatch Application Signals par défaut. Ces deux fonctionnalités vous permettent de collecter des métriques d’infrastructure, des données de performance applicative et des journaux de conteneurs provenant du cluster.

À partir de la version v6.2.0-eksbuild.1 ou d'une version ultérieure du module complémentaire, Container Insights avec OpenTelemetry des métriques peut être activé, qui collecte des métriques à l'aide du OpenTelemetry protocole (OTLP) et prend en charge les requêtes ProMQL. Pour de plus amples informations, veuillez consulter OTel Container Insights (recommandé).

Avec Container Insights OpenTelemetry pour Amazon EKS, les métriques de Container Insights sont facturées par Go ingéré ou par observation si vous utilisez Enhanced Container Insights (Classic). Pour Application Signals, la facturation est basée sur les demandes entrantes adressées à vos applications, les demandes sortantes provenant de vos applications et sur chaque objectif de niveau de service (SLO) configuré. Chaque requête entrante reçue génère un signal d’application, et chaque requête sortante effectuée génère un signal d’application. Chaque SLO crée deux signaux d’application par période de mesure. Pour plus d'informations sur la CloudWatch tarification, consultez la page CloudWatch Tarification Amazon.

Les deux méthodes permettent d’activer Container Insights sur les nœuds de calcul Linux et Windows d’un cluster Amazon EKS. Pour activer Container Insights sur Windows, vous devez utiliser la version 1.5.0 ou ultérieure du module complémentaire Amazon EKS ou des Charts de Helm. La vigie applicative n’est pas prise en charge sur Windows dans les clusters Amazon EKS.

Le module complémentaire Amazon CloudWatch Observability EKS est pris en charge sur les clusters Amazon EKS exécutés avec Kubernetes version 1.23 ou ultérieure.

Lorsque vous installez le module complémentaire ou le graphique Helm, vous devez également accorder des autorisations IAM pour permettre à l' CloudWatch agent d'envoyer des métriques, des journaux et des traces à CloudWatch. Il existe deux façons de procéder :

Option 1 : installation à l’aide de l’identité du pod EKS

Si vous utilisez la version 3.1.0 ou ultérieure du module complémentaire, vous pouvez utiliser l’identité du pod EKS pour accorder les autorisations requises au module complémentaire. L’identité du pod EKS est l’option recommandée, car elle offre plusieurs avantages, notamment le moindre privilège, la rotation des informations d’identification et l’auditabilité. De plus, l’utilisation de l’identité du pod EKS vous permet d’installer le module complémentaire EKS dès la création du cluster.

Pour utiliser cette méthode, commencez par suivre les étapes de la section Association d’identité du pod EKS afin de créer le rôle IAM et de configurer l’agent d’identité du pod EKS.

Installez ensuite le module complémentaire Amazon CloudWatch Observability EKS. Pour installer le module complémentaire, vous pouvez utiliser la AWS CLI console Amazon EKS ou Terraform. CloudFormation

AWS CLI

Pour utiliser le plugin AWS CLI pour installer le module complémentaire Amazon CloudWatch Observability EKS

Entrez les commandes suivantes : Remplacez-le my-cluster-name par le nom de votre cluster et remplacez-le 111122223333 par votre identifiant de compte. Remplacez-le my-role par le rôle IAM que vous avez créé lors de l'étape d'association EKS Pod Identity.

aws iam attach-role-policy \
--role-name my-role \
--policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy

aws eks create-addon \
--addon-name amazon-cloudwatch-observability \
--cluster-name my-cluster-name \
--pod-identity-associations serviceAccount=cloudwatch-agent,roleArn=arn:aws:iam::111122223333:role/my-role

Amazon EKS console

Pour utiliser la console Amazon EKS afin d'ajouter le module complémentaire Amazon CloudWatch Observability EKS

1. Ouvrez la console Amazon EKS à l'adresse https://console.aws.amazon.com/eks/home #/clusters.

2. Dans le volet de navigation de gauche, choisissez Clusters.

3. Choisissez le nom du cluster pour lequel vous souhaitez configurer le module complémentaire Amazon CloudWatch Observability EKS.

4. Cliquez sur l'onglet Add-ons.

5. Choisissez Obtenez plus de modules complémentaires.

6. Sur la page Sélectionner des modules complémentaires, procédez comme suit :

   1. Dans la EKS-addons section Amazon, cochez la case Amazon CloudWatch Observability.

   2. Choisissez Suivant.

7. Sur la page Configurer les paramètres des modules complémentaires sélectionnés, procédez comme suit :

   1. Sélectionnez la version que vous souhaitez utiliser.

   2. Pour Add-on y accéder, sélectionnez EKS Pod Identity

   3. Si aucun rôle IAM n’est configuré, sélectionnez Créer un rôle recommandé, puis cliquez sur Suivant jusqu’à ce que vous soyez à l’Étape 3 : nom, vérification et création. Vous pouvez modifier le nom de votre rôle si vous le souhaitez. Sinon, choisissez Créer un rôle, puis revenez à la Add-on page et sélectionnez le rôle IAM que vous venez de créer.

   4. (Facultatif) Vous pouvez développer les paramètres de configuration facultatifs. Si vous sélectionnez Remplacer pour la méthode de résolution des conflits, un ou plusieurs des paramètres du module complémentaire existant peuvent être remplacés par les paramètres du module complémentaire Amazon EKS. Si vous n'activez pas cette option et qu'il y a un conflit avec vos paramètres existants, l'opération échoue. Vous pouvez utiliser le message d'erreur qui en résulte pour résoudre le conflit. Avant de sélectionner cette option, assurez-vous que le module complémentaire Amazon EKS ne gère pas les paramètres que vous devez gérer vous-même.

   5. Choisissez Suivant.

8. Sur la page Vérifier et ajouter, choisissez Créer. Une fois l'installation du module complémentaire terminée, vous pouvez voir le module complémentaire installé.

CloudFormation

Pour utiliser CloudFormation pour installer le module complémentaire Amazon CloudWatch Observability EKS

1. Tout d'abord, exécutez la AWS CLI commande suivante pour associer la politique IAM nécessaire à votre rôle IAM. Remplacez-le my-role par le rôle que vous avez créé lors de l'étape d'association EKS Pod Identity.

   aws iam attach-role-policy \
   --role-name my-role \
   --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy

2. Ensuite, créez lea ressource suivante. Remplacez-le my-cluster-name par le nom de votre cluster, remplacez-le 111122223333 par votre identifiant de compte et remplacez-le my-role par le rôle IAM créé lors de l'étape d'association EKS Pod Identity. Pour plus d'informations, veuillez consulter AWS::EKS::Addon (langue française non garantie).

   {
   "Resources": {
       "EKSAddOn": {
           "Type": "AWS::EKS::Addon",
           "Properties": {
               "AddonName": "amazon-cloudwatch-observability",
               "ClusterName": "my-cluster-name",
               "PodIdentityAssociations": [
                   {
                       "ServiceAccount": "cloudwatch-agent",
                       "RoleArn": "arn:aws:iam::111122223333:role/my-role"
                   }
               ]
           }
       }
   }
   }

Terraform

Pour utiliser Terraform pour installer le module complémentaire Amazon CloudWatch Observability EKS

1. Utilisez ce qui suit. Remplacez-le my-cluster-name par le nom de votre cluster, remplacez-le 111122223333 par votre identifiant de compte et remplacez-le my-service-account-role par le rôle IAM créé lors de l'étape d'association EKS Pod Identity.

   Pour plus d’informations, consultez Ressource : aws_eks_addon dans la documentation Terraform.

2. resource "aws_iam_role_policy_attachment" "CloudWatchAgentServerPolicy" {
     policy_arn = "arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy"
     role       = "my-role"
   }
   
   resource "aws_eks_addon" "example" {
     cluster_name = "my-cluster-name"
     addon_name   = "amazon-cloudwatch-observability"
     pod_identity_associations {
     roleArn = "arn:aws:iam::111122223333:role/my-role"
     serviceAccount = "cloudwatch-agent"
     }
   }

Option 2 : installation avec des autorisations IAM sur les nœuds de travail

Pour utiliser cette méthode, attachez d'abord la politique CloudWatchAgentServerPolicy IAM à vos nœuds de travail en saisissant la commande suivante. Dans cette commande, remplacez-le my-worker-node-role par le rôle IAM utilisé par vos nœuds de travail Kubernetes.

aws iam attach-role-policy \
--role-name my-worker-node-role \
--policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy

Installez ensuite le module complémentaire Amazon CloudWatch Observability EKS. Pour installer le module complémentaire, vous pouvez utiliser la AWS CLI console ou Terraform. CloudFormation

AWS CLI

Pour utiliser le plugin AWS CLI pour installer le module complémentaire Amazon CloudWatch Observability EKS

Entrez la commande suivante. Remplacez my-cluster-name par le nom de votre cluster.

aws eks create-addon --addon-name amazon-cloudwatch-observability --cluster-name my-cluster-name

Amazon EKS console

Pour utiliser la console Amazon EKS afin d'ajouter le module complémentaire Amazon CloudWatch Observability EKS

1. Ouvrez la console Amazon EKS à l'adresse https://console.aws.amazon.com/eks/home #/clusters.

2. Dans le volet de navigation de gauche, choisissez Clusters.

3. Choisissez le nom du cluster pour lequel vous souhaitez configurer le module complémentaire Amazon CloudWatch Observability EKS.

4. Cliquez sur l'onglet Add-ons.

5. Choisissez Obtenez plus de modules complémentaires.

6. Sur la page Sélectionner des modules complémentaires, procédez comme suit :

   1. Dans la EKS-addons section Amazon, cochez la case Amazon CloudWatch Observability.

   2. Choisissez Suivant.

7. Sur la page Configurer les paramètres des modules complémentaires sélectionnés, procédez comme suit :

   1. Sélectionnez la version que vous souhaitez utiliser.

   2. (Facultatif) Vous pouvez développer les paramètres de configuration facultatifs. Si vous sélectionnez Remplacer pour la méthode de résolution des conflits, un ou plusieurs des paramètres du module complémentaire existant peuvent être remplacés par les paramètres du module complémentaire Amazon EKS. Si vous n'activez pas cette option et qu'il y a un conflit avec vos paramètres existants, l'opération échoue. Vous pouvez utiliser le message d'erreur qui en résulte pour résoudre le conflit. Avant de sélectionner cette option, assurez-vous que le module complémentaire Amazon EKS ne gère pas les paramètres que vous devez gérer vous-même.

   3. Choisissez Suivant.

8. Sur la page Vérifier et ajouter, choisissez Créer. Une fois l'installation du module complémentaire terminée, vous pouvez voir le module complémentaire installé.

CloudFormation

Pour utiliser CloudFormation pour installer le module complémentaire Amazon CloudWatch Observability EKS

Remplacez my-cluster-name par le nom de votre cluster. Pour plus d'informations, veuillez consulter AWS::EKS::Addon (langue française non garantie).

{
"Resources": {
    "EKSAddOn": {
        "Type": "AWS::EKS::Addon",
        "Properties": {
            "AddonName": "amazon-cloudwatch-observability",
            "ClusterName": "my-cluster-name"
        }
    }
}
}

Helm chart

Pour utiliser le graphique Helm d'amazon-cloudwatch-observability

1. Vous devez avoir Helm installé pour pouvoir utiliser ce graphique. Pour plus d’informations sur l’installation de Helm, consultez la documentation Helm.

2. Une fois Helm installé, saisissez les commandes suivantes. my-cluster-nameRemplacez-le par le nom de votre cluster et remplacez-le my-cluster-region par la région dans laquelle le cluster s'exécute.

   helm repo add aws-observability https://aws-observability.github.io/helm-charts
   helm repo update aws-observability
   helm install --wait --create-namespace --namespace amazon-cloudwatch amazon-cloudwatch-observability aws-observability/amazon-cloudwatch-observability --set clusterName=my-cluster-name --set region=my-cluster-region

Terraform

Pour utiliser Terraform pour installer le module complémentaire Amazon CloudWatch Observability EKS

Remplacez my-cluster-name par le nom de votre cluster. Pour plus d'informations, veuillez consulter Ressource : aws_eks_addon (langue française non garantie).

resource "aws_eks_addon" "example" {
  addon_name   = "amazon-cloudwatch-observability"
  cluster_name = "my-cluster-name"
}

Option 3 : installation à l’aide d’un rôle de compte de service IAM (valable uniquement pour le module complémentaire)

Cette méthode n'est valide que si vous utilisez le module complémentaire Amazon CloudWatch Observability EKS. Avant d'utiliser cette méthode, vérifiez que les conditions préalables suivantes sont respectées :

AWS CLI

Pour utiliser le plugin AWS CLI pour installer le module complémentaire Amazon CloudWatch Observability EKS à l'aide du rôle de compte de service IAM

1. Saisissez la commande suivante pour créer un fournisseur OpenID Connect (OIDC), si le cluster n'en possède pas déjà un. Pour plus d'informations, veuillez consulter Configuration d'un compte de service Kubernetes pour assumer un rôle IAM dans le Guide de l'utilisateur Amazon EKS.

   eksctl utils associate-iam-oidc-provider --cluster my-cluster-name --approve

2. Entrez la commande suivante pour créer le rôle IAM avec la CloudWatchAgentServerPolicy politique associée, et configurez le compte de service de l'agent pour qu'il assume ce rôle à l'aide d'OIDC. my-cluster-nameRemplacez-le par le nom de votre cluster et my-service-account-role remplacez-le par le nom du rôle auquel vous souhaitez associer le compte de service. Si le rôle n'existe pas encore, eksctl le crée pour vous.

   eksctl create iamserviceaccount \
     --name cloudwatch-agent \
     --namespace amazon-cloudwatch --cluster my-cluster-name \
     --role-name my-service-account-role \
     --attach-policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy \
     --role-only \
     --approve

3. Installez l'add-on en saisissant la commande suivante. Remplacez-le my-cluster-name par le nom de votre cluster, remplacez-le 111122223333 par votre identifiant de compte et remplacez-le my-service-account-role par le rôle IAM créé à l'étape précédente.

   aws eks create-addon --addon-name amazon-cloudwatch-observability --cluster-name my-cluster-name --service-account-role-arn arn:aws:iam::111122223333:role/my-service-account-role

Amazon EKS console

Pour utiliser la console pour installer le module complémentaire Amazon CloudWatch Observability EKS à l'aide du rôle de compte de service IAM

1. Ouvrez la console Amazon EKS à l'adresse https://console.aws.amazon.com/eks/home #/clusters.

2. Dans le volet de navigation de gauche, choisissez Clusters.

3. Choisissez le nom du cluster pour lequel vous souhaitez configurer le module complémentaire Amazon CloudWatch Observability EKS.

4. Cliquez sur l'onglet Add-ons.

5. Choisissez Obtenez plus de modules complémentaires.

6. Sur la page Sélectionner des modules complémentaires, procédez comme suit :

   1. Dans la EKS-addons section Amazon, cochez la case Amazon CloudWatch Observability.

   2. Choisissez Suivant.

7. Sur la page Configurer les paramètres des modules complémentaires sélectionnés, procédez comme suit :

   1. Sélectionnez la version que vous souhaitez utiliser.

   2. Pour Add-on y accéder, sélectionnez les rôles IAM pour les comptes de service (IRSA)

   3. Sélectionnez le rôle IAM dans la zone Add-on d'accès.

   4. (Facultatif) Vous pouvez développer les paramètres de configuration facultatifs. Si vous sélectionnez Remplacer pour la méthode de résolution des conflits, un ou plusieurs des paramètres du module complémentaire existant peuvent être remplacés par les paramètres du module complémentaire Amazon EKS. Si vous n'activez pas cette option et qu'il y a un conflit avec vos paramètres existants, l'opération échoue. Vous pouvez utiliser le message d'erreur qui en résulte pour résoudre le conflit. Avant de sélectionner cette option, assurez-vous que le module complémentaire Amazon EKS ne gère pas les paramètres que vous devez gérer vous-même.

   5. Choisissez Suivant.

8. Sur la page Vérifier et ajouter, choisissez Créer. Une fois l'installation du module complémentaire terminée, vous pouvez voir le module complémentaire installé.

(Facultatif) Configuration supplémentaire

Désactivation de la collecte des journaux de conteneurs

Par défaut, le module complémentaire utilise Fluent Bit pour collecter les journaux de conteneurs de tous les pods, puis les envoie à CloudWatch Logs. Pour plus d'informations sur les journaux collectés, veuillez consulter Envoyer des journaux à CloudWatch Logs.

Pour désactiver la collecte des journaux de conteneurs si vous utilisez le module complémentaire Amazon CloudWatch Observability EKS, sélectionnez l'option suivante lorsque vous créez ou mettez à jour le module complémentaire :

--configuration-values '{ "containerLogs": { "enabled": false } }'

Pour désactiver la collecte des journaux de conteneurs lorsque vous utilisez les Charts de Helm, ajoutez l’option suivante lors de la création ou de la mise à jour du module complémentaire :

--set containerLogs.enabled=false

Utilisation d’une configuration Fluent Bit personnalisée

À partir de la version 1.7.0 du module complémentaire Amazon CloudWatch Observability EKS, vous pouvez modifier la configuration de Fluent Bit lorsque vous créez ou mettez à jour le module complémentaire ou le graphique Helm. Vous devez fournir votre configuration personnalisée de Fluent Bit dans la section racine containerLogs de la configuration avancée du module complémentaire, ou dans les valeurs de substitution des Charts de Helm. Dans cette section, la configuration personnalisée de Fluent Bit doit être placée dans la section config (pour Linux) ou dans la section configWindows (pour Windows). La config est ensuite décomposée dans les sous-sections suivantes :

Pour trouver la config section correspondant à votre cluster, consultez aws-observability/helm-charts sur GitHub et recherchez la version correspondant à la version du module complémentaire ou du graphique Helm que vous êtes en train d'installer. Naviguez ensuite vers /charts/amazon-cloudwatch-observability/values.yaml pour trouver la section config (pour Linux) et la section configWindows (pour Windows) dans la section fluentBit sous containerLogs.

À titre d’exemple, la configuration Fluent Bit par défaut pour la version 1.7.0 est disponible ici.

Nous vous recommandons de fournir le config format YAML lorsque vous le fournissez à l'aide de la configuration avancée du module complémentaire Amazon EKS ou lorsque vous le fournissez sous forme de remplacement de valeur pour votre installation Helm. Assurez-vous que le format YAML respecte la structure suivante.

containerLogs:
  fluentBit:
config:
  service: |
    ...
  customParsers: |
    ...
  extraFiles:
    application-log.conf: |
      ...
    dataplane-log.conf: |
      ...
    host-log.conf: |
      ...

L’exemple config suivant modifie le paramètre global de l’intervalle de vidange à 45 secondes. Même si la seule modification concerne le champ Flush, vous devez fournir la définition SERVICE complète de la sous-section service. Comme cet exemple ne définit pas de valeurs de substitution pour les autres sous-sections, les valeurs par défaut sont utilisées pour celles-ci.

containerLogs:
  fluentBit:
config:
  service: |
    [SERVICE]
      Flush                     45
      Grace                     30
      Log_Level                 error
      Daemon                    off
      Parsers_File              parsers.conf
      storage.path              /var/fluent-bit/state/flb-storage/
      storage.sync              normal
      storage.checksum          off
      storage.backlog.mem_limit 5M

L’exemple de configuration suivant inclut un fichier conf Fluent Bit supplémentaire. Dans cet exemple, vous ajoutez un my-service.conf extraFiles sous-menu personnalisé qui sera inclus en plus des trois valeurs par défautextraFiles.

containerLogs:
  fluentBit:
config:
  extraFiles:
    my-service.conf: |
      [INPUT]
        Name              tail
        Tag               myservice.*
        Path              /var/log/containers/*myservice*.log
        DB                /var/fluent-bit/state/flb_myservice.db
        Mem_Buf_Limit     5MB
        Skip_Long_Lines   On
        Ignore_Older      1d
        Refresh_Interval  10
      
      [OUTPUT]
        Name                cloudwatch_logs
        Match               myservice.*
        region              ${AWS_REGION}
        log_group_name      /aws/containerinsights/${CLUSTER_NAME}/myservice
        log_stream_prefix   ${HOST_NAME}-
        auto_create_group   true

L’exemple suivant supprime entièrement un fichier conf existant de extraFiles. Cela exclut complètement la application-log.conf en la remplaçant par une chaîne vide. Le simple fait d'omettre application-log.conf de extraFiles impliquerait plutôt d'utiliser la valeur par défaut, ce qui n'est pas ce que vous essayez de réaliser dans cet exemple. Il en va de même pour la suppression de tout fichier conf personnalisé que vous auriez pu ajouter précédemment aux extraFiles.

containerLogs:
  fluentBit:
config:
  extraFiles:
    application-log.conf: ""

Gestion des tolérances Kubernetes pour les charges de travail des pods installés

À partir de la version 1.7.0 du module complémentaire Amazon CloudWatch Observability EKS, le module complémentaire et le graphique Helm définissent par défaut les tolérances de Kubernetes de manière à tolérer toutes les altérations des charges de travail des pods installées par le module complémentaire ou le graphique Helm. Cela garantit que les daemonsets tels que l' CloudWatch agent et Fluent Bit peuvent planifier des pods sur tous les nœuds de votre cluster par défaut. Pour plus d’informations sur les tolérances et les rejets, consultez Rejets et tolérances dans la documentation de Kubernetes.

Les tolérances par défaut définies par le module complémentaire ou les Charts de Helm sont les suivantes :

tolerations:
- operator: Exists

Vous pouvez remplacer ces tolérances par défaut en définissant le champ tolerations à la racine de la configuration avancée du module complémentaire ou lors de l’installation ou la mise à jour des Charts de Helm avec des valeurs de substitution. Par exemple :

tolerations:
- key: "key1"
  operator: "Exists"
  effect: "NoSchedule"

Pour omettre complètement les tolérances, vous pouvez utiliser une configuration de ce type :

tolerations: []

Toute modification des tolérances s’applique à toutes les charges de travail des pods installées par le module complémentaire ou les Charts de Helm.

Désactivation de la collecte des métriques de calcul accéléré

Par défaut, Container Insights, doté d'une observabilité améliorée, collecte des mesures pour la surveillance accélérée du calcul, notamment des métriques GPU NVIDIA, des métriques AWS Neuron pour AWS Trainium et AWS Inferentia et des métriques AWS Elastic Fabric Adapter (EFA).

Les métriques des GPU NVIDIA issues des charges de travail Amazon EKS sont collectées par défaut en commençant par la version v1.3.0-eksbuild.1 du module complémentaire EKS ou le graphique Helm et la version 1.300034.0 de l' CloudWatch agent. Pour la liste des métriques collectées et les prérequis, consultez Métriques des GPU NVIDIA.

AWS Les métriques neuronales pour les accélérateurs AWS Trainium et AWS Inferentia sont collectées par défaut en commençant par la version v1.5.0-eksbuild.1 du module complémentaire EKS ou du graphique Helm, et la version 1.300036.0 de l'agent. CloudWatch Pour la liste des métriques collectées et les prérequis, consultez AWS Métriques neuronales pour AWS Trainium et AWS Inferentia.

AWS Les métriques Elastic Fabric Adapter (EFA) provenant des nœuds Linux des clusters Amazon EKS sont collectées par défaut en commençant par la version v1.5.2-eksbuild.1 du module complémentaire EKS ou le graphique Helm et la version 1.300037.0 de l' CloudWatch agent. Pour la liste des métriques collectées et les prérequis, consultez AWS Métriques de l'adaptateur Elastic Fabric (EFA).

Vous pouvez choisir de ne pas collecter ces métriques en définissant le accelerated_compute_metrics champ du fichier de configuration de l' CloudWatch agent surfalse. Ce champ se trouve dans la kubernetes section de la metrics_collected section du fichier CloudWatch de configuration. Voici un exemple de configuration avec désactivation. Pour plus d'informations sur l'utilisation des configurations d' CloudWatch agent personnalisées, consultez la section suivante,Utiliser une configuration d' CloudWatch agent personnalisée.

{
  "logs": {
"metrics_collected": {
  "kubernetes": {
    "enhanced_container_insights": true,
    "accelerated_compute_metrics": false
  }
}
  }
}

Utiliser une configuration d' CloudWatch agent personnalisée

Pour collecter d'autres métriques, journaux ou traces à l'aide de l' CloudWatch agent, vous pouvez spécifier une configuration personnalisée tout en maintenant Container Insights et CloudWatch Application Signals activés. Pour ce faire, intégrez le fichier de configuration de l' CloudWatch agent dans la clé de configuration, sous la clé d'agent de la configuration avancée, que vous pouvez utiliser lors de la création ou de la mise à jour du module complémentaire EKS ou du graphique Helm. Ce qui suit représente la configuration par défaut de l’agent lorsque vous ne fournissez aucune configuration supplémentaire.

L'exemple suivant montre la configuration d'agent par défaut pour l' CloudWatch agent sous Windows. L' CloudWatch agent sous Windows ne prend pas en charge la configuration personnalisée.

{
  "logs": {
"metrics_collected": {
  "kubernetes": {
    "enhanced_container_insights": true
  },
}
  }
}

Gérer les certificats TLS du webhook d’admission

Le module complémentaire Amazon CloudWatch Observability EKS et le graphique Helm utilisent les webhooks d'admission Kubernetes pour valider et muter les demandes de ressources Instrumentation personnalisées (CR), AmazonCloudWatchAgent et éventuellement les requêtes de pod Kubernetes sur le cluster si Application Signals est activé. CloudWatch Dans Kubernetes, les webhooks nécessitent un certificat TLS auquel le serveur d'API est configuré pour faire confiance afin de garantir la sécurité des communications.

Par défaut, le module complémentaire Amazon CloudWatch Observability EKS et le graphique Helm génèrent automatiquement une autorité de certification autosignée et un certificat TLS signé par cette autorité de certification pour sécuriser la communication entre le serveur API et le serveur webhook. Ce certificat généré automatiquement a une durée de validité par défaut de 10 ans et n’est pas renouvelé automatiquement à l’expiration. De plus, le paquet CA et le certificat sont régénérés chaque fois que le module complémentaire ou les Charts de Helm sont mis à jour ou réinstallés, ce qui réinitialise la date d’expiration. Si vous souhaitez modifier la durée de validité par défaut du certificat généré automatiquement, vous pouvez utiliser les configurations supplémentaires suivantes lors de la création ou de la mise à jour du module complémentaire. expiry-in-daysRemplacez-la par la durée de péremption souhaitée, en jours.

Pour une solution d’autorité de certification plus sécurisée et riche en fonctionnalités, le module complémentaire prend en charge cert-manager, une solution largement adoptée pour la gestion des certificats TLS dans Kubernetes qui simplifie le processus d’obtention, de renouvellement, de gestion et d’utilisation de ces certificats. Il garantit que les certificats sont valides et à jour, et tente de les renouveler à une heure configurée avant leur expiration. cert-manager simplifie également l'émission de certificats à partir de diverses sources prises en charge, y compris l'autorité de certification AWS Certificate Manager privée.

Nous vous recommandons de consulter les bonnes pratiques en matière de gestion des certificats TLS sur vos clusters et d’opter pour cert-manager pour les environnements de production. Notez que si vous choisissez d'activer cert-manager pour gérer les certificats TLS du webhook d'admission, vous devez préinstaller cert-manager sur votre cluster Amazon EKS avant d'installer le module complémentaire Amazon Observability EKS ou le Helm chart. CloudWatch Pour plus d’informations sur les options d’installation disponibles, consultez la documentation cert-manager. Après l’avoir installé, vous pouvez activer son utilisation pour gérer les certificats TLS des webhooks d’admission à l’aide de la configuration supplémentaire suivante.

--configuration-values '{ "admissionWebhooks": { "certManager": { "enabled": true } } }' 

La configuration avancée décrite dans cette section utilisera par défaut un SelfSigned émetteur.

Collecte des ID de volume Amazon EBS

Si vous souhaitez collecter les ID de volume Amazon EBS dans les journaux de performance, vous devez ajouter une autre politique au rôle IAM attaché aux composants master ou au compte de service. Ajoutez les éléments suivants en tant que politique en ligne. Pour de plus amples informations, veuillez consulter Ajout et suppression d'autorisations basées sur l'identité IAM.

JSON

{
    "Version":"2012-10-17",
    "Statement": [
        {
            "Action": [
                "ec2:DescribeVolumes"
            ],
            "Resource": "*",
            "Effect": "Allow"
        }
    ]
}

Collecte des métriques Java Management Extensions (JMX)

L' CloudWatch agent prend en charge la collecte de métriques Java Management Extensions (JMX) sur Amazon EKS. Cela vous permet de collecter des métriques supplémentaires provenant d’applications Java exécutées sur des clusters Amazon EKS, offrant ainsi une meilleure visibilité sur les performances, l’utilisation de la mémoire, le trafic et d’autres métriques essentielles. Pour de plus amples informations, veuillez consulter Collecte des métriques Java Management Extensions (JMX).

Activation des métriques Kueue

À partir de la version v2.4.0-eksbuild.1 du module complémentaire CloudWatch Observability EKS, Container Insights pour Amazon EKS prend en charge la collecte de métriques Kueue à partir de clusters Amazon EKS. Pour plus d’informations sur ces métriques, consultez Métriques Kueue.

Si vous utilisez le module complémentaire Amazon SageMaker AI Hyperpod Task Governance EKS, vous pouvez ignorer les étapes de la section Prérequis et simplement suivre les étapes décrites dans. Activation de l’indicateur de configuration

Conditions préalables

Avant d’installer Kueue dans votre cluster Amazon EKS, effectuez les mises à jour suivantes dans le fichier manifeste :

Activation de l’indicateur de configuration

Pour activer les métriques Kueue, vous devez activer la configuration supplémentaire kueue_container_insights dans le module complémentaire. Vous pouvez le faire soit en utilisant le module complémentaire EKS Observability AWS CLI pour configurer, soit en utilisant la console Amazon EKS.

Après avoir installé avec succès le module complémentaire EKS Observability à l'aide de l'une des méthodes suivantes, vous pouvez consulter les métriques de votre cluster Amazon EKS dans l'onglet Tableau de bord de la HyperPod console.

AWS CLI

Pour activer les métriques Kueue à l'aide du AWS CLI

• Entrez la AWS CLI commande suivante pour installer le module complémentaire.

  aws eks create-addon --cluster-name cluster-name --addon-name amazon-cloudwatch-observability --configuration-values "configuration_json_file"

  Voici un exemple de fichier JSON contenant les valeurs de configuration.

  {
  "agent": {
      "config": {
          "logs": {
              "metrics_collected": {
                  "kubernetes": {
                      "kueue_container_insights": true,
                      "enhanced_container_insights": true
                  },
                  "application_signals": { }
              }
          },
          "traces": {
              "traces_collected": {
                  "application_signals": { }
              }
          }
      },
  },
  }

Amazon EKS console

Pour activer les métriques Kueue à l’aide de la console Amazon EKS

1. Ouvrez la console Amazon EKS à l'adresse https://console.aws.amazon.com/eks/home #/clusters.

2. Choisissez le nom de votre cluster.

3. Sélectionnez Add-ons.

4. Recherchez le module complémentaire Amazon CloudWatch Observability dans la liste et installez-le. Lors de l’installation, choisissez Configuration facultative et incluez les valeurs de configuration JSON suivantes.

   {
   "agent": {
       "config": {
           "logs": {
               "metrics_collected": {
                   "kubernetes": {
                       "kueue_container_insights": true,
                       "enhanced_container_insights": true
                   },
                   "application_signals": { }
               }
           },
           "traces": {
               "traces_collected": {
                   "application_signals": { }
               }
           }
       },
   },
   }

Ajout de fichiers de configuration du OpenTelemetry collecteur

L' CloudWatch agent prend en charge des fichiers de configuration de OpenTelemetry collecteurs supplémentaires en plus de ses propres fichiers de configuration. Cette fonctionnalité vous permet d'utiliser des fonctionnalités d' CloudWatch agent telles que CloudWatch Application Signals ou Container Insights via la configuration de l' CloudWatch agent et d'intégrer votre configuration de OpenTelemetry collecteur existante avec un seul agent.

Pour éviter les conflits de fusion avec les pipelines créés automatiquement par CloudWatch l'agent, ajoutez un suffixe personnalisé à chacun des composants et des pipelines de votre configuration de OpenTelemetry collecteur. Cela permettra d’éviter les collisions et les conflits de fusion.

Activation de l'APM via des signaux d'application pour votre cluster Amazon EKS

Par défaut, la surveillance des performances des applications OpenTelemetry (APM) basée sur (OTEL) est activée via les signaux d'application lors de l'installation du module complémentaire CloudWatch Observability EKS (V5.0.0 ou supérieur) ou du graphique Helm. Vous pouvez ensuite personnaliser certains paramètres spécifiques à l’aide de la configuration avancée du module complémentaire Amazon EKS ou en remplaçant certaines valeurs dans les Charts de Helm.

Surveillance automatique avec la vigie applicative

La version 5.0.0 du module complémentaire CloudWatch Observability Amazon EKS et du graphique Helm introduit de nouvelles fonctionnalités. Vous pouvez désormais activer automatiquement la vigie applicative pour tous les services, ou uniquement pour certains charges de travail spécifiques de votre cluster EKS, en configurant la surveillance automatique. Les paramètres autoMonitor suivants peuvent être spécifiés dans la section applicationSignals, située sous la section manager de la configuration avancée.

L’exemple suivant montre une configuration qui active automatiquement la vigie applicative pour toutes les charges de travail de service existantes et nouvelles dans le cluster.

manager:
  applicationSignals:
autoMonitor:
  monitorAllServices: true
  restartPods: true

L’exemple suivant montre une configuration qui active automatiquement la vigie applicative pour toute nouvelle charge de travail de service créée, ainsi que pour toute charge de travail de service existante explicitement redémarrée dans le cluster.

manager:
  applicationSignals:
autoMonitor:
  monitorAllServices: true

L’exemple suivant montre une configuration qui active automatiquement la vigie applicative avec Java pour tous les pods existants et nouveaux correspondant à une charge de travail située dans l’espace de noms pet-warehouse.

manager:
  applicationSignals:
autoMonitor:
  restartPods: true
  customSelector:
    java:
      namespaces: ["pet-warehouse"]

L’exemple suivant montre une configuration qui active automatiquement la vigie applicative avec Python pour toutes les charges de travail de service existantes et nouvelles dans le cluster, sauf pour le déploiement pet-clinic.

manager:
  applicationSignals:
autoMonitor:
  monitorAllServices: true
  languages: ["python"]
  restartPods: true
  exclude:
    python:
      deployments: ["pet-warehouse/pet-clinic"]

L’exemple suivant montre une configuration qui active automatiquement la vigie applicative avec Java pour toutes les charges de travail de service du cluster, à l’exception de celles situées dans l’espace de noms python-apps, et qui active la vigie applicative avec Python uniquement pour le déploiement sample-python-app dans ce même espace de noms python-apps.

manager:
  applicationSignals:
autoMonitor:
  monitorAllServices: true
  languages: ["java"]
  restartPods: true
  customSelector:
    python:
      deployments: ["python-apps/sample-python-app"]
  exclude:
    java:
      namespaces: ["python-apps"]

Considérations relatives aux grands clusters Kubernetes

Si vous exécutez de grands clusters Kubernetes, vous pourriez avoir besoin d'une configuration supplémentaire pour garantir la fiabilité de l' CloudWatch agent. Les sections suivantes décrivent les problèmes courants et les configurations recommandées pour les grands clusters.

Installations d'agents distinctes pour les métriques au niveau du cluster et au niveau des nœuds

Par défaut, l' CloudWatch agent s'exécute en tant que daemonset sur chaque nœud de votre cluster. Un agent Pod est élu en tant que responsable pour collecter des métriques au niveau du cluster. Ces mesures incluent les mesures du plan de contrôle et les mesures de l'état de la charge de travail. Sur les grands clusters, ce leader Pod peut être interrompu en raison d'une erreur de mémoire insuffisante (OOM) car il effectue un travail supplémentaire tout en partageant les mêmes limites de ressources que tous les autres agentsPod.

Pour déterminer si vous rencontrez ce problème, recherchez les agents Pod en état d'échec avec le code de sortie 137 et la raisonOOMKilled. Un symptôme courant est qu'un agent Pod (le leader) tombe en panne, qu'un nouveau leader est élu, et que cela plante Pod également, créant un cycle récurrent. Pour confirmer ce comportement, inspectez l'élection du leader ConfigMap en exécutant la commande suivante.

kubectl describe configmap cwagent-clusterleader -n amazon-cloudwatch

Si l' ConfigMap entrée du leader est fréquemment modifiée, cela indique qu'un nouveau chef est élu à plusieurs reprises, ce qui confirme le problème.

Pour éviter ce problème, vous pouvez séparer l'agent en deux installations :

Cette séparation vous permet de gérer et de dimensionner chaque installation indépendamment.

Pour activer cette configuration, utilisez la configuration avancée pour définir deux entrées dans la agents section :

L'exemple suivant montre une configuration avancée qui sépare l'agent en deux installations.

agents:
  - name: cloudwatch-agent
env:
  - name: CWAGENT_ROLE
    value: NODE
  - name: cloudwatch-agent-ci-leader
mode: deployment
config:
  {
    "logs": {
      "metrics_collected": {
        "kubernetes": {
          "enhanced_container_insights": true
        }
      }
    }
  }
env:
  - name: CWAGENT_ROLE
    value: LEADER
resources:
  limits:
    memory: 10Gi
    cpu: 2000m

Dans cet exemple, outre la définition de la variable d'CWAGENT_ROLEenvironnement pour chaque installation d'agent, elle remplace le mode par défaut, la configuration et les limites de ressources pour l'agent de déploiement uniquement. L'cloudwatch-agentinstallation de base utilise les valeurs par défaut.

Vous pouvez personnaliser davantage l'installation de chaque agent nodeSelector en tolerations ajoutant des nodeAffinity champs pour planifier le leader Pod sur un nœud spécifique. Les limites de ressources indiquées dans l'exemple précédent sont illustratives. Ajustez ces valeurs en fonction de la taille de votre cluster et du nombre de mesures Pod collectées par le leader.

Considérations relatives aux nœuds hybrides Amazon EKS

Node-level les métriques ne sont pas disponibles pour les nœuds hybrides car Container Insights cela dépend de la disponibilité du service de métadonnées d'instance EC2 (IMDS) pour les métriques au niveau des nœuds. Les métriques au niveau du cluster, de la charge de travail, du Pod et du conteneur sont disponibles pour les nœuds hybrides.

Après avoir installé le module complémentaire, appliquez un correctif à la amazoncloudwatchagents ressource pour ajouter la variable d'RUN_WITH_IRSAenvironnement afin que l'agent s'exécute correctement sur les nœuds hybrides :

kubectl patch amazoncloudwatchagents cloudwatch-agent -n amazon-cloudwatch --type=json -p '[{"op":"add","path":"/spec/env/-","value":{"name":"RUN_WITH_IRSA","value":"True"}}]'

Résolution des problèmes liés au module complémentaire Amazon CloudWatch Observability EKS ou au graphique Helm

Utilisez les informations suivantes pour résoudre les problèmes liés au module complémentaire Amazon CloudWatch Observability EKS ou au graphique Helm

Mettre à jour et supprimer le module complémentaire Amazon CloudWatch Observability EKS ou le graphique Helm

Pour obtenir des instructions sur la mise à jour ou la suppression du module complémentaire Amazon CloudWatch Observability EKS, consultez la section Gestion des modules complémentaires Amazon EKS. Utilisez amazon-cloudwatch-observability comme nom du module complémentaire.

Pour supprimer les Charts de Helm d’un cluster, saisissez la commande suivante.

helm delete amazon-cloudwatch-observability -n amazon-cloudwatch --wait

Vérifiez la version de l' CloudWatch agent utilisée par le module complémentaire Amazon CloudWatch Observability EKS ou le graphique Helm

Le module complémentaire Amazon CloudWatch Observability EKS et le graphique Helm installent une ressource personnalisée de type AmazonCloudWatchAgent qui contrôle le comportement du daemonset de l' CloudWatch agent sur le cluster, y compris la version de l' CloudWatch agent utilisé. Vous pouvez obtenir la liste de toutes les ressources AmazonCloudWatchAgent personnalisées installées sur votre cluster en saisissant la commande suivante :

kubectl get amazoncloudwatchagent -A

Dans le résultat de cette commande, vous devriez pouvoir vérifier la version de l' CloudWatchagent. Vous pouvez également décrire la ressource amazoncloudwatchagent ou l’un des pods cloudwatch-agent-* exécutés sur votre cluster pour inspecter l’image utilisée.

Gestion de a ConfigurationConflict lors de la gestion du module complémentaire ou du graphique Helm

Lorsque vous installez ou mettez à jour le module complémentaire Amazon CloudWatch Observability EKS ou le graphique Helm, si vous remarquez une défaillance due à des ressources existantes, cela est probablement dû au fait que l' CloudWatch agent et ses composants associés, tels que le ServiceAccount, ClusterRole et le, sont déjà ClusterRoleBinding installés sur le cluster.

L’erreur affichée par le module complémentaire inclura Conflicts found when trying to apply. Will not continue due to resolve conflicts mode,

L’erreur affichée par les Charts de Helm sera similaire à Error: INSTALLATION FAILED: Unable to continue with install and invalid ownership metadata..

Lorsque le module complémentaire ou le graphique Helm tente d'installer l' CloudWatch agent et ses composants associés, s'il détecte un changement dans le contenu, l'installation ou la mise à jour échoue par défaut pour éviter de remplacer l'état des ressources sur le cluster.

Si vous essayez d'intégrer le module complémentaire Amazon CloudWatch Observability EKS et que vous constatez un échec, nous vous recommandons de supprimer une configuration d' CloudWatch agent existante que vous aviez précédemment installée sur le cluster, puis d'installer le module complémentaire EKS ou Helm chart. Veillez à sauvegarder toutes les personnalisations que vous avez pu apporter à la configuration d'origine de l' CloudWatch agent, telle qu'une configuration d'agent personnalisée, et à les fournir au module complémentaire ou au graphique Helm lors de votre prochaine installation ou mise à jour. Si vous aviez déjà installé l' CloudWatch agent d'intégration à Container Insights, consultez Guide de configuration (AWS CLI) pour plus d'informations.

Le module complémentaire prend également en charge une option de configuration de résolution des conflits capable de spécifier OVERWRITE. Vous pouvez utiliser cette option pour procéder à l’installation ou à la mise à jour du module complémentaire en remplaçant les conflits sur le cluster. Si vous utilisez la console Amazon EKS, vous trouverez la Méthode de résolution des conflits lorsque vous choisissez les Paramètres de configuration facultatifs lorsque vous créez ou mettez à jour le module complémentaire. Si vous utilisez le AWS CLI, vous pouvez fournir le --resolve-conflicts OVERWRITE à votre commande pour créer ou mettre à jour le module complémentaire.

Désactiver les signaux d'application

Fine-tune vos préférences de surveillance des services dans la CloudWatch console ou à l'aide du SDK.

Pour désactiver la surveillance automatique des signaux d'application, suivez la procédure ci-dessous :

À l'aide de la CLI ou du SDK

La configuration suivante peut être appliquée soit en tant que configuration avancée au module complémentaire EKS, soit en tant que remplacement de valeurs lors de l'utilisation du helm chart.

{
  "manager": {
"applicationSignals": {
  "autoMonitor": {
    "monitorAllServices": false
  }
}
  }
}

Redémarrez vos services pour que les modifications prennent effet.

Utilisation de la console