もう4年前の話ですが、CloudWatch Logsへのログ送信をWindowsで行う場合の記事を書きました。
CloudWatch Logs on Windows 2012 Server – 続 カッコの付け方
もうこの内容は古くなって久しいですが、なるべく昔ながらのやり方で ファイルを書いてサービス起動する単純さ を貫くやり方を書きます
歴史と概要
WindowsからのCloudWatch (Logs)へのデータ送信の方法は2回変わっています。(当たり前ですが、直接APIを叩けば送信できるのは変わりません。)
1.EC2Config単体時代
これは上記の記事と同じです。EC2Configサービスが、CloudWatch (Logs)への送信機能も持っていた
2.EC2Config + SSM Agentの時代
非常に便利なSSMですが、SSM の管轄として CloudWatch (Logs) の設定が組み込まれました。設定はSSMで行うものの、サービスの実体はどっちが受け持っていたかは、よく知りません。
3.CloudWatch Agentの時代
SSM依存も解消されて、完全に CloudWatch だけで完結するようになりました。どう考えても、これがあるべき姿です。
CloudWatch Agent単体での設定を説明します。
インストール
https://s3.amazonaws.com/amazoncloudwatch-agent/windows/amd64/latest/AmazonCloudWatchAgent.zipをダウンロード- unzip
- 管理者権限で
install.ps1を実行
これで C:\Program Files\Amazon\AmazonCloudWatchAgent\ にコピーされるので、これから先の作業はこっちで行う
設定ファイルの生成
ちょっとややこしいです。それっぽい名前の amazon-cloudwatch-agent-config-wizard.exe というのがあり、対話してファイル生成できますが、お世辞にもわかりやすいとは言えないので、とっととファイルフォーマットのリファレンス読んだ方がマシです、どうせあとから読むことになるんだし。
Manually Create or Edit the CloudWatch Agent Configuration File – Amazon CloudWatch
何らかの形で config.json というファイルを作ります。ここからがキーポイントで、ここで作る config.json というファイルは そのまま利用するのではなくコンバートして使います 。ですので、場所はどこにおいても問題ないのですが、 C:\Program Files\Amazon\AmazonCloudWatchAgent\config.json に置いた前提ですすめます。
新フォーマットからのコンバート処理
新フォーマットという言葉は今は無視して。先程かいたコンバートは、専用コマンドで行います。管理者権限を持つPowershellターミナルにて
cd "C:\Program Files\Amazon\AmazonCloudWatchAgent" .\amazon-cloudwatch-agent-ctl.ps1 -a fetch-config -c file:config.json
-c file:config.json でファイルから吸うという意味です。 file: で始めているのに file:// って書かないんだ。。これでだいぶハマったまじかよ。。
これで文法エラーとかあれば怒られますので、ちゃんとエコーを見てください。 なお、コンバート済みのファイルは C:\ProgramData\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent(json|toml) となります。
旧フォーマットからのコンバート処理
このコンバート処理は過信しないこと！
PS C:\Program Files\Amazon\AmazonCloudWatchAgent> .\amazon-cloudwatch-agent-config-wizard.exe -configFilePath .\AWS.EC2.Windows.CloudWatch.json -isNonInteractiveWindowsMigration
このコマンドで旧形式のjson(前述の 1,2 の時代の設定フォーマット) を新形式のconfig.jsonに変換します。ですので、実際にこれから稼働させるCloudWatch Agentに反映するには更に -a fetch-config にて (json|toml) への変換が必要です。
本コマンドは EC2config でやっていた人でも、SSMでやっていた人でも(この場合は上記とオプションは違う)どちらも通用するようです。が、100%完全コンバートではないので結局自分でちゃんと調べて1から書いたほうがマシです。WindowsのEventログからの取得が一部、エラーすら出ずにうまく変換されませんでした。
サービスの起動・停止・設定変更の手順
- 起動
.\amazon-cloudwatch-agent-ctl.ps1 -a start - 停止
.\amazon-cloudwatch-agent-ctl.ps1 -a stop - ステータス
.\amazon-cloudwatch-agent-ctl.ps1 -a status
設定変更する場合は
.\amazon-cloudwatch-agent-ctl.ps1 -a fetch-config -c file:config.json .\amazon-cloudwatch-agent-ctl.ps1 -a stop .\amazon-cloudwatch-agent-ctl.ps1 -a start
fetch-configは加工済みの設定ファイルを吐き出すだけなので、restartは自動で行われませんので、stop/startする必要あり。
まとめ
- CloudWatch Agent 単体で完結するようになった SSM Agentは別にいらない
- 設定ファイルは json と toml の2本で、ジェネレートするコマンドを使う
- サービスとしては
CloudWatch Agentという名前で動いている、ただし確認用PSを使うことが推奨されている
なんでSSM管轄だと嫌なの？
最後に批判です。批判の先に言いたいのは CloudWatch Agent の独立万歳!
- 本来、CloudWatchとSSMは依存関係に無いのに、どうしてわざわざSSMに依存しなければならない？
- ファイルに書いてサービスリスタートで反映完了と言う単純明快な方法をなぜわざわざSSM経由のみに絞る必要があるのか
- 同じファイルを複数台のEC2にばらまくときは確かに便利かもしれないが、サーバーごとに個別設定を入れ込みたい、{instance-id} のような変数だけでは実現できないとき、ファイル生成してリスタートのほうがはるかに簡単だし、同じ設定をばら撒くなら、定義をS3かどこかに置いて、それをCloudWatch Agentに (ファイル形式で) 反映させるSSMドキュメントを作ればいいだけの話
- AWSの開発者リソースの話だが(私の勝手なおせっかい)、CloudWatchAgentの機能を受け持つのは EC2Configを作っている人なの？ それともSSM Agentの開発者？ CloudWatchAgent は、 CloudWatchの開発チームが面倒見るべき話じゃないの？ これらが混ざっている意味も利点も利用者にはまったくない
