はじめに
こんにちは。akibaです。
インスタンスで障害が発生した際、まずは状況を把握するためにログやプロセスを確認するといった対応を行う場面は多いかと思います。
こうした初動調査では、インスタンス内部の状態を把握し、次に取るべき対応を判断するための情報を集めることが重要になります。
一方で、環境によってはSSH接続が制限されている場合や、接続手段の準備に時間がかかるケースもあり、初動対応のハードルとなることがあります。
AWS Systems Manager Fleet Managerを利用することで、こうした環境においても、コンソール上からインスタンス内部の状態を確認することが可能です。
本記事では、AWS Systems Manager Fleet Manager（以下、Fleet Manager）を用いることで、
障害発生時の初動調査において確認できる情報をご紹介します。
目次
Fleet Managerとは
Fleet Managerは、AWS Systems Managerの機能の一つで、 Systems Managerで管理されているノード（EC2インスタンスやオンプレミスサーバー）をコンソール上から確認・管理するための機能です。
対象ノードに対しては、インスタンス情報や接続状況といった基本情報に加え、 プロセスやファイルシステム、ユーザー情報など、OS内部の情報を画面上から参照することができます。
また、複数のノードを一覧で確認できるため、対象インスタンスの状態をコンソール上で把握しやすい点も特徴です。
初動調査の場面では、このうちプロセスの稼働状況やログファイルの確認に加え、設定ファイルやパフォーマンス情報の確認も有効です。
これらの情報を組み合わせることで、サービスの状態や設定内容に加えて、必要に応じて負荷状況などもコンソール上から把握することができます。
そのため、以降の章ではこれらの観点から、各情報の確認方法を見ていきます。
前提（検証構成）
今回の内容は、AWS Systems Managerを利用してインスタンスの状態を確認できる環境が構成されていることを前提とします。
検証構成は以下の通りです。
- EC2：1台（SSMマネージドインスタンス）
- Fleet Manager：対象インスタンスの状態確認に使用
- Webサーバ（httpd）：状態確認用
また、対象インスタンスには以下の設定が行われているものとします。
- SSM Agentが導入、稼働していること
- IAMロール（AmazonSSMManagedInstanceCore）が付与されていること
動作確認
以下の流れで動作確認を進めていきます。
状態の確認はFleet Manager、サービスの操作はCLIで実施します。
- プロセスの確認
- ログファイルの確認
- 設定ファイルの確認
- 【参考】パフォーマンス情報の確認
1.プロセスの確認
まず、Processes画面からプロセスの状態を確認します。
httpdが起動している状態では、Processes画面にhttpdのプロセスが表示されていることが確認できます。
次に、webサーバを停止します。
$ sudo systemctl stop httpd
停止後に再度Processes画面を確認すると、httpdのプロセスが表示されていないことが分かります。
このことから、サービスの稼働状況をコンソール上から確認できることが分かります。
2.ログファイルの確認
次に、File systemからログファイルを確認します。
初動調査では、サービスの異常に関する情報が出力されるエラーログの確認が重要になります。
ここでは動作確認として、webサーバ上のリソースにアクセスできない状態を作成し、 Fleet Managerからエラーログを確認します。
対象のリソースに対してアクセス権限を変更し、 クライアントから正常にアクセスできない状態とします。
sudo mkdir -p /var/www/html/error-test echo "test" | sudo tee /var/www/html/error-test/index.html >/dev/null sudo chmod 000 /var/www/html/error-test
その状態で対象のリソースへアクセスすることで、 意図的にエラーを発生させます。
curl -i http://localhost/error-test/index.html
error_logを確認すると、エラーが出力されていることをコンソール上で確認できます。
3. 設定ファイルの確認
最後に、設定ファイルの内容を確認します。
ログの内容から設定に起因する問題が疑われる場合、 設定ファイルの内容を確認することで原因の切り分けを行うことができます。
webサーバの設定ファイルの内容を確認することで原因の切り分けを行うことができます。
また、設定値の誤りや想定外の変更がないかを確認できるため サービスの挙動不備や設定起因の問題の切り分けに利用できることが確認できます。
※File systemはSSM Agent経由で参照するため、OS上の権限（特にsymlink先）の影響で閲覧できない場合があることに注意してください。
4. 【参考】パフォーマンス情報の確認
ここまでの確認に加えて、Fleet Managerではパフォーマンス情報を確認することもできます。
Performance countersでは、CPU使用率、メモリ使用量、ディスクI/O、ネットワークトラフィックなどの情報が表示されていることが確認できます。
今回のようなアクセス権限に起因するエラーやサービス停止のような事象では、 パフォーマンス情報だけで原因を特定することは難しいですが、 初動調査では、負荷上昇や通信量の変化が発生していないかを確認する判断材料として利用できます。
簡単ではありますが、以上がFleet Managerを使用した初動対応の流れとなります。
まとめ
本記事では、Fleet Managerを利用した初動調査の流れを確認しました。
プロセスの確認から始まり、ログ、設定ファイルといった順に確認していくことで、
サービスの稼働状況やエラーの有無、設定内容といった観点から状況を整理できることが分かります。
今回は一例としてwebサーバを対象に確認を行いましたが、
同様の流れでほかのミドルウェアやアプリケーションに対しても応用できます。
このように、初動調査として必要な情報を段階的に確認していくことで、
インスタンス内部の状態をコンソール上から把握し、次に取るべき対応の判断につなげることができます。
また、必要に応じてパフォーマンス情報も確認することで、
負荷状況や通信量の変化といった観点からも状況を把握できます。
SSH接続を行わずに状態確認が可能であるため、環境による制約を受けにくく、初動対応の迅速化にも有効です。
さらに、複数のインスタンスを横断して同様の確認ができるため、
運用における調査手順の統一や効率化にもつながると考えられます。
初動調査の手段の一つとして、ぜひ活用を検討してみてください。
