皆様こんにちは！
ネットワールドでAWSやMicrosoftのクラウド製品を担当しているSEの碇です。
本日は、AWSのCloudWatchというサービスを用いて、OS内のログをCloudWatch logsへ取得する方法をご説明します。
特に今回は、WindowsのイベントログをCloudWatch logsへ取得する方法をご説明しようと思います。
CloudWatch logsを利用することで、OSにログインをせずAWSコンソールからイベントログを確認することができます。
Linuxの場合もほぼ手順は変わらず、/var/log/messagesなどのOS内のログを取得することが可能ですので、ブログ内で参考資料を共有していきます。
CloudWatchとは
CloudWatchとは、AWS上のサービスやリソースの監視を行えるサービスです。
従来のオンプレとは異なり、監視サーバーを用意しなくても簡単に監視の設定を行うことができます。設定したしきい値を超えるとメールアドレスへの通知を行うことも可能です。
簡単なメトリクス監視であれば、Agentをインストールすることなく監視が可能です。
参考資料：
Amazon CloudWatch とは - Amazon CloudWatch
今回はその中でもEC2の監視について取り上げます。
CloudWatch Agent
Agentのインストールがなく監視ができるメトリクスもありますが、より詳細に監視を行うため、今回は、CloudWatch Agentをインストールする必要があるログの監視についてご説明します。
また、よく取得するものとして挙げられるメモリ・ディスクの使用量監視についても、Agentのインストールが必要になるため、あわせてご説明します。
ログについては、CloudWatch logsにすべてのイベントログを取得すると課金が高くなってしまうため、今回は重大、警告、エラーだけに絞って取得します。
作業の流れ
作業の流れは以下になります。
⓪前提作業（IAMロールの付与）
①EC2にCloudWatch Agentをインストール
②CloudWatch Agent Wizardを実行して、CloudWatch設定ファイルを編集
⇒メモリ・ディスクや、ログの監視を行えるように設定
③設定ファイルを用いてCloudWatch Agentを起動
④（必要に応じて）通知を行う
以下のAWSドキュメントを参考に検証、ブログを作成しております。
CloudWatch エージェントを使用してメトリクス、ログ、トレースを収集する - Amazon CloudWatch
作業手順
それでは早速作業手順の説明を始めていきます。
⓪前提作業（IAMロールの付与）
EC2でCloudWatchを利用するためには、IAMを利用して利用権限を付与させる必要があります。
IAMとは、AWS リソースへのアクセスを安全に管理するためのウェブサービスです。IAM を使用すると、ユーザーがアクセスできる AWS のリソースを制御するアクセス許可を管理できます。
IAM とは - AWS Identity and Access Management
今回EC2に付与する必要があるのは、以下の前提条件にある通り[CloudWatchAgentServerPolicy]です。
[CloudWatchAgentServerPolicy]はIAMポリシーなので、このポリシーを付与したIAMロールを作成し、EC2に割り当てる流れとなります。
[CloudWatchAgentServerPolicy]はすでにAWSにて作成されているIAMポリシーですので、IAMで必要な作業はIAMロールを作成するのみです。
AWSコンソールにログイン後、IAMを選択して、ロール＞ロールを作成をクリックします。
信頼されたエンティティを選択画面が表示されます。
信頼されたエンティティタイプで「AWSのサービス」、ユースケースでは「EC2」を選択し、次へをクリックします。
続いてIAMポリシーの選択画面が表示されます。
[CloudWatchAgentServerPolicy]を選択して、次へをクリックします。
ロール名を入力して、設定値があっていることを確認出来たらロールを作成をクリックします。
今回はAWSドキュメントにある通り[CloudWatchAgentServerRole]名のIAMロールを作成しました。
前提条件 - Amazon CloudWatch
IAMロールの作成が完了したら、EC2に付与します。
AWSコンソールからEC2を選択して、今回CloudWatch Agentを導入する予定のインスタンスを選択します。
インスタンスを選択後、アクション＞セキュリティ＞IAMロールを変更をクリックします。
IAMロールを変更画面が表示されるので、先ほど作成した[CloudWatchAgentServerRole]を選択して、IAMロールの更新をクリックします。
IAMロールの変更後はEC2の再起動が必要です。実施できるタイミングで再起動してください。
ここまででCloudWatch Agent導入の前提準備が完了しました。
ここからはインスタンスへCloudWatch Agentをインストールしていきます。
①EC2にCloudWatch Agentをインストール
CloudWatch Agentのインストールは、今回はコマンドで手動で実施します。
対象のEC2が複数台ある場合、かつEC2がインターネットに繋がる環境であれば、Systems Managerを利用して一度にインストールすることが可能です。大規模環境での構築はSystems Managerの利用が必須になるかと思います。
Systems Managerを利用してCloudWatch Agentをインストールする方法についてもブログを作成中ですので、詳細はそちらをご覧ください。
前置きが長くなりましたが、インスタンスにログインしてCloudWatch Agentをインストールしていきます。
以下のAWSドキュメントに記載しているURLにアクセスし、msiをダウンロードします。
Amazon EC2 に手動でインストールする - Amazon CloudWatch
ダウンロードが完了した後、以下のコマンドを実行するか、ダウンロードしたmsiをダブルクリックして実行させ、インストールします。
>msiexec /i amazon-cloudwatch-agent.msi
上記のAWSドキュメントにはLinuxのコマンドも記載しているので、Linuxで実行する場合の参考にしてください。
インストールが完了したら、CloudWatch Agent設定ファイルの作成に入っていきます。
②CloudWatch Agent Wizardを実行して、CloudWatch設定ファイルを編集
どのイベントログを取得するかや、どのレベルでメトリクスを監視するかは、CloudWatch Agent実行時に設定ファイルを読み込むことで設定できます。
この設定ファイルは、CloudWatch Agentをインストールした際に自動的にインストールされていた、CloudWatch Agent Wizardを利用して作成することができます。
以下のコマンドを実行して、設定ファイルを作成するWizardを実行させます。
>cd "C:\Program Files\Amazon\AmazonCloudWatchAgent“
>.\amazon-cloudwatch-agent-config-wizard.exe
コマンドを実行すると、自動的にWizardが開きます。
参考資料はこちらです。こちらのAWSドキュメントにはLinux用のコマンドの記載もございます。
ウィザードを使用して CloudWatch エージェント設定ファイルを作成する - Amazon CloudWatch
Wizardでは、どのように設定ファイルを設定するか質問されるので、1つ1つ答えていきます。
2026/6時点でのWizardの中身をご説明していきます。
・CloudWatch Agent実行OS
On which OS are you planning to use the agent?
1. linux
2. windows
3. darwin
default choice: [2]:
2
Agentの実行OSを聞かれるので、今回はWindows[2]を入力します。
・実行インスタンス
Trying to fetch the default region based on ec2 metadata...
I! imds retry client will retry 1 timesAre you using EC2 or On-Premises hosts?
1. EC2
2. On-Premises
default choice: [1]:
1
今回はEC2インスタンスなので、[1]を入力します。
・StatsDデーモンの利用有無
Do you want to turn on StatsD daemon?
1. yes
2. no
default choice: [1]:
1
メモリ、ディスクの監視を行う場合、StatsDデーモンをインストールする必要があるので[1]を入力します。
・StatsDデーモンの利用ポート
Which port do you want StatsD daemon to listen to?
default choice: [8125]
StatsDデーモン用のポートを聞かれます。今回はデフォルトのままで設定するのでそのままEnterを押下します。
・StatsDデーモンが情報を取得する際の時間間隔
What is the collect interval for StatsD daemon?
1. 10s
2. 30s
3. 60s
default choice: [1]:
1
StatsDデーモンが情報を取得する際の間隔は、デフォルトの[1]を選択しました。
・StatsDデーモンがメトリクスを取得する際の時間間隔
What is the aggregation interval for metrics collected by StatsD daemon?
1. Do not aggregate
2. 10s
3. 30s
4. 60s
default choice: [4]:
4
StatsDデーモンがメトリクスを取得する際の間隔も、デフォルトの[4]を選択しました。
・CloudWatch log Agentが既に存在するか
Do you have any existing CloudWatch Log Agent configuration file to import for migration?
1. yes
2. no
default choice: [2]:
2
まだインスタンスにCloudWatch Log Agentは存在していないため、[2]を選択します。
・CPU, memoryなどのメトリクスを取得するかどうか
Do you want to monitor any host metrics? e.g. CPU, memory, etc.
1. yes
2. no
default choice: [1]:
1
CPU, memoryなどのメトリクスは取得したいため、[1]を選択します。
・1コアあたりのCPUメトリクスを取得するかどうか
Do you want to monitor cpu metrics per core?
1. yes
2. no
default choice: [1]:
1
1コアあたりのCPUメトリクスについても、取得する場合は[1]を選択します。
・EC2メトリクスのディメンションを以下のように表示するかどうか
Do you want to add ec2 dimensions (ImageId, InstanceId, InstanceType, AutoScalingGroupName) into all of your metrics if the info is available?
1. yes
2. no
default choice: [1]:
1
EC2メトリクスのディメンションとして上記を表示させたい場合は[1]を選択します。
※ディメンションとは、メトリクスのアイデンティティの一部である名前と値のペアのことです。
・EC2メトリクスのディメンションを以下のように表示するかどうか
Do you want to aggregate ec2 dimensions (InstanceId)?
1. yes
2. no
default choice: [1]:
1
EC2メトリクスのディメンションとして上記を表示させたい場合は[1]を選択します。
・メトリクスを高頻度で収集するかどうか
Would you like to collect your metrics at high resolution (sub-minute resolution)? This enables sub-minute resolution for all metrics, but you can customize for specific metrics in the output json file.
1. 1s
2. 10s
3. 30s
4. 60s
default choice: [4]:
4
メトリクスを高頻度で収集するかどうかを設定します。今回はデフォルトの[4]を選択しました。
・メトリクスセットのレベル選択
Which default metrics config do you want?
1. Basic
2. Standard
3. Advanced
4. None
default choice: [1]:
1
続いてメトリクスセットのレベルを選択します。今回は、メモリとディスクのみを取得したいので[1]を選択しました。
ウィザードを使用して CloudWatch エージェント設定ファイルを作成する - Amazon CloudWatch
・ここまでの設定ファイルが表示される
Current config as follows:
{
"metrics": {
"aggregation_dimensions": [
[
"InstanceId"
]
],
"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"
}
}
}
}
上記の設定ファイルで特に問題がない場合は続いての質問に[1]で回答します。
Are you satisfied with the above config? Note: it can be manually customized after the wizard completes to add additional items.
1. yes
2. no
default choice: [1]:
1
・カスタムログを取得するかどうか
Do you want to monitor any customized log files?
1. yes
2. no
default choice: [1]:
2
今回はイベントログのみを取得して、カスタムでログは取得しないので[2]を入力しました。
・イベントログを取得するかどうか
Do you want to monitor any Windows event log?
1. yes
2. no
default choice: [1]:
1
今回のブログのメインでもある、イベントログを取得するかどうかの設定です。
今回はイベントログを取得したいので[1]を入力します。
・取得したいイベントログのログ名
Windows event log name:
default choice: [System]
取得したいイベントログのログ名を聞かれます。Systemsログは取得したいのでそのままEnterを押下します。
・取得したいログのレベル
Do you want to monitor VERBOSE level events for Windows event log System ?
1. yes
2. no
default choice: [1]:
2
Do you want to monitor INFORMATION level events for Windows event log System ?
1. yes
2. no
default choice: [1]:
2
Do you want to monitor WARNING level events for Windows event log System ?
1. yes
2. no
default choice: [1]:
1
Do you want to monitor ERROR level events for Windows event log System ?
1. yes
2. no
default choice: [1]:
1
Do you want to monitor CRITICAL level events for Windows event log System ?
1. yes
2. no
default choice: [1]:
1
取得したいログのレベルについて聞かれています。
今回は重大、警告、エラーだけに絞って取得したいため、WARNING、ERROR、CRITICALのみ[1]、そのほかは[2]を入力しました。
・特別に取得したいイベントID
Do you want to filter by specific Event IDs?
1. yes
2. no
default choice: [1]:
2
特別に取得したいイベントIDがある場合は入力します。
今回は特にないので[2]を入力しました。
・regex filtersを追加するかどうか
Do you want to add regex filters to include/exclude specific events?
1. yes
2. no
default choice: [1]:
2
regex filtersは追加しないので[2]を選択しました。
・CloudWatch logsのロググループ名
Log group name:
default choice: [System]
Systemログを保存するCloudWatch logsのロググループ名を指定します。
今回は[System]で保存するので、そのままEnterを押下しました。
・CloudWatch logsのログストリーム名
Log stream name:
default choice: [{instance_id}]
ロググループの配下にはログストリームがあり、今回のイベントログはこのログストリームに保存される動きとなります。
ログストリーム名はデフォルトのインスタンスIDで保存しますので、そのままEnterを押下しました。
特に複数のインスタンスでログを取得する場合は、インスタンスIDで保存するのが一番わかりやすいかと存じます。
・ロググループのログクラス
Which log group class would you like to have for this log group?
1. STANDARD
2. INFREQUENT_ACCESS
default choice: [1]:
1
続いて保存するロググループのログクラスを選択します。今回は低頻度ではなくスタンダードを選びました。[1]を入力します。
ログクラス - Amazon CloudWatch Logs
・ログのフォーマット
In which format do you want to store windows event to CloudWatch Logs?
1. XML: XML format in Windows Event Viewer
2. Plain Text: Legacy CloudWatch Windows Agent (SSM Plugin) Format
default choice: [1]:
1
ログを取得する際のフォーマットについては、デフォルトの[1]を選択しました。
・ロググループの保持期間
Log Group Retention in days
1. -1
2. 1
3. 3
4. 5
5. 7
6. 14
7. 30
8. 60
9. 90
10. 120
11. 150
12. 180
13. 365
14. 400
15. 545
16. 731
17. 1096
18. 1827
19. 2192
20. 2557
21. 2922
22. 3288
23. 3653
default choice: [1]:
3
ロググループの保持期間は[3]を選択しました。ログ保持要件によって選択してください。
「-1」を指定すると、無制限でログが保持されるようになります。
・他にもイベントログを取得するかどうか
Do you want to specify any additional Windows event log to monitor?
1. yes
2. no
default choice: [1]:
2
他にもイベントログを取得したい場合は[1]を入力します。
Applicationログなど追加でログを取得したい場合は、[1]を入力し、先ほどまでで設定した設定を追加で行います。
今回はSystemログのみ取得するため、[2]を選択しました
・X-rayを利用するかどうか
Do you want the CloudWatch agent to also retrieve X-ray traces?
1. yes
2. no
default choice: [1]:
2
X-rayは利用しないので[2]を入力しました。
※AWS X-Ray はアプリケーションが処理するリクエストに関するデータを収集するサービスです。
・ここまでの設定ファイルと、そのコピー場所が表示される
Existing config JSON identified and copied to: C:\Users\Administrator\AppData\Roaming\Amazon\CloudWatchAgent\etc\backup-configs
Saved config file to config.json successfully.
Current config as follows:
{
"logs": {
"logs_collected": {
"files": {
"collect_list": [
{
"file_path": "",
"log_group_class": "STANDARD",
"log_group_name": ".",
"log_stream_name": "{instance_id}",
"retention_in_days": 1
}
]
},
"windows_events": {
"collect_list": [
{
"event_format": "xml",
"event_levels": [
"WARNING",
"ERROR",
"CRITICAL"
],
"event_name": "System",
"log_group_class": "STANDARD",
"log_group_name": "System",
"log_stream_name": "{instance_id}",
"retention_in_days": 3
}
]
}
}
},
"metrics": {
"aggregation_dimensions": [
[
"InstanceId"
]
],
"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"
}
}
}
}
・設定ファイルをSystems Managerのパラメーターストアに保存するかどうか
Please check the above content of the config.
The config file is also located at config.json.
Edit it manually if needed.
Do you want to store the config in the SSM parameter store?
1. yes
2. no
default choice: [1]:
2
ここまで設定してきた設定ファイルをSystems Managerのパラメーターストアに保存する場合は[1]を入力します。
「①EC2にCloudWatch Agentをインストール」でも少し触れていた通り、複数台のインスタンスでCloudWatch Agentをインストールする場合は、
設定ファイルをパラメーターストアに保存し、保存された設定ファイルを利用して展開します。
パラメーターストアへの保存が必要ない場合は[2]を選択してください。
詳細は次回のブログで触れますが、パラメータストアへの保存には、EC2へまた別のIAMロールが必要になりますので、ご注意ください。
設定ファイルの内容はこれで終了です。
③設定ファイルを用いてCloudWatch Agentを起動
続いて、②で作成したCloudWatch Agentの設定ファイルを参照させながらCloudWatch Agentを起動します。
以下のコマンドを実行します。
>& "C:\Program Files\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1" -a fetch-config -m ec2 -s -c file:”C:\Program Files\Amazon\AmazonCloudWatchAgent\config.json”
【設定ができているかの確認】
1.CloudWatch logs
CloudWatch Agentが起動できたら、AWSコンソールからCloudWatchを確認してみましょう。
まずはログを確認してみます。
AWSコンソールから、CloudWatch＞ログ＞ログ管理をクリックします。
ロググループから取得した「System」を検索します。
Systemをクリックすると、インスタンスIDのログストリームが作成されています。
ログストリームをクリックすると、イベントログが取得できていることが確認できました。
2.メトリクス
続いて、メモリとディスク容量監視用のメトリクスが作成されていることを確認します。
AWSコンソールから、CloudWatch＞すべてのメトリクスをクリックします。
今回取得したメトリクスは、「CWAgent」に格納されています。
先ほどのWizardでも指定した、InstanceIdをクリックします。
ディスク使用量の「disk_used_percent」、メモリ使用量の「mem_used_percent」が表示されていることが確認できました。
ここまででCloudWatch Agentでの設定は完了です。この後は、必要に応じて通知の設定を行います。
④（必要に応じて）通知を行う
1.ログの通知
今回はイベントログの内、重大、警告、エラーのみに絞って取得しております。重大、警告、エラーのログが出力された場合、特定のメールアドレスなどへの通知が必要な場合は以下の手順に沿って通知の設定を行います。
ログの通知の場合は、メトリクスフィルターを利用して、
メトリクスを作成⇒作成したメトリクスからアラームを作成するという流れになります。
それではメトリクスフィルターを作成していきます。
AWSコンソールから、CloudWatch＞ログ＞ログ管理をクリックします。
ロググループから取得した「System」を検索します。
メトリクスフィルター＞メトリクスフィルターを作成をクリックします。
メトリクスフィルターの作成画面で以下のフィルターパターンを入力し、次へをクリックします。
?"<Level>エラー</Level>" ?"<Level>Error</Level>" ?"<Level>Critical</Level>" ?"<Level>重大</Level>" ?"<Level>Warning</Level>" ?"<Level>警告</Level>"
※今回はOSを日本語化しているため、英語と日本語両方で「重大、警告、エラー」をフィルターさせています。
任意のメトリクスフィルター名、メトリクス名前空間、メトリクス名を入力し、メトリクス値に1を入力して、他はデフォルトのまま次へをクリックします。
設定値を確認して、メトリクスフィルターを作成をクリックします。
続いて、作成したメトリクスフィルターからアラームを作成していきます。
メトリクスフィルターが作成できたら、メトリクスフィルターを選択して、アラームを作成をクリックします。
アラーム作成画面に遷移します。
条件を先ほど設定したメトリクス値の1以上に設定し、それ以外はデフォルトのままで次へをクリックします。
続いて、アラーム状態になった際の動作を設定していきます。
今回は通知のみを行いたいので、アラーム状態のSNSを選択します。
SNSの作成方法については割愛しますが、今回は既存のSNSトピックを選択しました。
Amazon SNS トピックを作成する - Amazon Simple Notification Service
作成しているアラームのアラーム名を入力して、次へをクリックします。
次へをクリックすると設定値の確認画面になるので、設定値を確認した後アラームの作成をクリックします。
テストとしてコマンドで疑似ログを作成させたところ、SNS通知先のメールアドレスにアラームメールが届いたことを確認できました。
2.ディスク、メモリの通知
ディスクとメモリの通知については、先ほどメトリクスがあることが確認できたので、そのメトリクスを用いたアラーム作成を実施します。
先ほど「1.ログの通知」でご説明したアラームの作成と内容はほぼ一緒です。
AWSコンソールから、CloudWatch＞アラームをクリックします。
タイプはデフォルトのままクラシックを選択し、メトリクスでディスクまたはメモリを選択します。
今回はディスクを選択し、条件を90%以上としました。
ディスク容量が90%以上となった場合にアラームを飛ばす設定になります。
次へをクリックし、それ以降は「1.ログの通知」でご説明した通り、通知先のSNSとアラーム名を設定します。
まとめ
いかがでしたでしょうか。ここまででCloudWatch Agentを使ってログとディスク、メモリの監視、通知についてご説明しました。
特に、イベントログをわざわざOSにログインしなくともAWSコンソールから確認できることは運用観点から便利ですよね。また、メトリクス監視の通知は運用設計時必須だと思います。
本ブログでも少し触れていた、大規模環境での複数インスタンス導入時のCloudWatch対応方法については、次のブログでご説明しようと思います。
この記事が参考になれば幸いです。
*******************************************************************
本ブログに掲載されている内容は、執筆時点の情報および筆者の知見に基づいています。
内容の正確性や最新性については可能な限り配慮しておりますが、
その完全性や有用性を保証するものではありません。
本ブログに記載されている見解や意見は、筆者個人のものであり、
当社の公式な見解、方針、または保証を示すものではありません。
本ブログの情報を利用したことにより生じたいかなる損害についても、
当社および筆者は一切の責任を負いかねます。
製品の導入や設定、運用にあたっては、各ベンダーの公式ドキュメントや
契約内容をご確認のうえ、自己責任にてご判断ください。
*******************************************************************
