Installez l' CloudWatch agent avec le module complémentaire Amazon CloudWatch Observability EKS ou le graphique Helm - Amazon CloudWatch
Option 1 : installation à l'aide d'EKS Pod Identity Option 2 : Installation avec des autorisations IAM sur les nœuds de travail Option 3 : Installation à l'aide du rôle de compte de service IAM (s'applique uniquement à l'utilisation du module complémentaire)Considérations relatives aux nœuds hybrides Amazon EKS(Facultatif) Configuration supplémentaireCollectez les métriques des extensions de gestion Java (JMX)Activer les métriques KueueAjout de fichiers de configuration du OpenTelemetry collecteurConfiguration des signaux d'applicationRésolution des problèmes

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. 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 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 activent Container Insights sur les nœuds de travail Linux et Windows du cluster Amazon EKS. Pour activer Container Insights sous Windows, vous devez utiliser la version 1.5.0 ou ultérieure du module complémentaire Amazon EKS ou le graphique Helm. Actuellement, Application Signals n'est pas pris en charge sous 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 :

  • Attachez une politique au rôle IAM de vos composants master. Cette option accorde des autorisations aux nœuds de travail auxquels envoyer des données télémétriques. CloudWatch

  • Utilisez un rôle IAM pour les comptes de service des pods d'agent et attachez la politique à ce rôle. Cela ne fonctionne que pour les clusters Amazon EKS. Cette option donne CloudWatch accès uniquement aux modules d'agent appropriés.

Option 1 : installation à l'aide d'EKS Pod Identity

Si vous utilisez la version 3.1.0 ou ultérieure du module complémentaire, vous pouvez utiliser EKS Pod Identity pour accorder les autorisations requises au module complémentaire. EKS Pod Identity est l'option recommandée et offre des avantages tels que le moindre privilège, la rotation des informations d'identification et l'auditabilité. En outre, l'utilisation d'EKS Pod Identity vous permet d'installer le module complémentaire EKS dans le cadre de la création du cluster elle-même.

Pour utiliser cette méthode, suivez d'abord les étapes d'association EKS Pod Identity pour créer le rôle IAM et configurer l'agent EKS Pod Identity.

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. AWS 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 remplacez 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éder aux modules complémentaires, sélectionnez EKS Pod Identity

    3. Si aucun rôle IAM n'est configuré, choisissez Créer un rôle recommandé, puis cliquez sur Suivant jusqu'à ce que vous soyez à l'étape 3 Nommer, révisez et créez. Vous pouvez modifier le nom de votre rôle si vous le souhaitez. Sinon, choisissez Create Role, 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é.

