3つの要点
先に把握しておきたい論点だけを短くまとめています。忙しいときはここだけでも全体像をつかめます。
まず時刻とURLを見る
時刻はデプロイや設定変更、外部障害と照合でき、URLは公開ページか管理画面かbotかを見分ける手がかりになります。
例外名と短いメッセージを読む
スタックトレースを全部読む前に、権限・接続・未定義・外部通信失敗といった大まかな方向をつかみます。
影響範囲で優先度を分ける
トップページの障害と、存在しないURLへの古いbotを、同じ緊急度で扱わないようにします。
時刻はデプロイや設定変更、外部障害と照合でき、URLは公開ページか管理画面かbotかを見分ける手がかりになります。
まず時刻とURLを見る
ログの先頭で見るべきものは、発生時刻とURLです。時刻が分かれば、デプロイ、設定変更、アクセス増加、外部サービス障害などと照合できます。URLが分かれば、公開ページ、管理画面、存在しないページ、botアクセスのどれに近いか判断できます。
同じURLで繰り返し起きているなら、ページ固有の問題かもしれません。ばらばらのURLで同じ例外が出ているなら、共通処理や設定に原因がある可能性があります。
例外名と短いメッセージを読む
長いスタックトレースを全部読む前に、例外クラスと短いメッセージを見ます。ファイルがない、権限がない、DBに接続できない、変数が未定義、外部通信が失敗したなど、大まかな方向が分かります。
メッセージを検索する場合は、秘密情報を含めないよう注意します。ログには、パスワード、APIキー、Cookie、リクエスト本文の丸ごとが含まれない設計にしておくことも重要です。
たとえば「permission denied」ならファイルやディレクトリの権限、「could not connect」ならデータベースや外部サービスへの接続、「undefined」なら変数や設定の抜けを先に疑えます。メッセージそのものをそのまま検索するより、この大まかな見当をつけてから調べたほうが、無関係な情報に振り回されずに済みます。
今日からできること
- ログの先頭で発生時刻とURLを確認し、デプロイや設定変更と照合する
- 例外クラスと短いメッセージを読み、大まかな原因の方向をつかむ
- 影響範囲(公開ページ・フォーム・ログイン・bot)で優先度を決める
- 修正後、同じエラーが止まったか、別のエラーに変わったかを確認する
影響範囲を分ける
トップページが落ちているのか、一つの記事だけなのか、問い合わせだけなのか、botの存在しないURLだけなのかで優先度は変わります。すべてのエラーを同じ緊急度で扱うと、重要な障害に集中できません。
公開ページが読めない、フォームが送れない、ログインできない、決済できないといった問題は優先度が高くなります。一方で、存在しないURLへのアクセスや古いbotのリクエストは、必要なら404として扱えばよい場合もあります。
影響範囲で優先度を分ける
すべてのエラーを同じ緊急度で扱うと、本当に重要な障害に集中できません。
| 起きている場所 | 優先度 | 対応の方向 |
|---|---|---|
| トップや主要記事が読めない | 高 | すぐに原因を切り分ける |
| フォーム送信・ログイン・決済 | 高 | 利用者の行動を止めない |
| 存在しないURLへのbot | 低 | 必要なら404として扱う |
修正後に同じログが止まったかを見る
修正して終わりではなく、同じエラーが止まったか確認します。エラー通知が消えたのか、別のエラーに変わったのか、特定のURLだけ残っているのかを見ます。
ログは責めるためのものではありません。サイトがどこで困っているかを教えてくれる運用の記録です。読み方を決めておくと、問題が起きたときの判断が静かになります。