ストーリー

モニタリングとは

モニタリングは、あらかじめ定義した項目を定期的にチェックし、閾値を超えたらアラートを発する仕組みです。

// モニタリング的アプローチ：既知のメトリクスを監視
interface MonitoringCheck {
  metric: string;
  threshold: number;
  comparison: 'gt' | 'lt' | 'eq';
  alertChannel: string;
}

const healthChecks: MonitoringCheck[] = [
  { metric: 'cpu_usage', threshold: 80, comparison: 'gt', alertChannel: 'slack' },
  { metric: 'memory_usage', threshold: 90, comparison: 'gt', alertChannel: 'pager' },
  { metric: 'disk_usage', threshold: 85, comparison: 'gt', alertChannel: 'slack' },
  { metric: 'response_time_p99', threshold: 3000, comparison: 'gt', alertChannel: 'pager' },
];

モニタリングの限界

• 既知の問題しか検知できない: 閾値を設定していないメトリクスの異常は検知できない
• 「なぜ」に答えられない: CPU使用率が高いことは分かるが、なぜ高いかは分からない
• 相関関係が見えない: 個別のメトリクスは見えるが、それらの関係性は不明

オブザーバビリティとは

オブザーバビリティは、「何が起きているか」だけでなく「なぜ起きているか」を探索的に調査できる能力です。

// オブザーバビリティ的アプローチ：任意の質問に答えられるデータを収集
interface ObservabilityData {
  // 構造化ログ：コンテキスト付きのイベント記録
  logs: {
    timestamp: string;
    level: string;
    message: string;
    traceId: string;
    spanId: string;
    userId?: string;
    orderId?: string;
    duration?: number;
    [key: string]: unknown; // 任意のコンテキスト情報
  };

  // メトリクス：集計可能な数値データ
  metrics: {
    name: string;
    value: number;
    labels: Record<string, string>; // 多次元のラベル
    timestamp: string;
  };

  // トレース：リクエストの経路追跡
  traces: {
    traceId: string;
    spans: {
      spanId: string;
      parentSpanId?: string;
      operationName: string;
      serviceName: string;
      duration: number;
      attributes: Record<string, unknown>;
    }[];
  };
}

比較表

┌─────────────────────────────────┐
│       オブザーバビリティ          │
│                                 │
│  ┌──────────────────────────┐   │
│  │     モニタリング           │   │
│  │  （閾値ベースのアラート）    │   │
│  └──────────────────────────┘   │
│                                 │
│  + 探索的分析                    │
│  + 相関分析                     │
│  + 根本原因分析                  │
│  + 予測的インサイト               │
└─────────────────────────────────┘

実践例：障害調査の違い

モニタリングだけの場合

1. アラート: "APIレスポンスタイム > 3秒"
2. ダッシュボード確認: CPU正常、メモリ正常、DB正常
3. 推測: 「ネットワークの問題？」「コードの問題？」
4. サーバーにSSHしてログをgrep
5. 1時間後: 外部サービスの遅延が原因と判明

オブザーバビリティが整備されている場合

1. アラート: "APIレスポンスタイム P99 SLO違反"
2. ダッシュボードで遅いエンドポイントを特定
3. トレースで遅延箇所を特定: Payment Service → 外部決済API
4. ログで詳細確認: 外部APIのタイムアウトが多発
5. 5分で原因特定、対策（タイムアウト短縮 + フォールバック）実施

オブザーバビリティの成熟度モデル

enum ObservabilityMaturity {
  Level0 = 'ログファイルをサーバーに保存しているだけ',
  Level1 = '集中ログ管理 + 基本的なメトリクス監視',
  Level2 = '構造化ログ + カスタムメトリクス + 基本アラート',
  Level3 = '分散トレーシング + 相関分析 + SLO監視',
  Level4 = '自動異常検知 + 予測分析 + セルフヒーリング',
}

まとめ

チェックリスト

• モニタリングとオブザーバビリティの違いを説明できる
• モニタリングだけでは不十分な理由を理解した
• オブザーバビリティの成熟度モデルを把握した
• 障害調査フローの違いを具体的にイメージできる

次のステップへ

次は「Three Pillars: ログ・メトリクス・トレース」を学びます。オブザーバビリティを支える3つの柱を深掘りしましょう。

推定読了時間: 25分