LabHub

ブログ

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

2026-04-15 · 14 分で読めます · #observability#opentelemetry#prometheus#grafana#loki#tempo#pyroscope#ebpf#slo#sli#error-budget#datadog#season-2

한국어English日本語

はじめに — Observability vs Monitoring

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

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

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

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

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

1.1 Metric

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

1.2 Log

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

1.3 Trace

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

1.4 Profile (第4の軸、2023〜)

プロセス内部の 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

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

2.6 OTEL 進化 (2024〜2025)

第3部 — Prometheus と Grafana Stack

3.1 Grafana Stack (2025 OSS 標準)

コンポーネント役割
Prometheus / MimirMetric
LokiLog
TempoTrace
PyroscopeProfile
Grafanaダッシュボード
Alertmanagerアラート
BeylaeBPF ベース auto-instrumentation

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 破綻。

対処:

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

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

4.2 ログレベル戦略

レベル用途保持
ERRORアラート対象30〜90日
WARN注意30日
INFO主要イベント7〜30日
DEBUG開発のみ未保存または1日
TRACE特殊デバッグ未保存

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 ログソリューション比較

ツールモデル特徴
Loki低コスト、最小インデックスGrafana Stack 標準
Elasticsearch全文検索高コスト
OpenSearchElastic forkAWS 親和
QuickwitRust、ログ特化新興選択肢
ClickHouseカラム DBAnalytics 強い
Vector.dev (Datadog)収集パイプラインルーティング・フィルタ

第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 名・属性規則

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 観測ツール

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 本)

7.2 Error Budget

100% - SLO = Error Budget。

7.3 良い SLI の基準

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

例:

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

商用OSS Stack
Datadog, New Relic, Dynatrace, Splunk, HoneycombGrafana Stack, Signoz, Kibana
高速 ROI、サポート、高度な AI柔軟、低コスト、ロックインなし
コスト暴騰リスク運用人材必要

8.2 状況別推奨

状況推奨
スタートアップ 20名未満Datadog または Signoz SaaS
成長期スタートアップGrafana Cloud または Honeycomb
中堅企業Grafana Stack self-host + Prometheus
大企業混合 (Datadog + OSS + 自社構築)
コスト極限制御ClickHouse + Grafana

8.3 Datadog コスト罠

8.4 Honeycomb の独自価値

第9部 — 組織的 Observability

9.1 Observability-driven Development

9.2 Incident Management との接点

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 追加で測るもの

10.2 ツール

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: 基礎

Month 2: Logging

Month 3: Tracing

Month 4: SLO

Month 5: eBPF + Profile

Month 6: コスト + 組織

第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 の本質は:

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

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

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

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

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

コメント

まだコメントはありません。

ログインするとコメントできます