技術2課の松田です。こんにちは。
今回は統合CloudWatchエージェントを用いた、Windowsマシンのログ取得方法についてふわっとまとめます。
- 統合CloudWatchエージェントについて
- Windows OSで収集できるログ
- 統合CloudWatchエージェントの設定ファイル
- CloudWatch Logs ロググループの設計
- まとめ
- 参考記事
統合CloudWatchエージェントについて
統合CloudWatchエージェントを使用すると、クラウド/オンプレを問わずサーバー内部のメトリクスやログを収集し、Amazon CloudWatchに出力することが可能になります。OSログインせずともメトリクスやログを確認できるようになる便利なツールですので、しっかりした運用設計とセットで便利に使っていきたいですね。
なお今回はログの収集を主に記事を書いています。メトリクスの収集については当方の拙記事もご参考頂ければ幸いです。
ちなみに統合CloudWatchエージェントはオープンソース化されています。Githubはこちら。
Windows OSで収集できるログ
統合CloudWatchエージェントで取得できるログは、2つに分類できます。
1つはファイル出力されるログです。
OS上に.logとかの形式でファイル出力されるログです。正確には後述のイベントログもファイル出力されているので、「イベント ビューアーで見れないログ」と言った方が正確かもしれません。
もう1つはイベントログです。
こちらはWindows特有のもので、「イベント ビューアーで見れるログ」と理解するとよさそうです。Windows OSでは、OSのログと一部のアプリケーションやサービスのログがここから閲覧可能です。これらのログも統合CloudWatchエージェントでは収集することができます。
統合CloudWatchエージェントの設定ファイル
では、ログの収集方法についても簡単に書いていきます。
まず統合CloudWatchエージェントには.json形式の設定ファイルがあり、これを設定して「どのログを収集するか」「収集したログをどこに出力するか」などを決定します。
例えば以下のような感じです（ログに関する記述のみ抜粋）。
補足しておくと、"windows_events"セクションがイベントログ、"files"セクションがファイル出力されるログに関する記述ですね。
"logs": { "logs_collected": { "files": { "collect_list": [ { "file_path": "C:\\inetpub\\logs\\LogFiles\\W3SVC1\\u_*.log", "log_group_name": "IIS_Access_Log", "log_stream_name": "{instance_id}" } ] }, "windows_events": { "collect_list": [ { "event_format": "xml", "event_levels": [ "CRITICAL" ], "event_name": "System", "log_group_name": "System", "log_stream_name": "{instance_id}" } ] } } }
ちなみに"event_name"は収集するイベントログの名前を入れるのですが、これはイベントビューア―で、収集するイベントログを右クリック→「プロパティ」→「Full Name」を入れればよいです。
これが地味に分かりにくく、OS言語を英語にしていればまだマシなのですが、日本語にしちゃっていると2byte文字で表示されるログがあるのでなおのこと分かりにくい...。
設定ファイルのリファレンス的なものは記事末尾にリンクを貼っておきますので、詳細はそちらをご参照ください。
また統合CloudWatchエージェントのインストールやセットアップ手順も、記事末尾にリンクを貼っております。AWS Systems ManagerのRun Commandを使用することで、OSログインなしにセットアップも可能です。
CloudWatch Logs ロググループの設計
さて、統合CloudWatchエージェントで収集したログはCloudWatch Logs ロググループに出力されるのですが、運用上もっとも肝心なのはここの設計といっても過言ではないと思います。
というのも、深く考えずに統合CloudWatchエージェントを設定すると、以下の様なCloudWatch Logs ロググループが作成されます。
イベントログがロググループに、サーバーがログストリームにそれぞれ対応している形になります。↓のような感じですね。
イベントログ① ├─ サーバー① ├─ サーバー② └─ サーバー③ ... イベントログ② ├─ サーバー① ├─ サーバー② └─ サーバー③ ... イベントログ③ ├─ サーバー① ├─ サーバー② └─ サーバー③ ... ...
1種類のイベントログに複数のサーバーがぶら下がっている状態です。個人的には何となく使いにくいような気がするのですが（Auto Scalingを気にしてこんな構成にしてるのかな）、これが良いか悪いかは運用要件によるので、ちゃんと運用含めて設計しないとダメだなーと思いました（小並感）。
当たり前ではあるのですが、初学者向けチュートリアルなんかだと「とりあえずログ出力する」ことが優先されて、この辺りは端折られがちな気がします。実運用まで踏み込むと、正直めんどくさいですがこの辺りもちゃんと設計しないと、運用には堪えず金だけが掛かるログの山ができあがる未来が見えますね。。。
まとめ
色々書きましたが、本記事でお伝えしたかったことはCloudWatch Logs ロググループ、というかログの運用設計もちゃんとやりましょうということです。当たり前の話に落ち着いてしまいましたが、最後までお付き合いいただきありがとうございました。
参考記事
CloudWatch エージェントを使用して Amazon EC2 インスタンスとオンプレミスサーバーからメトリクスとログを収集する： https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html
CloudWatch エージェント設定ファイルを手動で作成または編集する： https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-Configuration-File-Details.html#CloudWatch-Agent-Configuration-File-Logssection
AWS Systems Manager を使用した CloudWatch エージェントのインストール： https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/installing-cloudwatch-agent-ssm.html
松田 渓(記事一覧)
2021年10月入社。散歩が得意です。