AWS CloudFormation
À utiliser AWS 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. Créez ensuite la 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 Resource : aws_eks_addon dans la documentation de 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 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. AWS 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é.

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 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 du rôle de compte de service IAM (s'applique uniquement à l'utilisation du 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 :

  • Vous disposez d'un cluster Amazon EKS fonctionnel avec des nœuds rattachés à l'une des Régions AWS prenant en charge Container Insights. Pour obtenir la liste des régions prises en charge, consultez Container Insights.

  • kubectl est installé et configuré pour le cluster. Pour plus d'informations, consultez Installation de kubectl dans le Guide de l'utilisateur Amazon EKS.

  • eksctl est installé. Pour plus d'informations, veuillez consulter Installation ou mise à jour de eksctl dans le Guide de l'utilisateur Amazon EKS.

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 l'accès aux modules complémentaires, sélectionnez les 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. Des métriques au niveau du clusterPod, de la charge de travail et 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

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

Note

Ni le module complémentaire ni le graphique Helm ne gèrent les ressources Fluentd ou Fluent Bit existantes dans un cluster. Vous pouvez supprimer les ressources Fluentd ou Fluent Bit existantes avant d'installer le module complémentaire ou le graphique Helm. Sinon, pour conserver votre configuration existante et éviter que le module complémentaire ou le graphique Helm n'installent également Fluent Bit, vous pouvez le désactiver en suivant les instructions de cette section.

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 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 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 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 :

  • service— Cette section représente la SERVICE configuration permettant de définir le comportement global du moteur Fluent Bit.

  • customParsers— Cette section représente tous les éléments globaux PARSER que vous souhaitez inclure et qui sont capables de prendre des entrées de journal non structurées et de leur donner une structure afin de faciliter le traitement et le filtrage ultérieur.

  • extraFiles— Cette section peut être utilisée pour fournir des conf fichiers Fluent Bit supplémentaires à inclure. Par défaut, les 3 conf fichiers suivants sont inclus :

    • application-log.conf— Un conf fichier permettant d'envoyer les journaux d'applications de votre cluster au groupe de CloudWatch journaux /aws/containerinsights/my-cluster-name/application dans Logs.

    • dataplane-log.conf— Un conf fichier permettant d'envoyer les journaux correspondant aux composants du plan de données de votre cluster, notamment les journaux CRI, les journaux kubelet, les journaux kube-proxy et les journaux Amazon VPC CNI, au groupe de journaux dans Logs. /aws/containerinsights/my-cluster-name/dataplane CloudWatch

    • host-log.conf— A conf pour envoyer des journaux depuis /var/log/dmesg/var/log/messages, et /var/log/secure sous Linux, et System winlogs sous Windows, /aws/containerinsights/my-cluster-name/host au groupe de journaux CloudWatch.

Note

Fournissez la configuration complète pour chacune de ces sections individuelles, même si vous ne modifiez qu'un seul champ dans une sous-section. Nous vous recommandons d'utiliser la configuration par défaut fournie ci-dessous comme référence, puis de la modifier en conséquence afin de ne pas désactiver les fonctionnalités activées par défaut. Vous pouvez utiliser la configuration YAML suivante lorsque vous modifiez la configuration avancée du module complémentaire Amazon EKS ou lorsque vous fournissez des remplacements de valeur pour le graphique Helm.

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 format YAML lorsque vous le fournissez à l'aide de la configuration avancée du module complémentaire Amazon EKS ou lorsque vous le fournissez en tant que remplacement de valeur pour votre installation Helm. Assurez-vous que le 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 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 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 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 obtenir la liste des mesures collectées et des conditions requises, consultezMétriques du 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 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) 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 obtenir la liste des mesures collectées et des conditions requises, consultezAWS 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 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 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.

Important

Toute configuration personnalisée que vous fournissez à l’aide de paramètres de configuration supplémentaires remplace la configuration par défaut utilisée par l’agent. Veillez à ne pas désactiver involontairement les fonctionnalités activées par défaut, telles que Container Insights avec une observabilité améliorée et les signaux d' CloudWatch application. Dans le cas où vous devez fournir une configuration d’agent personnalisée, nous vous recommandons d’utiliser la configuration par défaut suivante comme référence, puis de la modifier en conséquence.

  • Pour utiliser le module complémentaire Amazon CloudWatch observability EKS

    --configuration-values '{
  "agent": {
    "config": {
      "logs": {
        "metrics_collected": {
          "application_signals": {},
          "kubernetes": {
            "enhanced_container_insights": true
          }
        }
      },
      "traces": {
        "traces_collected": {
          "application_signals": {}
        }
      }
    }
  
}'

  • Pour utiliser le graphique Helm

    --set agent.config='{
  "logs": {
    "metrics_collected": {
      "application_signals": {},
      "kubernetes": {
        "enhanced_container_insights": true
      }
    }
  },
  "traces": {
    "traces_collected": {
      "application_signals": {}
    }
  }
}'

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

  • Utilisez-le pour le module complémentaire Amazon CloudWatch Observability EKS

    --configuration-values '{ "admissionWebhooks": { "autoGenerateCert": { "expiryDays": expiry-in-days } } }'

  • Utilisez-le pour le graphique Helm

    --set admissionWebhooks.autoGenerateCert.expiryDays=expiry-in-days

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 de cert-manager. Après l'avoir installé, vous pouvez choisir d'utiliser cert-manager pour gérer les certificats TLS du webhook d'admission à l'aide de la configuration supplémentaire suivante.

  • Si vous utilisez le module complémentaire Amazon CloudWatch Observability EKS

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

  • Si vous utilisez le graphique Helm

    --set admissionWebhooks.certManager.enabled=true
--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.


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

