テックブログ

2024.3.25

AWS Systems Manager State Manager を利用してサーバの状態を監視する

こんにちは AM です。
今回は State Manager を利用してサーバの状態をチェックし、結果が失敗であれば通知するということを行いたいと思います。

事前に検討、準備するもの

Systems Manager が利用できるサーバ
実際に設定、管理しておきたい項目

Systems Manager の利用方法については今回は割愛します。
監査項目としては、 Apache が自動起動でなければ失敗とし、通知する
ということを実現したいと思います。

監査したい項目をどのようにチェックするか

元々多数のルールが用意されていますが、
AWS-RunShellScript を利用してサーバでコマンドを実行し、その終了コードで失敗になるかを調べていきます。
ひとまずサーバ上で確認


$ sudo systemctl is-enabled httpd
disabled
$ sudo echo $?
1

$ sudo systemctl enable httpd
Created symlink /etc/systemd/system/multi-user.target.wants/httpd.service → /usr/lib/systemd/system/httpd.service.
$ sudo systemctl is-enabled httpd
enabled
$ sudo echo $?
0

問題なく取得できそうです。

StateManager の設定

SystemsManager の画面に移動し、ステートマネージャー、画面右上あたりの関連付けの作成をクリックします。

名前はわかりやすいものをつけておいたほうがよいかと思います。

🔍のテキストフィールドに AWS-RunShell 等を入力し、実際に利用するドキュメントを選択します。

必要に応じて適宜必要なコマンドや作業ディレクトリを入力します。

対象のインスタンスを選択、もしくは多数のサーバで同時に確認したい場合はタグの設定など各自の環境にあわせて設定してください。

実行間隔です。 CRON 式でも設定可能ですが、最短が 30分間隔です。

以下のオプションは必要に応じて利用してください。利用しなくても今回は問題ありません。

最後に関連付けの作成ボタンをクリックして完成です。

動作テスト

events 設定の前に実際に成功失敗のステータスになるのか確認します。
実際に時間経過を待ってもらっても問題ありませんが、手動で実行も可能です。
対象の関連付けにチェックを入れ、関連付けを今すぐ適用をクリックします。

また関連IDをクリックし、詳細画面に移動してから実行履歴タブをクリックすることで履歴及び、実行結果を確認することができます。

さらに実行IDをクリックすることで実際の標準出力結果を確認することができます。
成功パターン

失敗パターン

処理に問題はなさそうです。
EventBridge の作成に移ります。

EventBridge

EventBridge の管理画面左ペインからバス > ルールで表示される画面からルールを作成をクリックします。

名前、説明は任意で入力、イベントバスはデフォルト、ルールタイプはイベントパターンを持つルールにします。

イベントソースは AWSイベントまたは EventBridge パートナーイベントにいます。
サンプルイベントは特になにも選択しなくても問題ありません。

イベントパターン構築ページの下部で実際に検出パターンを入力します

ここは各自必要なアラームにあわせて設定してください。今回は
指定関連付けのステータスが Failed になった場合としました。

{"detail-type": ["EC2 State Manager Instance Association State Change"],"source": ["aws.ssm"],"detail": {"association-id": ["abcdfgh-ab12-abcd-efgf-a1b2c3d4e5f6g"],"status": ["Failed"]}}

ターゲットについても各自で必要なものを選択してください。

あとはタグと確認なので割愛します。
実際に Failed にして SNS通知を確認します。
実際に届いたメール

{"version":"0","id":"abcdefgh-1234-5678-98ab-12344556hijk","detail-type":"EC2 State Manager Instance Association State Change","source":"aws.ssm","account":"123456789012","time":"2024-03-13T01:01:11Z","region":"ap-northeast-1","resources":["arn:aws:ec2:ap-northeast-1:123456789012:instance/i-1234abcd","arn:aws:ssm:ap-northeast-1::document/AWS-RunShellScript"],"detail":{"association-id":"abcdfgh-ab12-abcd-efgf-a1b2c3d4e5f6g","association-name":"httpd_enabled_check","document-name":"AWS-RunShellScript","instance-id":"i-1234abcd","association-version":"8","document-version":"1","targets":"[{\"key\":\"InstanceIds\",\"values\":[\"i-1234abcd\"]}]","creation-date":"2024-03-13T01:01:10.793502Z","last-execution-date":"2024-03-13T01:01:11.560Z","status":"Failed","detailed-status":"Failed","execution-id":"12345678-1234-1234-abcd-abcdefghijk1","instance-association-cwe-version":"1.1"}}

失敗になったことを確認できました。
うまく使えば設定の漏れや設定の統一などを監視できます。
自動化が流行ってるとはいえ、なんらかの事情で手作業が発生したときに
誤った操作でズレが発生していないかといったことや、条件をかえて設定が古いままになっているサーバを割り出しなどに利用できるかなと考えています。

ここまで読んでいただきありがとうございました。