障害対応は「見える情報」で決まる
システムが遅い、エラーが増えた、特定ユーザーだけ失敗する。こうした問題を調べるとき、手元に情報がなければ推測で動くしかありません。
運用で重要なのは、障害が起きないことだけではありません。起きたときに、何が起きているかを短時間で把握できることです。
そのために使う代表的な情報が、ログ・メトリクス・トレースです。
| 種類 | 何を見るか | 例 |
|---|---|---|
| ログ | いつ何が起きたか | エラー内容、ユーザーID、処理結果 |
| メトリクス | 数値の変化 | CPU使用率、エラー率、レスポンス時間 |
| トレース | 処理の流れ | APIからDB、外部サービスまでの経路 |
ログは「あとで読む人」のために残す
ログは、単に console.log を置くものではありません。あとから調査する人が、状況を再現できる粒度で残します。
悪いログの例です。
error
failed
user not foundこれでは、いつ、どの処理で、誰に対して、何が失敗したのか分かりません。
読みやすいログでは、最低限次の情報を意識します。
{
"level": "error",
"event": "payment_failed",
"requestId": "req_abc123",
"userId": "user_123",
"orderId": "order_456",
"reason": "card_declined",
"timestamp": "2026-04-29T09:00:00Z"
}構造化されたログは、検索・集計・フィルタリングがしやすくなります。
ログレベルの使い分け
ログレベルは、重要度に応じて使い分けます。
| レベル | 使いどころ |
|---|---|
debug | 開発・詳細調査用。本番では出さないことも多い |
info | 正常な重要イベント。起動、処理完了など |
warn | すぐ障害ではないが注意が必要。リトライ成功など |
error | 処理失敗。ユーザー影響や調査が必要 |
fatal | プロセス継続が難しい重大障害 |
すべてを error にすると、重要な障害が埋もれます。逆に本当に調べるべき失敗を info にすると、アラートに引っかからない可能性があります。
初心者がまず残すべきログ
アプリケーションで最初に整えたいのは、次のログです。
- 起動・終了
- リクエスト開始・終了
- 認証・認可の失敗
- 外部API呼び出しの失敗
- DB更新の失敗
- 重要な業務イベントの成功・失敗
ただし、個人情報やトークンをそのまま出してはいけません。
出してよい例: userId, requestId, orderId
避ける例: パスワード、アクセストークン、クレジットカード番号、住所全文調査に必要な情報と、漏れてはいけない情報を分けることが重要です。
メトリクスで異常を早く見つける
ログは「何が起きたか」を見るのに向いています。一方で、全体の傾向を見るにはメトリクスが向いています。
代表的なメトリクスは次の通りです。
| 分類 | 例 |
|---|---|
| リクエスト | リクエスト数、エラー率、p95レスポンス時間 |
| リソース | CPU、メモリ、ディスク、ネットワーク |
| DB | クエリ時間、接続数、ロック待ち |
| キュー | 滞留件数、処理時間、失敗数 |
| 業務 | 注文数、決済失敗数、登録完了数 |
中級者は、システムメトリクスだけでなく業務メトリクスも見ます。CPUが正常でも、決済失敗率が急に上がっていればユーザー影響があるからです。
トレースで処理の流れを見る
マイクロサービスや外部API連携があるシステムでは、1つのリクエストが複数の処理をまたぎます。
ブラウザ
↓
API Gateway
↓
注文サービス
├─ DB
├─ 決済API
└─ メール送信トレースがあると、どの区間で時間がかかったか、どこでエラーが発生したかを追いやすくなります。
このとき重要なのが requestId や traceId です。ログにも同じIDを入れておくと、ログとトレースをつなげて調査できます。
中級者向け：アラート設計の考え方
アラートは多ければよいわけではありません。多すぎると誰も反応しなくなります。
良いアラートは、次の条件を満たします。
□ ユーザー影響または将来の障害につながる
□ 受け取った人が取るべき行動を判断できる
□ 一時的な揺らぎで頻繁に鳴りすぎない
□ ダッシュボードやログへの導線があるたとえばCPU使用率だけでアラートを出すより、エラー率やレスポンス時間と組み合わせた方が実際の影響を判断しやすくなります。
実務チェックリスト
□ 重要な処理にrequestIdまたはtraceIdが付いているか
□ エラーログに原因・対象・処理名が含まれているか
□ 個人情報や秘密情報をログに出していないか
□ ダッシュボードでエラー率とレスポンス時間を見られるか
□ アラートに対応手順または調査先リンクがあるか
□ 障害後に「足りなかったログ」を振り返って改善しているかまとめ
- ログは「いつ何が起きたか」を調べるための記録
- メトリクスはシステム全体の傾向や異常検知に向いている
- トレースは複数処理をまたぐリクエストの流れを追うために使う
requestIdやtraceIdをそろえると調査しやすくなる- ログには調査に必要な情報を残し、秘密情報は出さない
運用の基本コマンドはLinux 基礎コマンド、実行環境の再現性はDocker 基礎で学べます。