SSM Agent のエラーログでクラッシュの原因をトラブルシューティングする方法を教えてください。

簡単な説明

Run Command、Association、Automation、または Systems Manager の機能である Sessions Manager の実行中、Systems Manager コマンドをターゲットインスタンスに実行できない場合があります。これらの障害が原因で、次の例に類似したエラーが発生します。

"document process failed unexpectedly: document worker timed out; check [ssm-document-worker]/[ssm-session-worker] log for crash reason."

このエラーは、次の原因で発生します。

• リソースが不十分
• メモリ不足 (OOM)
• ディスクの空き容量不足
• 開いたファイル数が過度に多い

詳細なトラブルシューティングについては、インスタンスの SSM Agent ログを確認します。

注: パフォーマンスとセキュリティを改善し、最新機能にアクセスするために、SSM Agent を最新バージョンに更新してください。さらに、GitHub のウェブサイトで amazon-ssm-agent/RELEASE NOTES にサブスクライブすると、SSM Agent の更新に関する通知を受信できます。

解決策

リソースが不十分

ターゲットインスタンスとのセッションでリソース不足が発生すると (例: メモリやディスク容量の使用率超過)、セッションがクラッシュしてシステム障害を引き起こす可能性があります。インスタンスには、ターゲットインスタンスで実行されるワークロードを管理するのに十分なリソースがあることを確認します。

OOM

OOM エラーは、実行中のプロセスが利用可能なメモリをすべて消費しているため、プログラムまたはオペレーティングシステム (OS) が領域を割り当てられない場合に発生します。この影響を受けたシステムは、追加のプログラムを読み込めず、関連するプロセスは正常に機能しなくなります。その後、OS は低優先度と判断したプロセスを無効化します。

エラーの原因がメモリ不足かどうかを確認する方法については、「到達できないインスタンスのトラブルシューティング」を参照してください。Linux でのメモリ不足については、「Out of memory: end process」を参照してください。

ディスクの空き容量不足

Linux システムでは、このエラーはデータの書き込みやファイルの保存を試行したものの、空き容量が不足している場合に発生します。このエラーを解決するには、次の手順を実行します。

• ディスクまたはパーティション上の大量のスペースを占有しているファイルを確認します。
• パーティションの空き容量を増やします。
• /var/lib/amazon/ssm の Systems Manager オーケストレーションフォルダを含め、作業ディレクトリの容量が十分かどうかを確認します。
• 容量を増やします。詳細については「ファイルシステムの容量枯渇を示すエラーが発生した場合に、EBS ボリュームのサイズを増やす方法を教えてください」を参照してください。

開いたファイル数が過度に多い

ドキュメントワーカーのクラッシュが原因で Linux インスタンスが Systems Manager Run Command の処理を停止した場合、too many open files エラーが発生する可能性があります。開いているファイル数が過度に多い場合、SSM Agent はコマンドプロセッサを開始できず、エージェントログにこのエラーを報告します。このエラーは、次のシナリオで発生します。

• SSM エージェントのプロセスが、root ユーザーが開けるファイル数の上限に達した。
• システム全体で開かれているファイルの総数が、システム全体で開けるファイル数の上限に達した。
• システムがカーネル内のサブシステムに対する通知制限に達した。

このエラーをトラブルシューティングするには、次の手順を実行します。

1.SSM エージェントプロセスの PID を特定します。

$ sudo ps -C amazon-ssm-agent -o pid=

2.PID の制限を特定します。最初の数字はソフトリミットで、2 番目の数字はハードリミットです。

$ sudo cat /proc/_**PID**_/limits |grep "Max open files"

3.Systems Manager プロセスで開いているファイルの総数を特定します。

$ sudo lsof -p _**PID**_ |wc -l

4.ステップ 2 と 3 の結果を比較します。開いているファイルの総数がハードリミットに近い場合、この事象が原因で新しいファイルを開けない可能性があります。この問題を解決するには、次のいずれかの手順を実行します。

• SSM Agent を再起動します。
• SSM Agent 起動ファイルのハードリミット値を増やします。、

注: 例に記載されたすべての値を実際の値に置き換えてください。

Upstart: Amazon Linux 1、Ubuntu 14.04、Ubuntu 16.04 (.deb パッケージ使用)

echo "limit nofile example-hard-limit" >> /etc/init/amazon-ssm-agent.override

Systemd: Amazon Linux 2、RHEL 7.x、RHEL 8.x

$ sudo systemctl edit amazon-ssm-agent  [Service]  LimitNOFILE=example-hard-limit

Systemd: Ubuntu 22.04 LTS、20.10 STR & 20.04、18.04 (snap 使用)

$ sudo systemctl edit snap.amazon-ssm-agent.amazon-ssm-agent  [Service]  LimitNOFILE=example-hard-limit

5.SSM Agent サービスを再起動します。

注: ハードリミットの更新時には、同時実行ユーザー数、ネットワーク接続、ファイル操作を含むアプリケーション要件を確認してください。デフォルトのハードリミットは、悪用やリソースの枯渇を防ぐ目的で低く設定されています。新しいハードリミットには、ストレステストを実施してください。ハードリミットを監視し、必要に応じて調整します。

ワーカーログを確認する

ワーカーログを確認するには、次の手順を実行します。

1.SSM Agent ログを確認します。SSM Agent は、次のファイルに情報を保持します。

注: 利用可能なログファイル、およびその目的を把握するために、使用する OS の公式資料を参照することをおすすめします。

• Linux - /var/log/amazon/ssm/amazon-ssm-agent.log
• Linux - /var/log/amazon/ssm/errors.log
• Windows - %PROGRAMDATA%\Amazon\SSM\Logs\amazon-ssm-agent.log
• Windows - %PROGRAMDATA%\Amazon\SSM\Logs\errors.log

2.OS レベルのログでソフトウェアまたはカーネルの問題がないか確認します。

• Windows - C:\Windows\System32\winevt\Logs
• Ubuntu/ Debian - /var/log/syslog
• Amazon Linux/ CentOS/ RHEL - /var/log/messages
• Suse - /var/log/messages

3.seelog.xml ファイルを更新し、SSM Agent のデバッグログを許可します。

注: SSM Agent のデバッグログは、大量のログデータを生成するため、システムストレージに影響する可能性があります。トラブルシューティングの完了後は、デバッグログを無効にすることをおすすめします。

関連情報

SSM Agent のトラブルシューティング