LESSON 25分

ストーリー

高
高橋アーキテクト
オブザーバビリティの世界には”3本柱”がある

高橋アーキテクトがホワイトボードに三角形を描いた。

高
高橋アーキテクト
ログ、メトリクス、トレース。この3つを組み合わせることで、システムの内部状態を立体的に把握できるようになる。1つだけでは平面的で、死角が生まれてしまう

3本柱の全体像

           ┌─────────────┐
           │   Traces     │
           │ (経路追跡)    │
           └──────┬───────┘
                  │
    ┌─────────────┼─────────────┐
    │             │             │
    ▼             ▼             ▼
┌────────┐  ┌────────┐  ┌────────┐
│  Logs  │  │Metrics │  │Traces  │
│ 何が   │  │ どれだけ │  │ どこで  │
│ 起きたか │  │ の量か  │  │ 起きたか │
└────────┘  └────────┘  └────────┘

第1の柱：ログ（Logs）

ログは、システム内で発生した個別のイベントを記録したものです。

// 構造化ログの例
interface LogEntry {
  timestamp: string;
  level: 'DEBUG' | 'INFO' | 'WARN' | 'ERROR';
  message: string;
  service: string;
  traceId?: string;
  spanId?: string;
  context: Record<string, unknown>;
}

// 実際のログ出力例
const logEntry: LogEntry = {
  timestamp: '2025-01-15T10:30:45.123Z',
  level: 'ERROR',
  message: 'Payment processing failed',
  service: 'payment-service',
  traceId: 'abc123def456',
  spanId: 'span789',
  context: {
    orderId: 'ORD-001',
    userId: 'USR-042',
    amount: 5000,
    errorCode: 'TIMEOUT',
    retryCount: 3,
  },
};
特徴説明
粒度個別イベント単位（最も詳細）
用途デバッグ、監査、障害調査
データ量大きい（保存コストが高い）
強み「何が起きたか」の詳細がわかる
弱み大量データの中から問題を探すのが大変

第2の柱：メトリクス（Metrics）

メトリクスは、時間とともに変化する数値データを集計したものです。

// メトリクスの種類
interface Counter {
  name: string;
  value: number;       // 単調増加する値
  labels: Record<string, string>;
}
// 例: http_requests_total{method="GET", status="200"} = 15234

interface Gauge {
  name: string;
  value: number;       // 増減する値
  labels: Record<string, string>;
}
// 例: active_connections{service="api"} = 42

interface Histogram {
  name: string;
  buckets: { le: number; count: number }[];  // 分布
  sum: number;
  count: number;
}
// 例: http_request_duration_seconds{le="0.1"} = 8000
//     http_request_duration_seconds{le="0.5"} = 9500
//     http_request_duration_seconds{le="1.0"} = 9900
特徴説明
粒度集計値（集約されたデータ）
用途トレンド分析、アラート、SLO監視
データ量小さい（保存コストが低い）
強み「どれだけ」がわかる、傾向分析に強い
弱み個別のイベント詳細は失われる

第3の柱：トレース（Traces）

トレースは、1つのリクエストがシステム内を流れる経路を記録したものです。

// トレースの構造
interface Trace {
  traceId: string;     // リクエスト全体の識別子
  spans: Span[];       // 各処理区間
}

interface Span {
  traceId: string;
  spanId: string;
  parentSpanId?: string;  // 親Spanへの参照
  operationName: string;
  serviceName: string;
  startTime: number;
  duration: number;       // ミリ秒
  status: 'OK' | 'ERROR';
  attributes: Record<string, unknown>;
}

// トレースの可視化イメージ
// [API Gateway] ──────────────────────────── 250ms
//   └─[Auth Service] ────── 30ms
//   └─[Order Service] ──────────────── 200ms
//       └─[DB Query] ──── 15ms
//       └─[Payment API] ─────────── 170ms  ← ボトルネック！
//       └─[Notification] ── 10ms
特徴説明
粒度リクエスト単位の経路情報
用途ボトルネック特定、依存関係の可視化
データ量中程度（サンプリング可能）
強み「どこで」が経路として見える
弱み全リクエストを記録するとコストが高い

3本柱の使い分け

質問適切なデータ
「エラーの詳細は？」ログ
「エラー率は上昇している？」メトリクス
「どのサービスが遅い？」トレース
「特定ユーザーの問題を調査したい」ログ + トレース
「システム全体の健全性は？」メトリクス
「このリクエストはなぜ遅い？」トレース + ログ

3本柱の相関

メトリクス: エラー率が急増！
    │
    ▼ エラーが多いエンドポイントを特定
トレース: POST /orders のレスポンスタイムが急増
    │
    ▼ 遅延しているSpanを特定
ログ: Payment Service で外部APIタイムアウトが多発
    │
    ▼ 根本原因を特定
対策: タイムアウト設定の調整 + サーキットブレーカー導入

まとめ

柱何がわかるかデータの性質保存コスト
ログ何が起きたか（詳細）個別イベント高い
メトリクスどれだけ起きているか（傾向）集計値低い
トレースどこで起きているか（経路）リクエスト経路中程度

チェックリスト

  • 3本柱それぞれの特徴と用途を説明できる
  • メトリクスの3種類（Counter, Gauge, Histogram）を理解した
  • トレースの構造（Trace, Span）を理解した
  • 3本柱を相関させた障害調査の流れをイメージできる

次のステップへ

次は「OpenTelemetryの全体像」を学びます。3本柱を統一的に扱うための標準フレームワークを見ていきましょう。

推定読了時間: 25分