Observability 完全ガイド — Metric・Log・Trace・OpenTelemetry・eBPF・SLO (Season 2 Ep 9, 2025)

はじめに — Observability vs Monitoring

Monitoring: 既知の問題検知。「CPU > 80% ならアラート」。 Observability: 未知の問題探究。「なぜ突然 P99 が3倍になった?」

9つのブラックボックスを開ける

2025年のエンジニアに必須の能力:

• 分散トレースで要求フローを追跡
• プロファイルで CPU・メモリボトルネック発見
• eBPF でカーネルレベル診断
• SLO・Error Budget でリリース速度を決める
• Log・Metric コストを制御しつつ品質維持

本稿は Observability の 基礎・実戦・コスト・組織 の4レイヤーを一度に扱う。

第1部 — 3軸 + Profile = 4軸の観測性

1.1 Metric

数値の時系列 — 集約・長期保存・アラートが容易。

• 例: http_requests_total{status="200",method="GET"}
• ツール: Prometheus, VictoriaMetrics, Mimir, Cortex
• 長所: 保存効率、ダッシュボード高速
• 短所: Cardinality 爆発リスク (ラベル多いとコスト激増)

1.2 Log

イベントストリーム — 詳細だが大きい。

• 構造化ロギング (JSON) は必須
• ツール: Loki, Elasticsearch, OpenSearch, Quickwit, ClickHouse
• 長所: 詳細・柔軟
• 短所: コスト高、検索遅い

1.3 Trace

要求の因果連鎖 — 分散デバッグの核心。

• 概念: Span (作業単位) + Context Propagation
• ツール: Jaeger, Tempo, Zipkin, Honeycomb
• 長所: どのサービスがボトルネックか一目
• 短所: サンプリング戦略が肝 (100% 保存は非現実)

1.4 Profile (第4の軸、2023〜)

プロセス内部の CPU・メモリプロファイルを継続保存。

• ツール: Pyroscope (Grafana), Parca, Polar Signals
• 長所: 「どの関数が CPU を食うか」をリアルタイムで
• 短所: オーバーヘッド・ストレージ管理

1.5 4軸統合シナリオ

アラート: P99 レイテンシスパイク
  ↓
[Metric] どのサービス? → checkout-service
  ↓
[Trace] どの span? → payment-gateway 呼び出し 3秒
  ↓
[Log] 該当 trace_id のログ → timeout error
  ↓
[Profile] 該当時間の CPU → TLS handshake に 90%
  ↓
原因: 証明書期限切れ間近で TLS handshake 増加

Correlation が鍵。4軸を trace_id で貫く。

第2部 — OpenTelemetry: 観測の標準

2.1 OTEL が解決したもの

以前: ベンダーごとに別 SDK (Prometheus, Datadog, New Relic...)。ベンダー変更 = コード書き直し。

OTEL: 一度計装、どこへでも送信。

2.2 OTEL 構成要素

Application
  ↓ (OTEL SDK)
OTLP Protocol
  ↓
[OTEL Collector]
  ├─ Receivers (OTLP, Prometheus, Jaeger...)
  ├─ Processors (batch, filter, sample, enrich)
  └─ Exporters (Tempo, Loki, Prometheus, Datadog, ...)
  ↓
Backend (where you want)

2.3 Signal 3種 + Profile

• Traces: Stable
• Metrics: Stable
• Logs: Stable (2024)
• Profiles: Beta (2024〜2025)

2.4 Context Propagation

要求が A → B → C と流れる時、同じ trace_id の伝搬が必須:

HTTP Headers:
  traceparent: 00-TRACEID-SPANID-01
  tracestate: ...

W3C Trace Context 標準。OTEL が自動処理。

2.5 Auto-Instrumentation

• Java: -javaagent:opentelemetry-javaagent.jar (バイトコード操作)
• Python: opentelemetry-instrument python app.py
• Node.js: NODE_OPTIONS="--require @opentelemetry/auto-instrumentations-node/register"
• Go: SDK 明示計装 (reflection なし)
• Rust: tracing crate

