AWSで過去普通にやってた監視実装も、2,3年経つと（或いはそれより短い周期で）陳腐化する。以前は限られたサービスのリソース範囲でやれることをやっていればよかったが、今はSSM(Systems Manager)、Lambda、EventBridgeなどの「登場人物」が増えて、カスタマイズが可能になったからだ。やれることが増えた分、実装が複雑になる。その分チャレンジングな分野になって楽しめると言えないこともないが…、時間が足りないんだ。頭痛ぇな、まったく。絡み合った糸をほぐすためにまとめてみる。
監視の種別としては大枠としてノード監視、閾値監視、ログ監視、プロセス監視、イベント監視と想定する。それぞれの実装方式が若干異なってくるため整理したい。
監視方式大枠
- ノード監視
CloudWatchアラーム(ステータスチェック) ー＞ (EventBridgeルール) ー＞ Lambda ー＞ SNSトピック ー＞ メール送信
※ハード障害等でインスタンスが落ちた時に発動される想定。手動で落とした時は発動しないので通知は来ない。
- 閾値監視
CloudWatchアラーム（閾値チェック） ー＞ (EventBridgeルール) ー＞ Lambda ー＞ SNSトピック ー＞ メール送信
※EC2インスタンスのCPU使用率、ディスク使用率を想定。メモリ監視は別途カスタムメトリクスの実装がいる。
- ログ監視
CloudWatchLogsでログ出力（サブスクリプションフィルタキーワード検知）ー＞ Lambda ー＞ SNSトピック ー＞ メール送信
※これだけEventBridgeを使用しない。
- プロセス監視
EC2インスタンス上のプロセス数監視に相当する。検索すると「プロセス落ちていたらインスタンス再起動」アクションの事例が多いが、今回やりたいのはメール通知だけ。一応メモっておくけど。
CWエージェント + SSM + インスタンス停止、Lamabdaなし
EC2上のプロセスを監視し自動復旧する
CWエージェント + SSM + 自動再起動、Lamabdaなし
AWSでプロセス監視を実装したい
CWエージェント + Lamabda + SSM + 自動再起動
EC2のプロセス監視と自動再起動
procstat事例
以下はSSMを使用せず、procstatプラグインを使用してプロセス監視する例。記事には監視設定以降の通知イベント事例はなし。
CloudWatch Agent でProcstatプラグインの利用が可能になりました
SSMを使わずCloudwatchでEC2上のプロセス監視をしてみる
以下は途中まで参照したところ（後半は有料サービスの案内）、アラームを作成するところまでわかりやすかった。であれば、閾値監視と同様にEBルールを挟んでLambdaをターゲットに指定 ー＞ SNSトピックに渡されてメール送信、でいけるはず。
CloudWatchでプロセス監視する手順をLinuxとWindowsともに詳しく紹介
- イベント監視
イベント発生 ー＞ (EventBridgeルール) ー＞ Lambda ー＞ SNSトピック ー＞ メール送信
※1. 2. のアラームがイベントに置き換わるだけで、後続のフローは同様となる想定。
上記の中で、私的には4.のプロセス監視が一番面倒な気がする。プロセス監視の詳細は保留として、全体の登場人物を整理しておこう。
登場人物整理
整理したらこうなった。方式をどうするかによって変わる部分もあるが、今のところこの想定。すべての監視でLambdaを使うのは、メール件名や本文をカスタマイズしたいため。
| ノード監視 | 閾値監視 | ログ監視 | プロセス監視 | イベント監視 | |
|---|---|---|---|---|---|
| CloudWatchAlarm | ● | ● | - | ● | - |
| CloudWatchLogs | - | - | ● | - | - |
| SSM(Systems Manager) | - | - | - | ● | - |
| EventBridge rule | ● | ● | - | ● | ● |
| Lambda | ● | ● | ● | ● | ● |
| SNS topic | ● | ● | ● | ● | ● |
次のステップとして、これらの各アイテムにおいて「共通化できるもの / 個別に作成するもの」に分類する必要がある。
その他メモ
- メール件名のカスタマイズ
メール件名のカスタマイズをLambdaの環境変数でやるかコード本体でやるか。
イベントの中身を拾って詳細に設定するならLambdaコード内でやるしかないが、そんな体力はない。そもそもイベントの中身が元ネタによって異なるからメッセージ内容別に大幅な差分が発生するはず。やれなくもないがそんな体力は(ry)。となると、カッコ悪いかもしれないがほぼ決め打ちの値で環境変数にセット、でいく方がいい。
- メッセージ本文のカスタマイズ
① Lambdaコード内で実装
② EventBridgeルールの入力トランスフォーマーで実装
②を試したが期待値ならず。深追いしている時間はない。どっちにしろログ監視では本文をLambdaに渡しているからそっちに寄せる方がいい。ここでやってるマッピングがLambdaコードにも適用できるか検討しようと思ったが、スキーマレジストリとかよくわからん。
- aws configの通知をどうするか
configのログはS3にしか飛ばせない。ログ監視ではなく、イベント監視でやる。検知を制御したい時はイベント検知無効化で対応とか。
Amazon CloudWatch Events を使用すると、AWS Config イベントのステータスで変更を検出し対応することができます。
Configの変更はCloudTrailにつながるから、下手すると監視が重複するかもしれない。が、考えてる時間が(ry) 以下はCloudTrailの設定で直接SNSを指定しているっぽいが、これもEventBridgeに渡す、に統一させた方がよさげ。
CloudTrail が、新しいログファイルを Amazon S3 バケットに発行するときに通知を受け取ることができます。
以下は通知事例の記載はないが一応メモ
AWSリソースの設定変更履歴を管理する「AWS Config」とは？実際に使用してみた
果てしない旅路。
（追記）
SSM(Systems Manager)は使わずにprocstatプラグインだけでもなんとかなりそう。SSMを使えばもっと楽になるらしいが、よくわかっていない。ちゃんと調べればいいんだが、時間がないんだ…