share facebook facebook twitter menu hatena pocket slack

2018.10.10 WED

SSM Agentとか無視して Windowsで CloudWatch Agentを使う

WRITTEN BY 今岡 久敏

もう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単体での設定を説明します。

インストール

  1. https://s3.amazonaws.com/amazoncloudwatch-agent/windows/amd64/latest/AmazonCloudWatchAgent.zip をダウンロード
  2. unzip
  3. 管理者権限で 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の開発チームが面倒見るべき話じゃないの? これらが混ざっている意味も利点も利用者にはまったくない

元記事はこちら

SSM Agentとか無視して Windowsで CloudWatch Agentを使う

今岡 久敏

「常に新しいモノの方が、古いモノより優れている、というマインドを持てなくなった時、それはエンジニアとしての死を意味する」え、誰の言葉だって?俺の言葉だよ。

cloudpack

cloudpackは、Amazon EC2やAmazon S3をはじめとするAWSの各種プロダクトを利用する際の、導入・設計から運用保守を含んだフルマネージドのサービスを提供し、バックアップや24時間365日の監視/障害対応、技術的な問い合わせに対するサポートなどを行っております。
AWS上のインフラ構築およびAWSを活用したシステム開発など、案件のご相談はcloudpack.jpよりご連絡ください。