Scénarios courants avec l' CloudWatchagent - Amazon CloudWatch

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.

Scénarios courants avec l' CloudWatchagent

Les sections suivantes expliquent comment effectuer les tâches courantes de configuration et de personnalisation de l' CloudWatch agent.

Exécution de l' CloudWatch agent en tant qu'utilisateur différent

Sur les serveurs Linux, il CloudWatch s'exécute en tant qu'utilisateur root par défaut. Pour que l'agent soit exécuté sous un autre nom d'utilisateur, utilisez le run_as_user paramètre figurant dans la agent section du fichier de configuration de l' CloudWatch agent. 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.

Pour exécuter l' CloudWatch agent en tant qu'utilisateur différent sur une instance EC2 exécutant Linux
  1. Téléchargez et installez un nouveau package CloudWatch d'agent. Pour plus d’informations, consultez Téléchargez le package de CloudWatch l'agent.

  2. Créez un nouvel utilisateur Linux ou utilisez l'utilisateur par défaut nommé cwagent créé par le fichier DEB ou RPM.

  3. Utilisez l'une des méthodes suivantes pour fournir les informations d'identification de cet utilisateur :

    • Si le fichier .aws/credentials existe dans le répertoire personnel de l'utilisateur root, vous devez créer un fichier d'informations d'identification pour l'utilisateur que vous allez utiliser pour exécuter l' CloudWatch agent. Ce fichier d'informations d'identification sera /home/username/.aws/credentials. Ensuite, affectez le chemin du fichier d'informations d'identification en tant que valeur du paramètre shared_credential_file dans common-config.toml. Pour de plus amples informations, consultez (Facultatif) Modifiez la Configuration commune pour les informations de proxy ou de région.

    • Si le fichier .aws/credentials n'existe pas dans le répertoire personnel de l'utilisateur racine, vous pouvez procéder de l'une des manières suivantes :

      • Créez un fichier d'informations d'identification pour l'utilisateur que vous allez utiliser pour exécuter l' CloudWatch agent. Ce fichier d'informations d'identification sera /home/username/.aws/credentials. Ensuite, affectez le chemin du fichier d'informations d'identification en tant que valeur du paramètre shared_credential_file dans common-config.toml. Pour de plus amples informations, consultez (Facultatif) Modifiez la Configuration commune pour les informations de proxy ou de région.

      • Au lieu de créer un fichier d'informations d'identification, associez un rôle IAM à l'instance. L'agent utilise ce rôle en tant que fournisseur d'informations d'identification.

  4. Dans le fichier de configuration de l' CloudWatch agent, ajoutez la ligne suivante dans la agent section :

    "run_as_user": "username"

    Vous pouvez apporter d'autres modifications au fichier de configuration en fonction des besoins. Pour de plus amples informations, veuillez consulter Création du fichier de configuration de CloudWatch l'agent

  5. Donnez à l'utilisateur les autorisations requises. L'utilisateur doit disposer des autorisations Read (r) pour que les fichiers journaux soient collectés et de l'autorisation Execute (x) sur chaque répertoire du chemin des fichiers journaux.

  6. Démarrez l'agent avec le fichier de configuration que vous venez de modifier.

    sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c file:configuration-file-path
Pour exécuter l' CloudWatch agent en tant qu'utilisateur différent sur un serveur local exécutant Linux
  1. Téléchargez et installez un nouveau package CloudWatch d'agent. Pour plus d’informations, consultez Téléchargez le package de CloudWatch l'agent.

  2. Créez un nouvel utilisateur Linux ou utilisez l'utilisateur par défaut nommé cwagent créé par le fichier DEB ou RPM.

  3. Stockez les informations d'identification de cet utilisateur dans un dossier auquel l'utilisateur peut accéder, tel que /home/username/.aws/credentials.

  4. Affectez le chemin du fichier d'informations d'identification en tant que valeur du paramètre shared_credential_file dans common-config.toml. Pour plus d’informations, consultez (Facultatif) Modifiez la Configuration commune pour les informations de proxy ou de région.

  5. Dans le fichier de configuration de l' CloudWatch agent, ajoutez la ligne suivante dans la agent section :

    "run_as_user": "username"

    Vous pouvez apporter d'autres modifications au fichier de configuration en fonction des besoins. Pour de plus amples informations, veuillez consulter Création du fichier de configuration de CloudWatch l'agent

  6. Donnez à l'utilisateur les autorisations requises. L'utilisateur doit disposer des autorisations Read (r) pour que les fichiers journaux soient collectés et de l'autorisation Execute (x) sur chaque répertoire du chemin des fichiers journaux.

  7. Démarrez l'agent avec le fichier de configuration que vous venez de modifier.

    sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c file:configuration-file-path

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

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.

Toutefois, l' CloudWatch agent 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. De ce fait, l' CloudWatch agent publie autant d'octets que la taille apparente d'un fichier fragmenté. CloudWatch

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

Ajouter des dimensions personnalisées aux métriques collectées par l' CloudWatch agent

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.

