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

Vous pouvez utiliser le EKS module complémentaire Amazon CloudWatch Observability 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 EKS cluster Amazon permet à Container Insights d'améliorer l'observabilité pour Amazon EKS et à CloudWatch Application Signals par défaut. Les deux fonctionnalités vous aident à collecter des métriques d'infrastructure, des données de télémétrie sur les performances des applications et des journaux de conteneurs à partir du cluster.

Grâce à Container Insights avec une observabilité améliorée pour AmazonEKS, 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 les signaux d'application, 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 configuré ()SLO. 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 produit 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 activent Container Insights sur les nœuds de travail Linux et Windows du EKS cluster Amazon. Pour activer Container Insights sous Windows, vous devez utiliser la version 1.5.0 ou ultérieure du EKS module complémentaire Amazon ou du graphique Helm. Actuellement, Application Signals n'est pas pris en charge sous Windows dans les EKS clusters Amazon.

Le EKS module complémentaire Amazon CloudWatch Observability est pris en charge sur les EKS clusters Amazon 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 IAM des autorisations 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 avec IAM autorisations sur les nœuds de travail

Pour utiliser cette méthode, associez d'abord la CloudWatchAgentServerPolicyIAMpolitique à vos nœuds de travail en saisissant la commande suivante. Dans cette commande, remplacez my-worker-node-role par le IAM rôle 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 EKS module complémentaire Amazon CloudWatch Observability. Pour installer le module complémentaire, vous pouvez utiliser la AWS CLI console ou Terraform. AWS CloudFormation

AWS CLI

Pour utiliser le module complémentaire Amazon Observability 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 EKS console Amazon afin d'ajouter le module complémentaire Amazon CloudWatch Observability EKS

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

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

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

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 Sélectionner IAM un rôle, sélectionnez Hériter du nœud

   3. (Facultatif) Vous pouvez développer les paramètres de configuration facultatifs. Si vous sélectionnez Override pour la méthode de résolution des conflits, un ou plusieurs paramètres du module complémentaire existant peuvent être remplacés par les paramètres du EKS module complémentaire Amazon. 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 EKS module complémentaire Amazon ne gère pas les paramètres que vous devez gérer vous-même.

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

AWS CloudFormation

À utiliser AWS 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 le graphique amazon-cloudwatch-observability Helm

1. Helm doit être installé pour utiliser ce graphique. Pour plus d'informations sur l'installation de Helm, consultez la documentation de Helm.

2. Après avoir installé Helm, entrez 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 Observability CloudWatch 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 2 : Installation à l'aide du rôle IAM de compte de service (s'applique uniquement à l'utilisation du module complémentaire)

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

Considérations relatives aux nœuds EKS hybrides Amazon

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'EC2instance (IMDS) pour les métriques au niveau des nœuds. Cluster, charge de travail, Pod, et des métriques au niveau du conteneur sont disponibles pour les nœuds hybrides.

Après avoir installé le module complémentaire en suivant les étapes décrites dans les 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 amazoncloudwatchagents ressource du cluster pour ajouter la variable d'RUN_WITH_IRSAenvironnement correspondant à ce qui suit.

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

Ne pas collecter les 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 EKS module complémentaire Amazon CloudWatch Observability, passez l'option suivante lorsque vous créez ou mettez à jour le module complémentaire :

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

Pour refuser la collecte des journaux de conteneurs si vous utilisez le graphique Helm, passez l'option suivante lorsque vous créez ou mettez à jour le module complémentaire :

--set containerLogs.enabled=false

Utiliser une configuration Fluent Bit personnalisée

À partir de la version 1.7.0 du EKS module complémentaire Amazon CloudWatch Observability, vous pouvez modifier la configuration de Fluent Bit lorsque vous créez ou mettez à jour le module complémentaire ou le graphique Helm. Vous fournissez la configuration Fluent Bit personnalisée dans la section de niveau containerLogs racine de la configuration avancée du module complémentaire ou les remplacements de valeurs dans le graphique de Helm. Dans cette section, vous fournissez la configuration personnalisée de Fluent Bit dans la config section (pour Linux) ou dans configWindows la section (pour Windows). configIl est ensuite décomposé 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 /charts/amazon-cloudwatch-observability/values.yaml vers pour trouver la config section (pour Linux) et configWindows la section (pour Windows) dans la fluentBit section ci-dessouscontainerLogs.

À titre d'exemple, la configuration Fluent Bit par défaut pour la version 1.7.0 se trouve ici.

Nous vous recommandons de fournir le config as YAML lorsque vous le fournissez à l'aide de la configuration avancée du EKS module complémentaire Amazon ou lorsque vous le fournissez en tant que remplacement de valeur pour votre installation Helm. Assurez-vous qu'il YAML est conforme à la structure suivante.

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

L'exemple suivant config modifie le paramètre global de l'intervalle de rinçage à 45 secondes. Même si la seule modification concerne le Flush champ, vous devez tout de même fournir la SERVICE définition complète de la sous-section du service. Comme cet exemple n'a pas spécifié de remplacements 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 conf fichier Fluent bit supplémentaire. Dans cet exemple, nous ajoutons un my-service.conf sous-titre extraFiles personnalisé qui sera inclus en plus des trois 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 conf fichier existant deextraFiles. Cela les exclut application-log.conf complètement en le 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 conf fichier personnalisé que vous auriez pu ajouter précédemmentextraFiles.

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

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

