この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
園部です。
AWS Systems Manager（以降、SSM ）はみなさん使っていますか？
運用に関わる多くの機能がてんこ盛りなので、各機能の把握やベストな使い処に悩むといった声を耳にすることもあります。個人的には最新の Black Belt 資料が網羅されており、概要を把握するにはオススメです。 あとは 実現したいことドリブンで Automation や RunCommand で用意されているドキュメントを、こんなことできないかなぁ？といった視点で眺めてみるのも一手です。
さて今回は SSM を EC2 で利用する際に登場する SSM Agent に関する記事となります。 SSM 自体が先に書いたように多くの機能が統合されており、かつ個々にアップデートが頻繁にあります。（嬉しいことです）ただし、新しい機能やバグを解消するには Agent の更新が必須であることが多いです。これは SSM に限ったことではないですね。
そのため、ドキュメントでも以下のような案内がされています。
- 自動更新を推奨
- 更新をサブスクライブすることが可能
今回は、Agent 更新について取り上げていきます。
更新について
どのくらい更新されているの？
Agent の更新頻度や内容は、以下で知ることができます。
上記より抜粋（2020.06.29 時点）
実際、月に何回アップデートされているのか リリースノートの履歴から計算すると月に１〜２回の更新されています。これが多いかどうかは比較対象によって異なると思いますが、毎回手動でチェックおよび更新するのは苦しいと感じるのは私だけではないと思います。。
| 年月 | 回数 |
|---|---|
| 2019/12 | 2 |
| 2020/01 | 2 |
| 2020/02 | 1 |
| 2020/03 | 2 |
| 2020/04 | 1 |
| 2020/05 | 2 |
リリースの通知を受け取る
更新通知を受け取るには2つの方法があります。 比較的簡単に設定が行えますが Slack などへ通知する場合はどちらも一手間必要となるかと思います。
- SNS を利用した通知（ SSM エージェント 通知へのサブスクライブ ）
- Github を Watch 等での通知
Github amazon-ssm-agent RELEASENOTES.md
自動更新する
こちらは SSM の設定で行うことが可能です。シンプルな手順で設定が可能です！ 具体的な手順は以下のドキュメントか記事をご参照ください。
デフォルトは 14日周期での実行ですが変更することや手動で即時実行することも可能です。
可能なものはどんどん自動でいきましょう！！
自動更新で気になるところ
自動更新で気になるのは、やはりエラー（失敗）関連ではないかと思います。もし更新処理自体が失敗したら、更新されたがプロセスが起動しなかったら？ といった点について紹介していきます。今回は、トラブシューティングではなくエラーを検知する部分に重きをおいていきます。
更新処理が失敗したら？
RunCommand の実行結果を確認する方法としては以下の方法が考えられます。
- マネジメントコンソール
- 実行結果を出力されたログ（S3 および CloudWatch）
- CloudWatch メトリクス
- CloudWatch Events（EventBridge）
マネジメントコンソール
マネジメントコンソールを確認するのがもっとも正確ではありますが、自動更新の良さが半減してしまいます。 最終手段としたいですね。
実行結果を出力されたログ（S3 および CloudWatch）
出力された実行結果に対して、ログ監視を行う方法が考えられます。ですが、自動更新として提供されている State Manager では CloudWatch Logs には出力されず S3 のみへの出力となります。S3 内のデータをなんらかの形で監視し、特定のキーワードで通知するといったことは、この場合現実的ではないでしょう。
CloudWatch メトリクス
RunCommand は以下をメトリクスとして CloudWatch でモニタリング可能ですが、特定の実行ではなく全体として数が表示されます。
- CommandsDeliveryTimedOut
- CommandsFailed
- CommandsSucceeded
CLoudWatch Events（EventBridge）
RunCommand や State Manager の状態変更（Failed）をトリガーに通知が可能です。単一対象に対する実行や全て失敗といったケースでは有効です。 ただし RunCommand でエラーとする閾値を指定出来るのですが、こちらが空欄となっているため、複数台対象のうち何台が失敗するといったケースでは、どの程度でエラーと判断されるかは不明確です。
ここで取れる代案としては、利用しているドキュメント（ AWS-UpdateSSMAgent ）をベースに新しくメンテナンスウィンドウによる RunCommand 実行を作成し CloudWatch Logs に結果を出力しログを監視することで失敗を検知することが可能ではあります。（以下は成功時のメッセージです）
ただ、ここまで実施することが要件として必要かは運用しているサービスに左右されます。 Agent 自動更新に必要以上に手間をかけるのも自動化し運用負荷を軽減する目的からすると本末転倒となってしまうため、トレードオフが必要です。
プロセスが起動しなかったら？
Agent 更新完了したが何らかの理由に SSM Agent（amazon-ssm-agent） が起動しないケースも想定されます。
ここは何らかの監視サービス・ツールを利用して、プロセス監視するのがベタではありますが的確です。
他の方法としてはマネジメントコンソールの表示情報を確認するものもあります。
マネージドインスタンス >>> Ping の状態
こちらは SSM と SSM Agent との通信状態をなります。下の例では EC2 インスタンスは正常に稼働しているが SSM Agent プロセスを停止した場合の表示となります。ここを確認することで、目視ではありますが確認することも可能です。
SSM Agent が正常に起動していないインスタンスが把握出来たら、インスタンス内にログファイル生成されるログファイルを確認します。
# Windows の場合
%PROGRAMDATA%\Amazon\SSM\Logs\amazon-ssm-agent.log
%PROGRAMDATA%\Amazon\SSM\Logs\errors.log
# Linux の場合
/var/log/amazon/ssm/amazon-ssm-agent.log
/var/log/amazon/ssm/errors.logさいごに
後半は不安を煽るような内容となってしまいましたが、新機能利用のためという理由はもちろんのこと、弊社サポートデスクにお問い合わせをいただく中でも古い Agent に起因するケースもあり Agent は定期的に更新することが重要で、それであれば出来るだけ自動で行うことをお勧めします。
更新は計画的にいきましょう！
2
