Scénarios courants avec l'agent CloudWatch

Cette section présente différents scénarios d’utilisation permettant d’effectuer les tâches de configuration et de personnalisation les plus courantes de l’agent CloudWatch.

Exécution de l'agent CloudWatch sous l'identité d'un autre utilisateur

Sur les serveurs Linux, l'agent CloudWatch s'exécute sous l'identité de l'utilisateur racine par défaut. Pour que l'agent s'exécute sous l'identité d'un autre utilisateur, utilisez le paramètre run_as_user dans la section agent du fichier de configuration de l'agent CloudWatch. Cette option est disponible uniquement sur les serveurs Linux.

Si vous exécutez déjà l'agent avec l'utilisateur racine et que vous souhaitez le modifier pour utiliser l'identité d'un autre utilisateur, suivez l'une des procédures ci-après.

Comment l'agent CloudWatch gère les fichiers journaux fragmentés

Les fichiers fragmentés sont des fichiers avec des blocs vides et du contenu réel. Un fichier épars utilise plus efficacement l'espace disque en écrivant de brèves informations représentant les blocs vides sur le disque au lieu des octets nuls réels qui composent le bloc. Généralement, la taille réelle d'un fichier fragmenté apparaît alors beaucoup plus petite que sa taille apparente.

Cependant, l'agent CloudWatch ne traite pas les fichiers fragmentés différemment des fichiers normaux. Lorsque l'agent lit un fichier fragmenté, les blocs vides sont traités comme des blocs « réels » remplis d'octets nuls. Pour cette raison, l'agent CloudWatch publie autant d'octets que la taille apparente d'un fichier fragmenté sur CloudWatch.

La configuration de l'agent CloudWatch pour publier un fichier fragmenté peut entraîner des coûts CloudWatch plus élevés que prévu. Nous vous recommandons donc de ne pas le faire. Par exemple, /var/logs/lastlog sous Linux est généralement un fichier très fragmenté et nous vous recommandons de ne pas le publier sur CloudWatch.

Ajout de dimensions personnalisées aux métriques collectées par l'agent CloudWatch

Pour ajouter des dimensions personnalisées telles que des étiquettes à des métriques collectées par l'agent, ajoutez le champ append_dimensions dans la section du fichier de configuration d'agent qui répertorie ces métriques.

Par exemple, l'exemple suivant de section du fichier de configuration ajoute une dimension personnalisée nommée stackName avec la valeur Prod pour les métriques cpu et disk collectées par l'agent.

"cpu":{  
  "resources":[  
    "*"
  ],
  "measurement":[  
    "cpu_usage_guest",
    "cpu_usage_nice",
    "cpu_usage_idle"
  ],
  "totalcpu":false,
  "append_dimensions":{  
    "stackName":"Prod"
  }
},
"disk":{  
  "resources":[  
    "/",
    "/tmp"
  ],
  "measurement":[  
    "total",
    "used"
  ],
  "append_dimensions":{  
    "stackName":"Prod"
  }
}

Souvenez-vous que chaque fois que vous modifiez le fichier de configuration d'agent, vous devez ensuite redémarrer l'agent pour que les modifications prennent effet.

Agrégation ou propagation de métriques collectées par l'agent CloudWatch

Pour regrouper ou propager les métriques recueillies par l'agent, ajoutez un champ aggregation_dimensions à la section correspondante dans le fichier de configuration d'agent.

Par exemple, le fichier de configuration suivant extrait les métriques sur la dimension AutoScalingGroupName. Les métriques de toutes les instances de chaque groupe Auto Scaling sont regroupées et peuvent être affichées comme un tout.

"metrics": {
  "cpu":{...}
  "disk":{...}
  "aggregation_dimensions" : [["AutoScalingGroupName"]]
}

Pour déployer la combinaison de chacune des dimensions InstanceId et InstanceType en plus du déploiement sur le nom de groupe Auto Scaling, ajoutez les éléments suivants.

"metrics": {
  "cpu":{...}
  "disk":{...}
  "aggregation_dimensions" : [["AutoScalingGroupName"], ["InstanceId", "InstanceType"]]
}

Pour propager des métriques dans une collection, utilisez [].

"metrics": {
  "cpu":{...}
  "disk":{...}
  "aggregation_dimensions" : [[]]
}

Souvenez-vous que chaque fois que vous modifiez le fichier de configuration d'agent, vous devez ensuite redémarrer l'agent pour que les modifications prennent effet.

Collecte de métriques haute résolution avec l'agent CloudWatch

Le champ metrics_collection_interval indique l'intervalle de temps pour les métriques collectées, en quelques secondes. En spécifiant une valeur inférieure à 60 pour ce champ, les métriques sont collectées en haute résolution.

Par exemple, si toutes vos métriques doivent être en haute résolution et collectées toutes les 10 secondes, spécifiez 10 comme valeur pour metrics_collection_interval sous la section agent comme intervalle de collecte des métriques globales.

"agent": {
  "metrics_collection_interval": 10
}

Sinon, l'exemple suivant définit les métriques cpu à collecter chaque seconde, et toutes les autres métriques sont collectées toutes les minutes.

