優先順位:
  1. 構造化ログ（最低限これは必須）
  2. メトリクス（パフォーマンス監視に）
  3. 分散トレース（マイクロサービスで特に重要）

必須フィールド:
  - timestamp: ISO 8601 / UTC
  - level: ログレベル
  - message: 人間が読めるメッセージ
  - service: サービス名
  - request_id: リクエスト追跡用 ID

推奨フィールド:
  - user_id: 操作ユーザー（認証後）
  - method: HTTP メソッド
  - path: リクエストパス
  - status_code: レスポンスステータス
  - duration_ms: 処理時間
  - error: エラー情報（スタックトレース含む）

出力形式: JSON（機械解析可能）

DO:
  - ビジネスイベントをログに記録する
  - エラーにはコンテキスト情報を含める
  - リクエスト ID で関連ログを紐付ける
  - 本番では INFO 以上、開発では DEBUG 以上

DON'T:
  - パスワード、トークン、個人情報をログに出力しない
  - ループ内で大量のログを出力しない
  - ログレベルを不適切に使わない（正常処理を ERROR にしない）
  - スタックトレースを本番のレスポンスに含めない

設計:
  1. リクエスト受信時に一意の ID を生成（または受信）
  2. すべてのログにこの ID を付与
  3. 下流サービスへのリクエストにも ID を伝播
  4. レスポンスヘッダーにも ID を含める

ヘッダー規約:
  - X-Request-ID（一般的）
  - traceparent（W3C Trace Context 標準）

用途:
  - エラー調査時にリクエスト全体の流れを追跡
  - サポート問い合わせ時にユーザーから ID を取得

構成要素:
  - Trace: リクエスト全体の追跡単位
  - Span: 個別の操作単位（DB クエリ、外部 API 呼び出し等）
  - Context Propagation: サービス間でのトレース情報の伝播

計装対象（優先度順）:
  1. HTTP リクエスト/レスポンス
  2. データベースクエリ
  3. 外部 API 呼び出し
  4. キューのメッセージ処理
  5. 重要なビジネスロジック

ビジネスメトリクス:
  - アクティブユーザー数
  - 注文数 / 売上
  - 機能の利用率

技術メトリクス:
  - DB コネクションプール使用率
  - キャッシュヒット率
  - 外部 API レスポンス時間

GET /health  → 基本的な稼働確認（200 OK）
GET /ready   → 依存サービスを含めた準備完了確認

/health レスポンス:
  - status: "ok" | "degraded" | "unhealthy"
  - version: アプリバージョン
  - uptime: 稼働時間

/ready レスポンス:
  - 各依存サービスのステータス
  - DB 接続: ok/ng
  - キャッシュ: ok/ng
  - 外部 API: ok/ng

- /health は軽量に（依存チェックなし、即座に応答）
- /ready は起動完了の判断に使用
- 認証不要にする（ロードバランサーから呼ばれる）
- タイムアウトを設定する（ヘルスチェック自体がハングしない）

1. アクション可能なアラートのみ設定
   → 「見たけど何もしない」アラートは削除

2. 症状ベース > 原因ベース
   → ❌ "CPU 使用率が 80% 超過"
   → ✅ "レスポンス時間の p95 が 2秒 超過"

3. 適切な閾値設定
   → 過敏すぎない（アラート疲れの防止）
   → 遅すぎない（障害の早期検知）

4. 段階的なエスカレーション
   → Warning → Critical → Page

記録すべき情報:
  - エラーメッセージとスタックトレース
  - 発生環境（本番/ステージング）
  - リクエスト情報（URL, メソッド, ヘッダー）
  - ユーザー情報（匿名化）
  - 発生頻度と影響範囲

グルーピング:
  - 同一スタックトレースのエラーを集約
  - 新規 vs 既知のエラーを区別
  - リリースバージョンとの相関