アプリケーションイベントとコンテナの問題をトラブルシューティングします。
対応する時刻の アプリケーションイベント を表示します。
liveness チェックの失敗を確認します。インスタンスが liveness チェックに 3 回失敗すると、再起動されます。liveness チェックに失敗した場合は、次の手順に従って調査します。
モニタリングデータを確認して、CPU 使用率と負荷が過度に高くないかどうかを判断します。
関連する時刻のビジネス例外のログを調べます。
Container Exit Codeでプロセスが終了したかどうかを確認します。たとえば、終了コード 137 は、プロセスがkill -9で終了したことを示唆しており、多くの場合 Linux システムの OOM Killer メカニズムが原因です。
SAE 全体イベント を確認します。
OOM Killer イベントまたはその他の異常イベントが発生したかどうかを調査します。OOM Killer メカニズムがアクティブ化された場合は、SAE インスタンスタイプを調整してメモリ容量を増やすことを検討してください。
Java アプリケーションの場合は、ヒープメモリの最適化について、「JVM メモリ構成のベストプラクティス」をご参照ください。
イベントをサブスクライブして、コンテナの変更をリアルタイムで監視します。
アプリケーションログを調べます。
ログを SLS に転送して永続ストレージに保存すると、履歴の問題の追跡に役立ちます。コンテナの再起動時間を確認し、Java OOM などの異常なアプリケーションログを確認します。インスタンスのプライマリプロセスが終了すると、コンテナは自動的に再起動します。