"agent":{  
  "metrics_collection_interval": 60
},
"metrics":{  
  "metrics_collected":{  
    "cpu":{  
      "resources":[  
        "*"
      ],
      "measurement":[  
        "cpu_usage_guest"
      ],
      "totalcpu":false,
      "metrics_collection_interval": 1
    },
    "disk":{  
      "resources":[  
        "/",
        "/tmp"
      ],
      "measurement":[  
        "total",
        "used"
      ]
    }
  }
}

Souvenez-vous que chaque fois que vous modifiez le fichier de configuration d'agent, vous devez ensuite redémarrer l'agent pour que les modifications prennent effet.

Envoi de métriques, de journaux et de traces à un autre compte

Pour que l'agent CloudWatch envoie les métriques, les journaux ou les traces à un autre compte, spécifiez un paramètre role_arn dans le fichier de configuration de l'agent sur le serveur d'envoi. La valeur role_arn spécifie un rôle IAM dans le compte cible que l'agent utilise pour envoyer des données vers le compte cible. Ce rôle permet au compte d'envoi d'assumer un rôle correspondant dans le compte de destination lorsque vous envoyez les métriques ou les journaux au compte de destination.

Vous pouvez également spécifier des chaînes role_arn distinctes dans le fichier de configuration de l'agent : une pour l'envoi de métriques, une autre pour l'envoi de journaux et une autre pour l'envoi de traces.

L'exemple suivant de l'extrait de la section agent du fichier de configuration paramètre l'agent afin qu'il utilise CrossAccountAgentRole pour envoyer des données à un compte différent.

{
  "agent": {
    "credentials": {
      "role_arn": "arn:aws:iam::123456789012:role/CrossAccountAgentRole"
    }
  },
  .....
}

Sinon, l'exemple suivant définit différents rôles que le compte d'envoi devra utiliser pour envoyer des métriques, des journaux et des traces :

"metrics": {
    "credentials": {
     "role_arn": "RoleToSendMetrics"
    },
    "metrics_collected": {....

"logs": {
    "credentials": {
    "role_arn": "RoleToSendLogs"
    },
    ....

Politiques requises

Lorsque vous spécifiez un role_arn dans le fichier de configuration de l'agent, vous devez également vous assurer que les rôles IAM des comptes d'envoi et de destination disposent de certaines stratégies. Les rôles des comptes d'envoi et de destination doivent avoir la politique CloudWatchAgentServerPolicy. Pour plus d'informations sur l'assignation de cette politique à un rôle, consultez Prérequis.

Le rôle dans le compte d'envoi doit également inclure la politique suivante. Vous ajoutez cette stratégie dans l'onglet Permissions (Autorisations) de la console IAM lorsque vous modifiez le rôle.

JSON

{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "sts:AssumeRole"
            ],
            "Resource": [
                "arn:aws:iam::111122223333:role/agent-role-in-target-account"
            ]
        }
    ]
}

Le rôle dans le compte de destination doit inclure la stratégie suivante, afin qu'il reconnaisse le rôle IAM utilisé par le compte d'envoi. Vous ajoutez cette stratégie dans l'onglet Trust relationships (Relations d'approbation) de la console IAM lorsque vous modifiez le rôle. Ce rôle est celui spécifié dans agent-role-in-target-account dans la politique utilisée par le compte d'envoi.

JSON

{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::111122223333:role/role-in-sender-account"
                ]
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

Différences d’horodatage entre l’agent CloudWatch et l’agent CloudWatch Logs antérieur

L'agent CloudWatch prend en charge un ensemble différent de symboles pour les formats d'horodatage, par rapport à l'ancien agent CloudWatch Logs. Ces différences figurent dans le tableau suivant.

Pour plus d'informations sur la signification des symboles pris en charge par le nouvel agent CloudWatch, consultez Fichier de configuration d'agent CloudWatch : section Logs dans le Guide de l'utilisateur Amazon CloudWatch. Pour plus d'informations sur les symboles pris en charge par l'agent CloudWatch Logs, consultez Fichier de configuration d'agent CloudWatch : section Logs dans le Guide de l'utilisateur Amazon CloudWatch Logs.

Ajout des fichiers de configuration du collecteur OpenTelemetry

L’agent CloudWatch prend en charge l’ajout de fichiers de configuration du collecteur OpenTelemetry supplémentaires, en plus de ses propres fichiers de configuration. Cette fonctionnalité vous permet d’utiliser des fonctionnalités telles que la vigie applicative CloudWatch ou Container Insights via la configuration de l’agent CloudWatch, tout en réutilisant votre configuration existante du collecteur OpenTelemetry, le tout à l’aide d’un seul agent.

Pour éviter les conflits de fusion avec les pipelines créés automatiquement par l’agent CloudWatch, nous vous recommandons d’ajouter un suffixe personnalisé à chaque composant et pipeline de votre configuration de votre collecteur OpenTelemetry.

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]
      

Pour configurer l’agent CloudWatch, démarrez-le à l’aide de l’option fetch-config et spécifiez le fichier de configuration de l’agent CloudWatch. L’agent CloudWatch nécessite au moins un fichier de configuration d’agent CloudWatch.

/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -c file:/tmp/agent.json -s

Ensuite, utilisez l’option append-config tout en spécifiant le fichier de configuration du collecteur OpenTelemetry.

/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a append-config -c file:/tmp/otel.yaml -s

L’agent fusionne les deux fichiers de configuration au démarrage et enregistre la configuration résolue.