2.6 OTEL 進化 (2024〜2025)

• Profile Signal 正式化
• Gen AI Semantic Conventions: LLM 呼び出しも標準化
• Exponential Histograms: 高解像度 Metric
• OTEL Collector Contrib: receiver/exporter 数百

第3部 — Prometheus と Grafana Stack

3.1 Grafana Stack (2025 OSS 標準)

3.2 Prometheus の4種 Metric

1. Counter: 単調増加 (リクエスト数)
2. Gauge: 現在値 (メモリ使用)
3. Histogram: バケット化 (レイテンシ分布)
4. Summary: 分位数を直接計算

3.3 PromQL 基本

# 分あたりリクエスト数
rate(http_requests_total[1m])

# サービス別 P99
histogram_quantile(0.99,
  sum(rate(http_request_duration_seconds_bucket[5m])) by (le, service)
)

# エラー率
sum(rate(http_requests_total{status=~"5.."}[5m])) /
sum(rate(http_requests_total[5m]))

3.4 Cardinality 管理

問題: {user_id, path, status, method} → 100万ユーザー × 10 path × 5 status × 4 method = 2億系列。Prometheus 破綻。

対処:

• 高 Cardinality ラベル禁止 (user_id, trace_id など)
• 集約を先、保存を後
• VictoriaMetrics・Mimir で拡張 (Prometheus より効率)

第4部 — ログ管理: コストと品質のバランス

4.1 ログコストが暴走する理由

• Debug ログを本番でそのまま
• JSON でなくテキスト → 検索・集約困難
• 全文検索エンジン (Elastic) コスト
• 保持期間過剰

4.2 ログレベル戦略

4.3 構造化ロギング (必須)

# 悪い例
logger.info(f"User {user_id} logged in from {ip}")

# 良い例
logger.info("user_login", extra={
    "user_id": user_id,
    "ip": ip,
    "trace_id": trace_id,
})

検索・フィルタ・集約がすべて可能に。

4.4 2025 ログソリューション比較

第5部 — Distributed Tracing 実戦

5.1 サンプリング戦略4種

1. Head-based (probabilistic): 要求開始時に N% 決定。単純。Root-leaf 一貫。
2. Rate-limited: 秒あたり X 件のみ
3. Tail-based: 全受信、エラー・遅いもののみ保存。コスト・情報バランス
4. Dynamic: 問題検知時に自動増加

5.2 Tail-based Sampling (2024〜2025 主流)

# OTEL Collector config
processors:
  tail_sampling:
    policies:
      - name: errors
        type: status_code
        status_code: {status_codes: [ERROR]}
      - name: slow
        type: latency
        latency: {threshold_ms: 1000}
      - name: random
        type: probabilistic
        probabilistic: {sampling_percentage: 1}

エラー・遅延は 100%、通常は 1%。

5.3 Span 名・属性規則

• Span 名: service.operation (例: db.query, http.get)
• Attribute: W3C Semantic Conventions に従う
• Event: 主要ステージ (cache.hit, retry, backoff)
• Error: span.setStatus(ERROR) + exception イベント

5.4 分散デバッグ例

Gateway (20ms)
├─ auth-service (5ms)
├─ user-service (50ms)
│  └─ postgres.query (45ms)  ← 遅い
└─ product-service (10ms)

45ms クエリ span 属性 db.statement = "SELECT * FROM users WHERE ..." → インデックス確認。

第6部 — eBPF: コード修正なしの観測

6.1 eBPF とは

Linux カーネルに安全なバイトコードを挿入 → ネットワーク・システムコール・関数呼び出しを追跡。

長所:

• アプリコード修正なしで観測
• オーバーヘッド極小 (カーネル内実行)
• ネットワーク・システムレベル

6.2 2025 eBPF 観測ツール

• Pixie (New Relic): Kubernetes 専用、auto-telemetry
• Cilium Hubble: ネットワークフロー
• Parca: 常時 CPU プロファイル
• Grafana Beyla: auto-instrumentation
• Inspektor Gadget: Kubernetes 用ツールキット
• Odigos: eBPF ベース auto-instrumentation SaaS