Plusieurs fichiers CloudWatch de configuration d'agents

Sur les serveurs Linux et Windows, vous pouvez configurer l' CloudWatch agent pour qu'il utilise plusieurs fichiers de configuration. Par exemple, vous pouvez utiliser un fichier de configuration courant qui recueille un ensemble de métriques, de journaux et de traces que vous souhaitez toujours collecter à partir de tous les serveurs dans votre infrastructure. Vous pouvez alors utiliser les fichiers de configuration supplémentaires qui collectent des métriques de certaines applications ou dans certaines situations.

Pour cette configuration, commencez par créer les fichiers de configuration que vous souhaitez utiliser. Tous les fichiers de configuration qui seront utilisés ensemble sur le même serveur doivent avoir différents noms de fichiers. Vous pouvez stocker les fichiers de configuration sur les serveurs ou dans le Parameter Store.

Démarrez l' CloudWatch agent à l'aide de l'fetch-configoption et spécifiez le premier fichier de configuration. Pour ajouter le second fichier de configuration pour l'agent en cours d'exécution, utilisez la même commande, mais avec l'option append-config. L'ensemble des métriques, des journaux et des traces répertoriés dans l'un ou l'autre fichier de configuration sont collectés. Les exemples de commandes suivants illustrent ce scénario en utilisant des stockages de configurations sous forme de fichiers. La première ligne démarre l'agent à l'aide du fichier de configuration infrastructure.json et la seconde ligne ajoute le fichier de configuration app.json.

Les exemples de commandes suivants concernent Linux.

/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c file:/tmp/infrastructure.json
/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a append-config -m ec2 -s -c file:/tmp/app.json

Les exemples de commandes suivants concernent Windows Server.

& "C:\Program Files\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1" -a fetch-config -m ec2 -s -c file:"C:\Program Files\Amazon\AmazonCloudWatchAgent\infrastructure.json"
& "C:\Program Files\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1" -a append-config -m ec2 -s -c file:"C:\Program Files\Amazon\AmazonCloudWatchAgent\app.json"

Les exemples de fichiers de configuration suivants illustrent une utilisation pour cette fonction. Le premier fichier de configuration est utilisé pour tous les serveurs de l'infrastructure. Le second collecte des journaux uniquement à partir d'une application et est ajouté aux serveurs exécutant cette application.

infrastructure.json

{ "metrics": { "metrics_collected": { "cpu": { "resources": [ "*" ], "measurement": [ "usage_active" ], "totalcpu": true }, "mem": { "measurement": [ "used_percent" ] } } }, "logs": { "logs_collected": { "files": { "collect_list": [ { "file_path": "/opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log", "log_group_name": "amazon-cloudwatch-agent.log" }, { "file_path": "/var/log/messages", "log_group_name": "/var/log/messages" } ] } } } }

app.json

{ "logs": { "logs_collected": { "files": { "collect_list": [ { "file_path": "/app/app.log*", "log_group_name": "/app/app.log" } ] } } } }

Tous les fichiers de configuration ajoutés à la configuration doivent avoir des noms de fichiers différents les uns des autres et du fichier de configuration initiale. Si vous utilisez append-config avec un fichier de configuration ayant le même nom de fichier qu'un fichier de configuration que l'agent utilise déjà, la commande Ajouter écrasera les informations provenant du premier fichier de configuration, au lieu d'effectuer un ajout. C'est le cas même si les deux fichiers de configuration avec le même nom de fichier sont sur différents chemins de fichier.

L'exemple précédent montre l'utilisation des deux fichiers de configuration, mais il n'y a pas de limite au nombre de fichiers de configuration que vous pouvez ajouter à la configuration de l'agent. Vous pouvez également combiner l'utilisation des fichiers de configuration situés sur les serveurs et les configurations situées dans le Parameter Store.

Agrégation ou agrégation des 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' CloudWatch agent envoie les métriques, les journaux ou les traces à un autre compte, spécifiez un role_arn paramètre 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 Créez des rôles IAM à utiliser avec l' CloudWatch agent sur les instances Amazon EC2.

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.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "sts:AssumeRole" ], "Resource": [ "arn:aws:iam::target-account-ID: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. Le rôle dans le compte de destination dans lequel vous ajoutez cette politique est le rôle que vous avez créé dans Création de rôles et d'utilisateurs IAM à utiliser avec l'agent CloudWatch . Ce rôle est celui spécifié dans agent-role-in-target-account dans la politique utilisée par le compte d'envoi.

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

Différences d'horodatage entre l' CloudWatch agent unifié et l'ancien CloudWatch agent Logs

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

Symboles pris en charge par les deux agents Symboles pris en charge uniquement par CloudWatch l'agent unifié Symboles pris en charge uniquement par l'ancien agent CloudWatch Logs

%A, %a, %b, %B, %d, %f, %H, %l, %m, %M, %p, %S, %y, %Y, %Z, %z

%-d, %-l, %-m, %-M, %-S

%c, %j, %U, %W, %w

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