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 avec le module complémentaire Amazon CloudWatch Observability EKS ou le graphique Helm

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

L'utilisation de l'une ou l'autre méthode sur un cluster Amazon EKS permet à Container Insights de bénéficier d'une observabilité améliorée pour Amazon EKS et CloudWatch d'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.

Grâce à Container Insights avec observabilité améliorée pour Amazon EKS, les métriques de Container Insights sont facturées par observation au lieu d'être facturées par métrique stockée ou par journal ingéré. 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 CloudWatch les tarifs, consultez Amazon CloudWatch Pricing.

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 module complémentaire Amazon CloudWatch Observability EKS AWS CLI pour installer le module complémentaire Amazon Observability

Entrez les commandes suivantes : Remplacez my-cluster-name par le nom de votre cluster et 111122223333 par votre identifiant de compte. my-roleRemplacez-le par le rôle IAM que vous avez créé à l'étape d'association d'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. Choisissez l'onglet Modules complémentaires.

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 section Amazon EKS-Addons, 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 Accès au module complémentaire, sélectionnez Identité du pod EKS

   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, sélectionnez Créer un rôle, puis revenez à la page du module complémentaire 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

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

1. Exécutez d'abord la AWS CLI commande suivante pour associer la politique IAM nécessaire à votre rôle IAM. my-roleRemplacez-le par le rôle que vous avez créé à l'étape d'association d'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 my-cluster-name par le nom de votre cluster, remplacez 111122223333 par votre identifiant de compte et remplacez par le rôle IAM créé my-role à l'étape d'association d'EKS Pod Identity. Pour plus d'informations, consultez AWS::EKS::Addon.

   {
       "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 my-cluster-name par le nom de votre cluster, remplacez 111122223333 par votre identifiant de compte et remplacez par le rôle IAM créé my-service-account-role à l'étape d'association d'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, associez d'abord la politique CloudWatchAgentServerPolicyIAM à 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 module complémentaire Amazon CloudWatch Observability EKS AWS CLI pour installer le module complémentaire Amazon Observability

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. Choisissez l'onglet Modules complémentaires.

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 section Amazon EKS-Addons, 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

À 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, consultez AWS::EKS::Addon.

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

Helm chart

Pour utiliser les Charts de Helm 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. Remplacez my-cluster-name par le nom de votre cluster et remplacez 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 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 CloudWatchAgentServerPolicypolitique attachée, et configurez le compte de service de l'agent pour qu'il assume ce rôle à l'aide d'OIDC. Remplacez my-cluster-name par le nom de votre cluster, my-service-account-role puis 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 my-cluster-name par le nom de votre cluster, remplacez 111122223333 par votre ID de compte et remplacez 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 afin d'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. Choisissez l'onglet Modules complémentaires.

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 section Amazon EKS-Addons, 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 Accès au module complémentaire, sélectionnez Rôles IAM pour les comptes de service (IRSA)

   3. Sélectionnez le rôle IAM dans la zone Accès au module complémentaire.

   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é.

Considérations relatives aux nœuds hybrides Amazon EKS

Les métriques au niveau des nœuds ne sont pas disponibles pour les nœuds hybrides car elles Container Insights dépendent de la disponibilité du service de métadonnées d'EC2 instance (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 en suivant les étapes des sections précédentes, vous devez mettre à jour le manifeste du module complémentaire afin que l’agent puisse s’exécuter correctement sur les nœuds hybrides. Modifiez la ressource amazoncloudwatchagents dans le cluster afin d’ajouter la variable d’environnement RUN_WITH_IRSA, comme illustré ci-dessous.

kubectl edit amazoncloudwatchagents -n amazon-cloudwatch cloudwatch-agent

apiVersion: v1
       items:
       - apiVersion: cloudwatch.aws.amazon.com/v1alpha1
         kind: AmazonCloudWatchAgent
         metadata:
           ...
           name: cloudwatch-agent
           namespace: amazon-cloudwatch
           ...
         spec:
           ...
           env:
           - name: RUN_WITH_IRSA # <-- Add this
             value: "True" # <-- Add this
           - name: K8S_NODE_NAME
             valueFrom:
               fieldRef:
                 fieldPath: spec.nodeName
                 ...
       

(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 des conteneurs à partir de tous les pods, puis envoie les CloudWatch journaux à Logs. Pour plus d'informations sur les journaux collectés, veuillez consulter Configuration de Fluent Bit.

Pour refuser la collecte des journaux de conteneurs si vous utilisez le module complémentaire Amazon CloudWatch Observability EKS, passez 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 on GitHub et recherchez la version correspondant à la version du module complémentaire ou du graphique Helm que vous installez. 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 la config en format YAML, que ce soit via la configuration avancée du module complémentaire Amazon EKS ou les valeurs de substitution de 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, nous ajoutons une my-service.conf personnalisée sous extraFiles qui sera incluse en plus des trois extraFiles par défaut.

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 que nous n’essayons pas 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 des tolérances Kubernetes afin de tolérer toutes les altérations des charges de travail du pod 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 métriques pour la surveillance accélérée du calcul, notamment les métriques du GPU NVIDIA, les métriques AWS Neuron pour AWS Trainium et AWS Inferentia, et les métriques AWS Elastic Fabric Adapter (EFA).

Les métriques du 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 à partir de la version v1.5.0-eksbuild.1 du module complémentaire EKS ou du graphique Helm et de 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 Inferentia AWS.

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

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

Utiliser une configuration d' CloudWatchagent personnalisée

Pour collecter d'autres métriques, journaux ou traces à l'aide de l' CloudWatch agent, vous pouvez définir une configuration personnalisée tout en gardant 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 située 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 par défaut de 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 exploitent 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 que le serveur d’API soit configuré pour faire confiance à un certificat TLS afin de garantir une communication sécurisée.

Par défaut, le module complémentaire Amazon CloudWatch Observability EKS et le graphique Helm génèrent automatiquement une autorité de certification auto-signée et un certificat TLS signé par cette autorité de certification afin de sécuriser la communication entre le serveur d'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-le 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 renouveler les certificats à une heure configurée avant leur expiration. cert-manager facilite également l’émission de certificats provenant de diverses sources prises en charge, y compris l’autorité de AWS Certificate Manager Private Certificate Authority.

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 acceptez 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 graphique Helm 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.

Collectez le volume Amazon EBS IDs

Si vous souhaitez collecter le volume Amazon EBS IDs dans les journaux de performance, vous devez ajouter une autre politique au rôle IAM qui est attaché aux nœuds de travail 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 for 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. 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 correctement installé 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 sous 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. Choisissez Modules complémentaires.

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 les 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 dans le cadre de 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, nous vous recommandons d'ajouter un suffixe personnalisé à chacun des composants et pipelines de la configuration de votre 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"]

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

Mise à jour et suppression du module complémentaire Amazon CloudWatch Observability EKS ou du 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 AmazonCloudWatchAgent qui contrôle le comportement du daemonset de l' CloudWatch agent sur le cluster, y compris la version de l' CloudWatch agent utilisée. 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 être en mesure de 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.

Manipulation d'un 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, c'est probablement parce que vous avez déjà ClusterRoleBinding installé l' CloudWatch agent et ses composants associés tels que le ServiceAccount, le ClusterRole et le 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 une modification du contenu, il échoue par défaut à l'installation ou à la mise à jour afin d'éviter de modifier l'état des ressources du cluster.

Si vous essayez d'intégrer le module complémentaire Amazon CloudWatch Observability EKS et que vous constatez cet é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 le graphique Helm. Veillez à sauvegarder toutes les personnalisations que vous avez éventuellement apportées à 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 tableau Helm lors de sa prochaine installation ou mise à jour. Si vous avez déjà installé l' CloudWatch agent pour l'intégration à Container Insights, consultez Suppression de l' CloudWatch agent et de Fluent Bit for Container Insights 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

Ajustez vos préférences de surveillance des services dans la CloudWatch console ou avec le SDK.

Pour les versions antérieures à 5.0.0, pour désactiver la surveillance automatique des signaux d'application, suivez la procédure ci-dessous :

Utilisation 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 diagramme de barre.

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

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

Utilisation de la console