6.3 eBPF の真価

「言語不問の auto-instrument」 — Java・Go・Python・Rust・Node どの言語でも HTTP/gRPC/DB 呼び出しを自動 Trace。

短所: カーネル >= 5.x 要件、Windows 未対応 (進行中)、デバッグ難易度高い。

第7部 — SLO・SLI・Error Budget

7.1 定義 (Google SRE 本)

• SLI (Indicator): 測定値 — 「リクエスト 99% が 200ms 以内応答」
• SLO (Objective): 目標 — 「99.9% で SLI 達成」
• SLA (Agreement): 顧客との約束 — 「99.5% 下回れば返金」

7.2 Error Budget

100% - SLO = Error Budget。

• SLO 99.9% → Budget 0.1% = 月 約43分のダウンタイム許容
• Budget 余り → リリース可
• Budget 消尽 → リリース停止、安定化集中

7.3 良い SLI の基準

1. ユーザー中心: 内部指標でなくユーザーが感じるもの
2. 単純: 計算・理解が容易
3. 予測可能: 正常運用で 100% 達成
4. 操作不能: 定義変更で引き上げられない

例:

• 悪: 「サーバー CPU <= 70%」
• 良: 「ユーザー要求 99% が 500ms 以内 200 応答」

7.4 Burn Rate

Error Budget の消尽速度。

Burn Rate = 現在のエラー率 / 許容エラー率

14x burn for 1 hour = 5% budget 消尽
6x burn for 6 hours = 5% budget 消尽

Multi-window alert: 短期高強度 + 長期中強度の組み合わせ → false positive 削減。

7.5 Error Budget Policy

Budget 100〜50% 残り: 通常リリース速度
Budget 50〜10%: リリーステスト強化、feature freeze 準備
Budget 10% 未満: Feature freeze、安定化 sprint
Budget 消尽: ポストモーテム、プロセス見直し

第8部 — 2025 観測プラットフォーム選択

8.1 商用 vs OSS

8.2 状況別推奨

8.3 Datadog コスト罠

• Custom Metrics: 時系列1つ月 約$5。Cardinality 爆発で爆弾
• Log Ingestion: GB あたり高い。フィルタ必須
• APM Host: ホスト月 $31。マイクロサービス多数で激増
• 対策: OTEL Collector で pre-filter, sample, aggregate

8.4 Honeycomb の独自価値

• High-cardinality 検索優先: trace_id, user_id で自由検索
• BubbleUp: 異常グループ自動発見
• 「Metric 先」でなく「生イベント先」哲学

第9部 — 組織的 Observability

9.1 Observability-driven Development

• 開発段階から計装を考える
• PR に「観測性影響」チェックボックス
• 新機能には SLO ドラフト必須
• Post-incident で「なぜ観測できなかったか」分析

9.2 Incident Management との接点

• MTTR 削減 = 観測性成熟度 の代理指標
• Runbook に「このアラート → このダッシュボード → この trace 確認」チェックリスト
• Blameless Postmortem: なぜシステムは検知しなかったか

9.3 観測性コストモデル

総観測コスト = Σ (signal サイズ × 保持期間 × コスト/GB)

削減レバー:
1. Sample (trace 1%, log 10%)
2. Aggregate (Metric は raw でなく rollup)
3. Retention 差別化 (ERROR 90d, INFO 7d)
4. Pre-filter (OTEL Collector)
5. Cold/hot tier (S3 アーカイブ)

目標: 観測コスト = インフラコストの 5〜15% に維持。

第10部 — LLM 観測性 (2024〜2025 新領域)

10.1 追加で測るもの

• Token Usage: prompt / completion トークン
• Latency: TTFT, total, per-token
• Cost: USD 単位 (モデル × トークン)
• Quality: LLM-as-Judge score, user feedback
• Tool Calls: 成功/失敗、チェーン深さ
• Safety: moderation 結果、refuse rate

10.2 ツール