Collectez les métriques des extensions de gestion Java (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 à partir d'applications Java exécutées sur des clusters Amazon EKS, ce qui vous permet de mieux comprendre les performances, l'utilisation de la mémoire, le trafic et d'autres mesures 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 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 de 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. Activer l'indicateur de configuration

Prérequis

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

  1. Activez les métriques de ressources de file d'attente de cluster facultatives pour Kueue. Pour ce faire, modifiez le texte en ligne controller_manager_config.yaml dans le kueue-system ConfigMap. Dans la metrics section, ajoutez ou décommentez la ligneenableClusterQueueResources: true.

    apiVersion: v1
data:
  controller_manager_config.yaml: |
    apiVersion: config.kueue.x-k8s.io/v1beta1
    kind: Configuration
    health:
      healthProbeBindAddress: :8081
    metrics:
      bindAddress: :8080
      enableClusterQueueResources: true  <-- ADD/UNCOMMENT THIS LINE

  2. Par défaut, tous les k8s services sont disponibles à l'échelle du cluster. Kueue crée un service kueue-controller-manager-metrics-service pour exposer les métriques. Pour éviter les observations dupliquées pour les métriques, modifiez ce service pour autoriser l'accès uniquement au service de métriques depuis le même nœud. Pour ce faire, ajoutez la ligne internalTrafficPolicy: Local à la kueue-controller-manager-metrics-service définition.

    apiVersion: v1
kind: Service
metadata:
  labels:
    ...
  name: kueue-controller-manager-metrics-service
  namespace: kueue-system
spec:
  ports:
  - name: https
    port: 8443
    protocol: TCP
    targetPort: https
  internalTrafficPolicy: Local   <-- ADD THIS LINE
  selector:
    control-plane: controller-manager

  3. Enfin, le kueue-controller-manager pod crée un kube-rbac-proxy contenant. Ce conteneur présente actuellement un niveau élevé de verbosité de journalisation, ce qui fait que le jeton porteur du cluster est enregistré par ce conteneur lorsque le scraper de métriques accède au. kueue-controller-manager-metrics-service Nous vous recommandons de réduire cette verbosité de journalisation. La valeur par défaut du manifeste distribué par Kueue est 10, nous vous recommandons de la remplacer par 0.

    apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    ...
  name: kueue-controller-manager
  namespace: kueue-system
spec:
  ...
  template:
    ...
    spec:
      containers:
      ...
      - args:
        - --secure-listen-address=0.0.0.0:8443
        - --upstream=http://127.0.0.1:8080/
        - --logtostderr=true
        - --v=0  <-- CHANGE v=10 TO v=0
        image: gcr.io/kubebuilder/kube-rbac-proxy:v0.8.0
        name: kube-rbac-proxy
        ...

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 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. Dans ce cas, 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.

  • Si vous utilisez le module complémentaire Amazon CloudWatch Observability EKS

    --configuration-values file://values.yaml

    or

    --configuration-values '
  agent:
    otelConfig:
      receivers:
        otlp/custom-suffix:
          protocols:
            http: {}
      exporters:
        awscloudwatchlogs/custom-suffix:
          log_group_name: "test-group"
          log_stream_name: "test-stream"
      service:
        pipelines:
          logs/custom-suffix:
            receivers: [otlp/custom-suffix]
            exporters: [awscloudwatchlogs/custom-suffix]
'

  • Si vous utilisez le graphique Helm

    --set agent.otelConfig='
  receivers:
    otlp/custom-suffix:
      protocols:
        http: {}
  exporters:
    awscloudwatchlogs/custom-suffix:
      log_group_name: "test-group"
      log_stream_name: "test-stream"
  service:
    pipelines:
      logs/custom-suffix:
        receivers: [otlp/custom-suffix]
        exporters: [awscloudwatchlogs/custom-suffix]
'

Configuration des signaux d'application pour votre cluster Amazon EKS

Application Signals est activé par défaut lors de l'installation du module complémentaire CloudWatch Observability EKS ou du graphique Helm. Vous pouvez personnaliser davantage des paramètres spécifiques à l'aide de la configuration avancée du module complémentaire Amazon EKS ou en remplaçant les valeurs par le graphique de Helm.

Surveillance automatique des signaux d'application

La version 4.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 les signaux d'application pour toutes les charges de travail de service ou pour des charges de travail spécifiques de votre cluster EKS via la configuration du moniteur automatique. Les autoMonitor paramètres suivants peuvent être spécifiés dans la applicationSignals section située sous la manager section de la configuration avancée.

  • monitorAllServices— Un indicateur booléen permettant d'activer (vrai) ou de désactiver (faux) la surveillance de toutes les charges de travail des services par Auto Monitor. La valeur par défaut est false. L'activation de cet indicateur garantit que toutes les charges de travail Kubernetes (déploiements DaemonSets, et StatefulSets) du cluster mappées à un service Kubernetes seront autorisées à activer automatiquement les signaux d'application lorsqu'ils seront affichés pour la première fois (ou lors du redémarrage pour les charges de travail existantes). Le système exclut les charges de travail dans les amazon-cloudwatch espaces de noms kube-system et par défaut.

  • languages — Une liste de chaînes spécifiant l'ensemble de langues avec lesquelles Application Signals essaiera d'instrumenter automatiquement vos services, lorsqu'il monitorAllServices est activé. Par défaut, toutes les langues prises en charge sont prises en charge.

  • RestartPods — Un indicateur booléen contrôle si les charges de travail redémarrent après les modifications de configuration. La valeur par défaut est false. L'activation de cet indicateur permet de true contrôler si les charges de travail Kubernetes dans le cadre de la surveillance automatique redémarrent automatiquement lors de l'enregistrement des modifications de configuration. Tous les paramètres de vos charges de travail Kubernetes qui influencent le redémarrage des pods seront pris en updateStrategy compte. Tenez compte du fait que le redémarrage peut entraîner une interruption du service.

  • CustomSelector : paramètres permettant de sélectionner des espaces de noms ou des charges de travail Kubernetes spécifiques pour Auto Monitor.

    • java — Spécifie les charges de travail à instrumenter automatiquement avec Java

    • python — Spécifie les charges de travail à instrumenter automatiquement avec Python

    • nodejs — Spécifie les charges de travail à instrumenter automatiquement avec Node.js

    • dotnet — Spécifie les charges de travail à instrumenter automatiquement avec .NET

    Pour chacune des langues ci-dessus, les champs suivants peuvent être configurés.

    • namespaces — Liste de chaînes spécifiant les espaces de noms à sélectionner. Par défaut, il s'agit d'une liste vide, c'est-à-dire []

    • déploiements : liste de chaînes spécifiant les déploiements à sélectionner. Spécifiez dans le namespace/deployment format. Par défaut, il s'agit d'une liste vide, c'est-à-dire []

    • daemonsets — Liste de chaînes spécifiant les daemonsets à sélectionner. Spécifiez dans le namespace/daemonset format. Par défaut, il s'agit d'une liste vide, c'est-à-dire []

    • statefulsets — Liste de chaînes spécifiant les ensembles d'états à sélectionner. Spécifiez dans le namespace/statefulset format. Par défaut, il s'agit d'une liste vide, c'est-à-dire []

  • exclude — Paramètres permettant d'exclure des espaces de noms ou des charges de travail Kubernetes spécifiques du moniteur automatique. L'exclusion d'une charge de travail a priorité lorsque la même charge de travail est également comprise dans le champ d'application de monitorAllServices oucustomSelector.

    • java — Spécifie les charges de travail à exclure de l'instrumentation automatique avec Java

    • python — Spécifie les charges de travail à exclure de l'instrumentation automatique avec Python

    • nodejs — Spécifie les charges de travail à exclure de l'instrumentation automatique avec Node.js

    • dotnet — Spécifie les charges de travail à exclure de l'instrumentation automatique avec .NET

    Pour chacune des langues ci-dessus, les champs suivants peuvent être configurés.

    • namespaces — Liste de chaînes spécifiant les espaces de noms à exclure. Par défaut, il s'agit d'une liste vide, c'est-à-dire []

    • déploiements : liste de chaînes spécifiant les déploiements à exclure. Spécifiez dans le namespace/deployment format. Par défaut, il s'agit d'une liste vide, c'est-à-dire []

    • daemonsets — Liste de chaînes spécifiant les daemonsets à exclure. Spécifiez dans le namespace/daemonset format. Par défaut, il s'agit d'une liste vide, c'est-à-dire []

    • statefulsets — Liste de chaînes spécifiant les ensembles d'états à exclure. Spécifiez dans le namespace/statefulset format. Par défaut, il s'agit d'une liste vide, c'est-à-dire []

Voici un exemple de configuration qui active automatiquement les signaux d'application pour toutes les charges de travail de service existantes et nouvelles sur le cluster.

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

Voici un exemple de configuration qui active automatiquement les signaux d'application pour toute nouvelle charge de travail de service créée et pour toute charge de travail de service existante qui est explicitement redémarrée sur le cluster.

manager:
  applicationSignals:
    autoMonitor:
      monitorAllServices: true

Voici un exemple de configuration qui active automatiquement les signaux d'application avec Java pour tous les pods existants et nouveaux correspondant à une charge de travail dans l'espace de pet-warehouse noms.

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

Voici un exemple de configuration qui active automatiquement les signaux d'application avec Python pour toutes les charges de travail de service existantes et nouvelles du cluster, à l'exception du pet-clinic déploiement.

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

Voici un exemple de configuration qui active automatiquement les signaux d'application avec Java pour toutes les charges de travail de service du cluster, à l'exception de celles de l'python-appsespace de noms, et qui active également les signaux d'application avec Python spécifiquement pour le sample-python-app déploiement dans l'python-appsespace de noms.

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 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 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' 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 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 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 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 Supprimer l' CloudWatch agent et 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.