アプリが停止しました。最初の有用な手がかりを見つけましょう。

観測可能な1つの障害を定義する

「停止」とは、HTTPエラー、タイムアウト、完了しなかったジョブ、終了したプロセスを意味する場合があります。1つのURLまたはアクション、最後に動作していた時刻、最初の失敗時刻、タイムゾーンを書き留めてください。全員が影響を受けているか、1つのクライアントだけかを含めてください。調査中は現在のSSHセッションを開いたままにしてください。アプリケーションエラーへの必要な初期対応としてアクセスルールを変更する必要はありません。

このガイドは、systemdを使用するLinuxホスト、次の名前のアプリケーションサービスを想定しています: first-api.service, そして次のローカルヘルスエンドポイント: 127.0.0.1:3000/healthz。これらのデフォルトは最初のAPIデプロイガイドと一致します。実際の名前で置き換えてください。他のユーザーのプロセスやログを表示するには管理者権限が必要な場合があります。以下のコマンドと出力は例示です。このガイドのためにプロバイダインスタンスはテストされていません。

メモは障害が発生しているアプリ自身のディレクトリの外に保管してください。解釈の前に観察を記録してください。「09:18 UTCに接続が拒否された」は事実です。「VPSにはもっとCPUが必要だ」はまだ仮説です。サーバー自体に到達できない場合は、確立された復旧アクセスを使用し、アプリの再起動が可能だと仮定するのではなく、接続の詳細を収集してください。

プロセス状態とその最近の履歴を読む

systemctl status first-api.service --no-pager --full
systemctl show first-api.service -p ActiveState -p SubState -p Result -p ExecMainStatus -p NRestarts

status view は現在または直近の呼び出しを記述し、最近の journal メッセージを含みます。選択したプロパティは、後で比較するための簡潔な記録を提供します。失敗状態や再起動回数の増加は調査に値します。アクティブなプロセスであっても、リクエストテストは必要です。これらは異なるチェックであり、次に説明されています: upstream systemctl リファレンス.

ユニットが存在しない場合は、まずその名前とデプロイ方法を確認してください。対話型ターミナルで起動したアプリ、コンテナ、systemd サービスでは、所有者もログも異なります。すぐに新しいサービスを作成すると、同じポートを奪い合う2つのコピーが残る可能性があります。変更する前に、既存の構成を特定してください。

リスナーを確認し、ローカルリクエストを送る

sudo ss -ltnp
curl --silent --show-error --max-time 5 http://127.0.0.1:3000/healthz

期待されるアドレスとポートを探し、所有プロセスを特定します。別のポートでリッスンしているプロセスは正常でも、設定されたプロキシから到達できない場合があります。別のプロセスが期待されるポートを占有している可能性があります。 ss マニュアル はリスナーとプロセスのオプションを定義します。

ローカルリクエストが成功し、公開 HTTPS リクエストが失敗する場合は、次へ進んでください: DNS、TLS、プロキシのチェック。リスナーが存在しない場合は、起動失敗を調べます。接続は成功するがアプリがエラーを返す場合は、そのルートと依存関係を調査します。Curl は --fail HTTP エラー応答でも正常に完了するため、終了コードだけに頼らず応答を読んでください。参照: curl の応答と失敗オプション.

最後の行だけでなく、最初の失敗の周辺を読む

sudo journalctl -u first-api.service --since "30 minutes ago" --no-pager -n 100
sudo journalctl -k --since "30 minutes ago" --no-pager -n 100

最初のクエリはサービスを選択し、2番目はカーネルメッセージを選択します。最後に成功したリクエストと障害の前に発生した変更を含むように間隔を調整してください。アクセスと保持期間が、利用可能な情報を決定します。 upstream journalctl リファレンス ユニット、時間、カーネルのフィルターについて説明しています。抜粋を共有する前に、トークン、顧客データ、接続文字列をマスクしてください。

アップロード機能を持つ別のアプリからの例示的な抜粋:

09:18:03 field-api: opening upload directory
09:18:03 field-api: EACCES: permission denied, open '/var/lib/field-api/uploads/index.json'
09:18:03 field-api: startup aborted

これは、サービスユーザーが特定のパスにアクセスできることを示唆しています。リリース手順に照らして、ファイルと親ディレクトリの所有権を確認してください。ファイルシステム全体に広範な書き込みアクセスを付与しないでください。このシナリオでは、後続のプロキシの「upstream unavailable」メッセージは結果であるため、最初にプロキシを修復すると原因を見逃します。

リソースを最新リリースと比較する

free -h
df -h / /opt/first-api
df -i / /opt/first-api

これらのスナップショットは、メモリの負荷、ファイルシステムの空き容量、inode の枯渇が障害と同時に発生したかどうかを判断するのに役立ちます。その解釈は次に属します: メモリとディスクのガイド。単一のビジーな読み取りだけでは原因を特定できません。サービスは、ホスト全体に余裕があっても、自身のリソース制限に達することがあります。

デプロイされたリリース識別子、起動コマンド、必要な環境変数名、データパスを、最後に動作したリリースと比較してください。秘密の環境値をレポートにダンプしないでください。ディレクトリ名の変更、実行時依存関係の欠落、ポート変更、互換性のないデータベースマイグレーションを探してください。何が変更されたか、エラーから何が見つかると予測されるかを述べてください。

正当な修正を1つ行い、復旧を確認する

証拠に基づいて支持される最小の修正を選んでください。例示的な権限失敗の場合、それはサービスアカウントの意図されたアクセスを復元し、その後1回の制御された起動を試みることを意味します。代わりに既知の動作するコードリリースを使用する場合は、まずそのデータベーススキーマが互換性を保っているか確認してください。コードのロールバックはデータマイグレーションを自動的に逆転できません。

修正後、同じサービス、ローカルエンドポイント、公開リクエストのチェックを繰り返してください。代表的なアプリケーションアクションが機能すること、新しいエラーが停止したこと、次の通常のワークロードを通じてプロセスが安定していることを確認してください。再起動ポリシーはプロセスの回復に役立ちますが、持続的に壊れたプログラムを健康にするものではありません。次を参照してください: systemd サービスリファレンス 実際のポリシーについて。

インシデントノートを、症状、最初の有用な手がかり、行った変更、検証結果で締めくくってください。原因が不明な場合は、一時的な再起動を恒久的な修正とラベル付けするのではなく、マスクされた証拠とともにその不確実性を報告してください。改善してください: リリースチェックリスト この障害をより早く捕捉できたはずのチェックを加えて。