• Langfuse: OSS、セルフホスト可
• LangSmith: LangChain チーム
• Helicone: プロキシベース
• Phoenix (Arize): OSS 強力
• OTEL Gen AI Semantic Conventions: 標準統合

10.3 LLM Trace 構造

user_query (root span)
├─ retrieval (vector search)
│   ├─ embedding (token count)
│   └─ qdrant.search (query vector)
├─ llm.openai.chat (tokens, cost)
│   └─ tool_call: get_weather
│       └─ api.weather
└─ response_generation

第11部 — 6ヶ月 Observability ロードマップ

Month 1: 基礎

• Prometheus + Grafana 導入
• 4種 Metric の理解
• PromQL 基本

Month 2: Logging

• 構造化ロギング標準
• Loki または Elastic 運用
• Log level ポリシー

Month 3: Tracing

• OTEL SDK 統合
• Tempo または Jaeger
• Tail-based sampling

Month 4: SLO

• 主要サービス SLI 定義
• Error Budget 計算
• Burn Rate アラート

Month 5: eBPF + Profile

• Pyroscope 導入
• Cilium Hubble (K8s ネットワーク)
• Beyla auto-instrumentation

Month 6: コスト + 組織

• 観測コスト監査
• LLM 観測性 (Langfuse)
• Post-incident review プロセス

第12部 — Observability チェックリスト 12

1. 3軸 + Profile それぞれの強みが分かる
2. OpenTelemetry Collector 構造を説明できる
3. Prometheus 4種 Metric が分かる
4. Cardinality 爆発 の意味と予防が分かる
5. Head vs Tail-based sampling の違いが分かる
6. W3C Trace Context でサービス接続原理が分かる
7. eBPF が auto-instrumentation に有利な理由 が分かる
8. SLI・SLO・SLA の違いを明確に分かる
9. Error Budget と Burn Rate を計算できる
10. ログコスト削減5種 が分かる
11. Datadog コスト罠 3種が分かる
12. LLM 観測性の新指標5種 が分かる

第13部 — Observability アンチパターン 10

1. 非構造化ログ: printf 式。検索・集約不可
2. Cardinality 無視: ラベルに user_id で爆発
3. 100% trace 保存: コスト・保存破綻。Tail sampling 必須
4. log-to-metric 乱発: 高い。Counter・Gauge で Metric 化
5. アラート疲労: 毎日数百。本当に重要なものだけ
6. SLO なし運用: どれが「問題」か合意なし
7. ダッシュボードジャングル: 50個中10個しか使わない
8. trace_id 未連結: ログに trace_id なし = デバッグ地獄
9. Retention 統一: ERROR と DEBUG を同じ期間 = 無駄
10. 観測性を後回し: リリース後「入れる」= 永遠に先延ばし

終わりに — Observability は「システムの自己認識」だ

人間が痛みを感じられないと身体を管理できないように、システムも 自分の状態を認識 できなければ運用できない。

2025 年の Observability の本質は:

• 標準 (OpenTelemetry でベンダー独立)
• 統合 (4軸を trace_id で貫く)
• 経済性 (コスト制御しつつ品質維持)
• 組織性 (SLO はチーム合意)

ツールは毎年変わる。Grafana Stack は Prometheus → Mimir → Grafana Cloud、Elastic は OpenSearch、Datadog は eBPF へ。しかし 原理は不変 である。

「観測できなければ運用できない」 を忘れるな。

次回予告 — 「セキュリティ完全ガイド: Zero Trust・Secret 管理・OAuth・OIDC・Supply Chain・AI セキュリティ」

Season 2 Ep 10 は「運用の必須」 セキュリティエンジニアリング。次回は:

• Zero Trust アーキテクチャ実戦
• OAuth 2.1 / OIDC / PKCE
• Secret 管理 (Vault, AWS KMS, SOPS)
• SBOM と Supply Chain 攻撃防御
• Container・K8s セキュリティ (Pod Security, Admission)
• OWASP Top 10 for LLM
• セキュリティ観点の観測性

暗号は易しく、セキュリティは難しい。次回に続く。