À partir de la version 1.7.0 du module complémentaire Amazon CloudWatch Observability, le EKS module complémentaire et le graphique Helm définissent par défaut les tolérances de 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 altérations, consultez Taints and Tolerations dans la documentation Kubernetes.

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

tolerations:
- operator: Exists

Vous pouvez annuler les tolérances par défaut en définissant le tolerations champ au niveau de la racine lorsque vous utilisez la configuration avancée du module complémentaire ou lorsque vous installez ou mettez à niveau le graphique de Helm avec des remplacements de valeurs. Voici un exemple :

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

Pour omettre complètement les tolérances, vous pouvez utiliser une configuration qui ressemble à ce qui suit :

tolerations: []

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

Désactiver la collecte accélérée de métriques de calcul

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

NVIDIAGPUles métriques des EKS charges de travail Amazon sont collectées par défaut en commençant par la version v1.3.0-eksbuild.1 du EKS module complémentaire ou le graphique Helm et la version 1.300034.0 de l' CloudWatch agent. Pour obtenir la liste des mesures collectées et des conditions requises, consultezMétriques NVIDIA GPU.

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 EKS module complémentaire ou du graphique Helm et par la version 1.300036.0 de l'agent. CloudWatch Pour obtenir la liste des mesures collectées et des conditions requises, consultezAWS Métriques neuronales pour AWS Trainium et Inferentia AWS.

AWS Les métriques Elastic Fabric Adapter (EFA) provenant des nœuds Linux des EKS clusters Amazon sont collectées par défaut en commençant par la version v1.5.2-eksbuild.1 du EKS module complémentaire ou le graphique Helm et la version 1.300037.0 de l' CloudWatch agent. Pour obtenir la liste des mesures collectées et des conditions requises, consultezAWS 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 de désinscription. 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 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 EKS module complémentaire 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 d'admission en ligne TLS

Le EKS module complémentaire Amazon CloudWatch Observability 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 un TLS certificat auquel le API serveur est configuré pour faire confiance afin de garantir la sécurité des communications.

Par défaut, le EKS module complémentaire Amazon CloudWatch Observability et le graphique Helm génèrent automatiquement une autorité de certification auto-signée et un TLS certificat signé par cette autorité de certification afin de sécuriser la communication entre le API serveur 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. En outre, le bundle CA et le certificat sont régénérés chaque fois que le module complémentaire ou le graphique Helm est mis à niveau ou réinstallé, ce qui réinitialise l'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 TLS certificats 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 meilleures pratiques en matière de gestion des TLS certificats sur vos clusters et d'opter pour le gestionnaire de certificats pour les environnements de production. Notez que si vous acceptez d'activer cert-manager pour gérer les TLS certificats webhook d'admission, vous devez préinstaller cert-manager sur votre cluster Amazon EKS avant d'installer le module complémentaire Amazon Observability ou le graphique Helm. CloudWatch EKS Pour plus d'informations sur les options d'installation disponibles, consultez la documentation de cert-manager. Après l'avoir installé, vous pouvez choisir d'utiliser cert-manager pour gérer les TLS certificats webhook 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 EBS volume Amazon IDs

Si vous souhaitez collecter le EBS volume Amazon IDs dans les journaux de performance, vous devez ajouter une autre politique au IAM rôle attaché aux nœuds de travail ou au compte de service. Ajoutez les éléments suivants en tant que politique en ligne. Pour plus d'informations, consultez la section Ajouter et supprimer des autorisations IAM d'identité.

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

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

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

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

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

Pour supprimer le graphique Helm d'un cluster, entrez la commande suivante.

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

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

Le EKS module complémentaire Amazon CloudWatch Observability et le graphique Helm installent une ressource personnalisée AmazonCloudWatchAgent qui contrôle le comportement du daemonset de l' CloudWatchagent 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' CloudWatch agent. 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 EKS module complémentaire Amazon CloudWatch Observability ou le graphique Helm, si vous remarquez une défaillance due aux 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 le graphique 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 pour éviter de modifier l'état des ressources du cluster.

Si vous essayez d'intégrer le EKS module complémentaire Amazon CloudWatch Observability 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 EKS module complémentaire 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 EKS console Amazon, 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.

Collectez les métriques des extensions de gestion Java (JMX)

L' CloudWatch agent prend en charge la collecte de métriques par Java Management Extensions (JMX) sur AmazonEKS. Cela vous permet de collecter des métriques supplémentaires à partir d'applications Java exécutées sur des EKS clusters Amazon, ce qui vous permet de mieux comprendre les performances, l'utilisation de la mémoire, le trafic et d'autres indicateurs critiques. Pour de plus amples informations, veuillez consulter Collectez les métriques des extensions de gestion Java (JMX).

Activer les métriques Kueue

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

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

Prérequis

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

Activer 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 EKS console Amazon.

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 EKS cluster Amazon 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 JSON fichier 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 EKS console Amazon à 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. Dans ce cas, choisissez Configuration facultative et incluez les valeurs JSON de configuration 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.