干してた布団が通り雨にやられました、技術1課の松田です。
今回はCloudWatch Agentを使ったカスタムメトリクスの取得方法についてです。
あまり利用されていないのかいまひとつ情報が出てこず、ちょっと苦戦したので備忘録がてら記事にしようと思います。
CloudWatch Agentとは
その名の通り、CloudWatchのエージェントツールのことです。
CloudWatch Agent（以下、Agent）を使用することで、通常のCloudWatchよりも詳細なメトリクスを取得することができるようになります。
Agentによって取得可能となるメトリクスのことは「カスタムメトリクス」と呼びます。
Windowsの場合、パフォーマンス モニターで収集できる「カウンター」をカスタムメトリクスとして取得することが可能です。
画像は実際のパフォーマンスモニターの画面ですが、ここに表示されるすべてのカウンターから好きなものを収集できる、ということですね。
ちなみにAgentなしで取得できるメトリクスの一覧はこちらです。
またAgentはEC2だけでなく、オンプレミスのサーバーにインストールして使用することも可能です。
今回の構成
今回の構成は以下の通りです。
VPC Endpointは使用せず、Internet Gateway経由でCloudWatchにプッシュでデータを送信します。
EC2はMicrosoft Windows Server 2019 BaseのAMIを使用しています。
導入手順
1. IAMロールの作成とアタッチ
Agentをインストールする前に、EC2インスタンスにCloudWatchへの書き込み権限を付与する必要があります。
AWS管理ポリシーである「CloudWatchAgentServerPolicy」をアタッチしたIAMロールを作成し、EC2インスタンスに適用しておきます。
詳細な手順は公式ドキュメントを参照下さい。
ちなみにオンプレミスのサーバーの場合は、IAMユーザーのクレデンシャルを埋め込む必要があります。
2. CloudWatch Agentのインストール
msiが公式で配布されていますので、インスタンスにダウンロード＆インストールします。
アクセスするとすぐにmsiがダウンロードされますのでご留意ください。
https://s3.amazonaws.com/amazoncloudwatch-agent/windows/amd64/latest/amazon-cloudwatch-agent.msi
3. CloudWatch Agentの設定ファイルを作成する
インストールが完了したら、Agentの起動前にjson形式の設定ファイルを作成する必要があります。
設定ファイルの作成方法は次の2つです。
ウィザードを使用して作成する
手動で作成する
手順は割愛しますが、今回は公式ドキュメントを参考にウィザードから作成しました。
4. いったん動作確認
これで準備は整ったので、動作確認の意味で一度Agentを起動してみます。
Powershellから以下のコマンドで起動します。
> cd 'C:\Program Files\Amazon\AmazonCloudWatchAgent\' > & "C:\Program Files\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1" -a fetch-config -m ec2 -s -c file:config.json
ここでCloudWatchのマネジメントコンソールを見てみると、「CWAgent」という名前でカスタム名前空間が作成されています。
中を覗いてみると、メモリとディスク利用率のメトリクスが取得されていました。
Agentの設定ファイルをウィザードから作成すると、デフォルトでこの2つを引っ張ってくるようになってるみたいです。
ちなみにキャプチャしたタイミングの関係で、上の画像だとCWAgentが「4メトリクス」になっていますが、この時点では「2メトリクス」が正しいです。
5. カスタムメトリクスの設定
準備が一通り終わったところで、取得したいカスタムメトリクスを追加してみます。
3. で作成された設定ファイルで、パフォーマンスモニターのどのカウンターをカスタムメトリクスとしてを取得するかが定義されています。
ウィザードで自動生成した私の環境では、以下のような中身になっていました。
{
"logs": {
"logs_collected": {
"windows_events": {
"collect_list": [
{
"event_format": "xml",
"event_levels": [
"VERBOSE",
"INFORMATION",
"WARNING",
"ERROR",
"CRITICAL"
],
"event_name": "System",
"log_group_name": "System",
"log_stream_name": "{instance_id}"
}
]
}
}
},
"metrics": {
"append_dimensions": {
"AutoScalingGroupName": "${aws:AutoScalingGroupName}",
"ImageId": "${aws:ImageId}",
"InstanceId": "${aws:InstanceId}",
"InstanceType": "${aws:InstanceType}"
},
"metrics_collected": {
"LogicalDisk": {
"measurement": [
"% Free Space"
],
"metrics_collection_interval": 60,
"resources": [
"*"
]
},
"Memory": {
"measurement": [
"% Committed Bytes In Use"
],
"metrics_collection_interval": 60
},
"statsd": {
"metrics_aggregation_interval": 60,
"metrics_collection_interval": 10,
"service_address": ":8125"
}
}
}
}
公式ドキュメントに沿って、これを読み解いていきます。
まず前半の"log"セクションはCloudWatch Logsの設定なので、ここでは割愛させていただきます。
カスタムメトリクスの設定は、後半の"metrics"セクションで記述されています（以下は抜粋）。
"metrics": {
"append_dimensions": {
"AutoScalingGroupName": "${aws:AutoScalingGroupName}",
"ImageId": "${aws:ImageId}",
"InstanceId": "${aws:InstanceId}",
"InstanceType": "${aws:InstanceType}"
},
"metrics_collected": {
"LogicalDisk": {
"measurement": [
"% Free Space"
],
"metrics_collection_interval": 60,
"resources": [
"*"
]
},
"Memory": {
"measurement": [
"% Committed Bytes In Use"
],
"metrics_collection_interval": 60
},
"statsd": {
"metrics_aggregation_interval": 60,
"metrics_collection_interval": 10,
"service_address": ":8125"
}
}
}
}
パッと見、"LogicalDisk"や"Memory"などの部分がパフォーマンスモニターのカウンターと対応していそうです。
というわけで、以下はパフォーマンスモニターのカウンターリストの画面ですが、この中を探してみると...。
"LogicalDisk"カテゴリの中に"% Free Space"という名前のカウンターを見つけることができました。
（省略しますが、"Memory"の中に"% Committed Bytes In Use"もしっかりありました。）
さて、ここまで確認した結果を踏まえると、パフォーマンスモニターのカウンターをカスタムメトリクスとして収集するには、取得したいカウンターの表示名をそのまま設定ファイルに入れ込めばよさそうです。
試しに、プロセッサーの利用率を示す"% Proccessor Time"のカウンターを取得するように設定してみます。
抜粋するとこんな感じですね。
"Processor Information": {
"measurement": [
"% Processor Time"
],
"metrics_collection_interval": 60,
"resources": [
"*"
]
},
補足ですが、"metrics_collection_interval" は、メトリクスをCloudWatchに60秒おきに送信するという意味です。
また"resources"でワイルドカード（"*"）を指定していますが、この場合はCPU全てのコアのメトリクスを収集するという意味です。
今回はインスタンスタイプにt3.mediumを選択していますので、2コア分のメトリクスがCloudWatchで取得されることになります。
このあたりの記述については、上述の公式ドキュメントに詳細が記載されています。
では設定ファイルを保存して、Powershellから改めてAgentの起動コマンドを実行します。
> cd 'C:\Program Files\Amazon\AmazonCloudWatchAgent\' > & "C:\Program Files\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1" -a fetch-config -m ec2 -s -c file:config.json
Agentの再起動が完了しました。
****** processing amazon-cloudwatch-agent ****** Successfully fetched the config and saved in C:\ProgramData\Amazon\AmazonCloudWatchAgent\Configs\file_config.json.tmp Start configuration validation... 2021/11/02 03:33:51 Reading json config file path: C:\ProgramData\Amazon\AmazonCloudWatchAgent\Configs\file_config.json.tmp ... Valid Json input schema. No csm configuration found. Configuration validation first phase succeeded Configuration validation second phase succeeded Configuration validation succeeded AmazonCloudWatchAgent has been stopped AmazonCloudWatchAgent has been started
6. マネジメントコンソールで確認
最後に、Agentからちゃんとメトリクスが送信されているか確認しておきます。
無事に取得できていますね。
ちなみに私の環境では、Agent再起動からマネジメントコンソールに反映されるまでに数分かかりました。
アレ、反映されないぞ...と思っても、しばらく待ってみましょう。
まとめ
というわけで、CloudWatch Agentを使用してカスタムメトリクスを取得することができました。
取得できる項目は多岐にわたるので、具体的にどんなメトリクスが取れるのか、どう活用できるのかは引き続き勉強していきたいところです。
松田 渓(記事一覧)
2021年10月入社。散歩が得意です。
