Observability 2025 完全ガイド: OpenTelemetry、Grafana・Datadog・Honeycomb・SigNoz、SLO・Error Budget、LLM可観測性 (2025)

Season 5 Ep 8 — ガバナンスが「管理」なら、可観測性は 「現実の把握」 だ。2025年のObservabilityはLog・Metric・Traceで止まらず、LLM・データパイプライン・ユーザー体験 まで含む。

• Prologue — 「可観測性は保険ではなくプロダクトだ」
• 第1章 · 3大シグナル + α
  • 1.1 基本の3種
  • 1.2 拡張シグナル
  • 1.3 相関（Correlation）
• 第2章 · OpenTelemetry — 標準の成熟
  • 2.1 何なのか
  • 2.2 構造
  • 2.3 なぜ重要か
  • 2.4 導入の難易度
• 第3章 · Grafanaスタック（オープン）
  • 3.1 構成
  • 3.2 Grafana Cloud
  • 3.3 強み
  • 3.4 限界
• 第4章 · Datadog・New Relic・Splunk・Dynatrace — SaaSの巨人たち
  • 4.1 Datadog
  • 4.2 New Relic
  • 4.3 Splunk
  • 4.4 Dynatrace
  • 4.5 比較
• 第5章 · 新世代 — Honeycomb・SigNoz・Axiom・Tinybird
  • 5.1 Honeycomb
  • 5.2 SigNoz
  • 5.3 Axiom
  • 5.4 Tinybird
  • 5.5 OpenObserve
  • 5.6 共通点
• 第6章 · Logs・Metrics・Tracesの実装実践
  • 6.1 Metric設計
  • 6.2 Log設計
  • 6.3 Trace設計
  • 6.4 RUM
  • 6.5 Synthetic
• 第7章 · SLO・SLI・Error Budget
  • 7.1 概念
  • 7.2 なぜ重要か
  • 7.3 実践的な指標
  • 7.4 Error Budgetのポリシー
  • 7.5 ツール
• 第8章 · LLM Observability（Ep 6の延長）
  • 8.1 追加のシグナル
  • 8.2 主要ツール
  • 8.3 OpenLLMetry
  • 8.4 運用パターン
• 第9章 · カオスエンジニアリング・回復力
  • 9.1 哲学
  • 9.2 ツール
  • 9.3 実践
  • 9.4 データパイプラインへの適用
  • 9.5 2025年のトレンド
• 第10章 · アラート・オンコール・事故対応
  • 10.1 アラート設計
  • 10.2 オンコール文化
  • 10.3 事故対応
  • 10.4 Postmortem
  • 10.5 ツール
• 第11章 · コスト最適化
  • 11.1 ログのコスト
  • 11.2 Metricのコスト
  • 11.3 Traceのコスト
  • 11.4 SaaSのコスト
  • 11.5 現実的な目標
• 第12章 · 韓国企業の可観測性
  • 12.1 現況
  • 12.2 LLM可観測性の導入
  • 12.3 韓国特有の事情
  • 12.4 参考事例
• 第13章 · アンチパターン10選
  • 13.1 「デプロイ後に可観測性を追加」
  • 13.2 すべてのログをDEBUGに
  • 13.3 アラートのスパム
  • 13.4 SLOのない運用
  • 13.5 Traceなしの障害分析
  • 13.6 高カーディナリティなMetricラベル
  • 13.7 ログに機密情報
  • 13.8 Postmortemなしで同じ事故を繰り返す
  • 13.9 SaaSコストの放置
  • 13.10 LLM可観測性がゼロ
• 第14章 · チェックリスト — 可観測性のローンチ前12項目
• 第15章 · 次回予告 — Season 5 Ep 9:「データチームの組織とキャリア」

Prologue — 「可観測性は保険ではなくプロダクトだ」

2015–2020年、多くのチームは可観測性を「事故対応のための保険」として扱っていた。2025年は違う:

• ユーザーの問題を 先に 発見する = 競争優位
• SLOベースの運用 = 開発速度と安定性の両方
• 観測データそのものが プロダクト意思決定の根拠 になる
• LLMプロダクトでは「成果物が正しいか」が観測対象になる

「可観測性はコストだ」と言われた時代は終わった。「可観測性はプロダクト品質の一部だ」が2025年の標準である。

第1章 · 3大シグナル + α

1.1 基本の3種

• Metric: 時系列の数値（CPU・QPS・レイテンシ）
• Log: イベントのテキスト
• Trace: 分散リクエストの経路

1.2 拡張シグナル

• Profile: CPU・メモリのプロファイリング（continuous profiling）
• Event: ビジネス・デプロイ・リリースのイベント
• RUM (Real User Monitoring): ブラウザ・モバイルでのユーザー体感
• Synthetic: 周期的な仮想リクエスト
• LLMイベント: プロンプト・応答・トークン・コスト・フィードバック

1.3 相関（Correlation）

• Metricが尖ったら、その時刻のTrace・Logへジャンプする
• User session → Trace → Log の連結
• 2025年のツールにおける基本のUX

第2章 · OpenTelemetry — 標準の成熟

2.1 何なのか

• 2019年のCNCFプロジェクト（OpenCensus + OpenTracingの統合）
• Metric・Trace・Log・Profile（2024）の標準
• ベンダー中立の収集パイプライン

2.2 構造

• SDK: 言語別（Python/Go/JS/Java/Rustなど）
• Collector: 収集・処理・ルーティング
• OTLPプロトコル: gRPC/HTTP
• Exporter: Prometheus・Datadog・Grafana・New Relicなど

2.3 なぜ重要か

• ベンダーロックインの解消: コードはOTel、バックエンドは交換可能
• 2024–2025年、ほとんどの可観測性ベンダーがOTelネイティブを受け入れた
• Semantic Conventionsでメタデータを標準化（HTTP・DB・メッセージング）

2.4 導入の難易度

• 基本的な収集は簡単だが
• Semantic Conventions・Sampling・コストチューニングには専門性が要る
• 分断された過去のMetric/Log体系の統合が課題

第3章 · Grafanaスタック（オープン）

3.1 構成

• Prometheus（Metric）: 標準、大規模ではMimir/Thanos/VictoriaMetrics
• Loki（Log）: 「インデックスはメタだけ」という設計で低コスト
• Tempo（Trace）: OTel対応、ストレージが安い
• Grafana（UI）: 統合ダッシュボード
• Pyroscope（Profile）: 2023年に買収、継続的プロファイリング

3.2 Grafana Cloud

• 上記スタックのマネージドSaaS
• Free tierがあり、有料は使用量ベース
• 中堅企業にとってコスパの良い選択肢

3.3 強み

• オープンの自由度 + 統合されたUX
• コスト効率が良い（ログ・トレースのストレージ）
• コミュニティの規模が大きい

3.4 限界

• セルフ運用では複数コンポーネントの管理負担がある
• Datadog水準の「all-in-one」体験には及ばない

第4章 · Datadog・New Relic・Splunk・Dynatrace — SaaSの巨人たち

4.1 Datadog

• 業界1位、600以上の統合
• Infrastructure・APM・Logs・RUM・Security・LLM Observabilityのすべて
• コストが最大の不満（売上成長の源泉でもある）

4.2 New Relic

• 2020年の再設計（NRDB）でシグナルを統合
• 2022年に価格モデルを変更（データベース → ユーザーベース）
• Kubernetes・OTelに親和的

4.3 Splunk

• ログ・セキュリティの強者、2023年にCiscoが買収
• エンタープライズ・セキュリティに特化
• Observability Cloud（AppD・SignalFx）を統合中

4.4 Dynatrace

• 自動化・AI（Davis）ベース
• エンタープライズ・大規模で複雑なシステム向け

4.5 比較

第5章 · 新世代 — Honeycomb・SigNoz・Axiom・Tinybird

5.1 Honeycomb

• High-cardinality・探索型の観測を牽引
• BubbleUp（自動相関分析）
• エンジニア文化への影響力が大きい（Charity Majors）

5.2 SigNoz

• オープンソースのDatadog代替
• ClickHouseベース
• セルフホストでコストを削減

5.3 Axiom

• サーバーレスなログ、超低コストのストレージ
• イベント・分析が中心
• コミュニティや個人プロジェクトに人気

5.4 Tinybird

• ClickHouseのAPI-first
• リアルタイム分析・ユーザー向け指標
• 可観測性専用ではないが、似たワークロード

5.5 OpenObserve

• オープンソースのフルスタック
• コストはClickHouseベース

5.6 共通点

• OTel対応
• ClickHouse/Parquetベースの低コストストレージ
• Kafka・Kinesis対応

第6章 · Logs・Metrics・Tracesの実装実践

6.1 Metric設計

• RED（Rate・Errors・Duration）for services
• USE（Utilization・Saturation・Errors）for resources
• Golden signals（Latency・Traffic・Errors・Saturation）
• 高カーディナリティなラベルに注意（Prometheusの暴走）

6.2 Log設計

• 構造化ログ（JSON）
• Trace ID・Span ID・User IDを含める
• 等級（DEBUG/INFO/WARN/ERROR）の一貫性
• 機密情報のマスキング

6.3 Trace設計

• Service boundaryごとにspan
• DB・外部API呼び出しの自動計装
• Sampling（Head・Tail）でコストを管理
• Business attribute（org・plan）を含める

6.4 RUM

• ブラウザ: Web Vitals（LCP・CLS・INP）
• モバイル: 起動時間・クラッシュ・ネットワーク
• ユーザーID・バージョン・デバイスの連結

6.5 Synthetic

• 主要経路を1–5分周期で
• リージョンごとのチェック
• 多段ワークフロー（ログイン→決済）の検証

第7章 · SLO・SLI・Error Budget

7.1 概念

• SLI（Service Level Indicator）: 測定する指標（可用性・レイテンシ）
• SLO（Service Level Objective）: 目標（99.9%の可用性）
• Error Budget: 許容される失敗量（月43分）

7.2 なぜ重要か

• 100%は不可能で不経済
• 新機能のデプロイと安定性の科学的なバランス
• チーム間の共通言語

7.3 実践的な指標

• 可用性: 成功リクエスト / 総リクエスト
• レイテンシ: p95/p99のしきい値以内の比率
• 正確性: 結果のエラー率
• 鮮度: データの遅延時間
• LLM品質: 評価セットのスコア（Ep 6）

7.4 Error Budgetのポリシー

• 予算を使い切ったら機能デプロイを凍結し、安定化作業へ
• 予算が余っていれば積極的にデプロイ・実験する

7.5 ツール

• Grafana SLO、Datadog SLO、Nobl9、Blameless
• Prometheus + Sloth（OSS）
• 月次・四半期のレビューが必須

第8章 · LLM Observability（Ep 6の延長）

8.1 追加のシグナル

• プロンプト・応答のテキスト
• トークン・コスト
• Latency・TTFT（Time to First Token）
• 評価セットのスコア・ユーザーフィードバック
• ツール呼び出し・エージェントのstep

8.2 主要ツール

• LangFuse（オープン+SaaS）
• LangSmith（LangChain）
• Phoenix/Arize
• Helicone
• Weights & Biases Weave
• Traceloop（OpenLLMetryベース）
• Datadog LLM Observability（2024）

8.3 OpenLLMetry

• OpenTelemetryの拡張としてLLMのセマンティックコンベンションを標準化
• 2024年にTraceloop主導で開始 → 2025年はOTel標準化の議論が活発

8.4 運用パターン

• プロンプトのA/B・Canary（Ep 11）
• 評価セットの定期実行 + 回帰アラート
• ユーザーフィードバックを反映するループ
• コスト・トークンのダッシュボード

第9章 · カオスエンジニアリング・回復力

9.1 哲学

• 障害は不可避 → 意図的に起こして 学ぶ
• 2010年のNetflix Chaos Monkeyが起源

9.2 ツール

• Gremlin、LitmusChaos（K8s）、Steadybit
• AWS Fault Injection Service
• Chaos Toolkit

9.3 実践

• ゲームデー（1チームが障害を再現し、残りが対応する）
• Runbookのテスト
• 回復メカニズム（サーキットブレーカー・リトライ・フォールバック）の検証

9.4 データパイプラインへの適用

• Kafkaのパーティションが止まったとき
• DBがフェイルオーバーしたとき
• エンジンが1台落ちたとき

9.5 2025年のトレンド

• Resilience as code: カオスシナリオをコードで管理する
• CI統合: デプロイ前の回復テスト

第10章 · アラート・オンコール・事故対応

10.1 アラート設計

• Symptom-based: ユーザー影響ベース（5XXの増加）
• Cause-basedは避ける: すべての原因にアラートを出すとノイズになる
• Severity（P1/P2/P3）
• スロットリング・抑制

10.2 オンコール文化

• ローテーションは週単位
• Primary・Secondary
• 報酬・休息のポリシー

10.3 事故対応

• Detect → Triage → Mitigate → Resolve → Learn
• コミュニケーションチャネル（Slack専用の部屋）
• 顧客コミュニケーション（Status page）

10.4 Postmortem

• Blameless
• Timeline・Root cause・Action items
• 公開（社内）・記録の保管

10.5 ツール

• PagerDuty、Incident.io、FireHydrant、Rootly
• Slack・MS Teamsの統合
• Jira・Linearの連携（アクション追跡）

第11章 · コスト最適化

11.1 ログのコスト

• 構造化・フィールド分類で保存対象を選ぶ
• 安価なストレージ（ClickHouse・Loki）
• 長期アーカイブ（S3 Glacier）
• 機密情報はすでにマスキング済み

11.2 Metricのコスト

• ラベルのカーディナリティ管理
• Scrape intervalの最適化
• Aggregation rules

11.3 Traceのコスト

• Head samplingは1–10%
• Tail sampling（エラーや遅いものを優先）
• 自動dropping（health checkを除外）

11.4 SaaSのコスト

• 使用量ベースモデルの急増に注意
• 月次レビュー + 予算アラート
• オープンな代替も検討する

11.5 現実的な目標

• 可観測性コスト / インフラコスト = 5–15%が一般的
• 20%を超えたら最適化が必要というシグナル

第12章 · 韓国企業の可観測性

12.1 現況

• 大企業: Datadog・Dynatrace・Splunk + 自社構築
• インターネット企業: Grafanaスタック・Prometheus自社運用 + 一部SaaS
• スタートアップ: Grafana Cloud・Datadog・Axiomの混在
• 金融・公共: オンプレのElastic・Splunk・Prometheus

12.2 LLM可観測性の導入

• 2024年に開始、2025年に急拡大
• LangFuseをオープンソースでセルフホスト
• 自社構築のケース（トス・カカオ・ネイバー）

12.3 韓国特有の事情

• 網分離環境での全面オンプレ要求
• 韓国語のログ・アラート文言
• 祝日・週末の対応文化
• 金融監督院の監査要件

12.4 参考事例

• クーパン: 自社の可観測性プラットフォーム + オープンの混在
• ネイバー: 大規模なElastic + 自社APM
• サムスン・LG・SK: エンタープライズツール + SI構築
• トス: SLOベースの運用文化を牽引

第13章 · アンチパターン10選

13.1 「デプロイ後に可観測性を追加」

最初から計装してこそ価値がある。

13.2 すべてのログをDEBUGに

コストが暴騰し、重要なシグナルが埋もれる。

13.3 アラートのスパム

すべてのエラーにアラート → アラート無視症候群。

13.4 SLOのない運用

「開発 vs 安定性」の政治的な争いになる。

13.5 Traceなしの障害分析

数時間かかり、原因も分からない。

13.6 高カーディナリティなMetricラベル

Prometheusが暴走する。

13.7 ログに機密情報

監査・流出事故。

13.8 Postmortemなしで同じ事故を繰り返す

学習ループの欠如。

13.9 SaaSコストの放置

月末の請求書ショック。

13.10 LLM可観測性がゼロ

ハルシネーション・拒否・コスト暴走を検知できない。

第14章 · チェックリスト — 可観測性のローンチ前12項目

• OpenTelemetryベースの計装（SDK + Collector）
• 3大シグナル + RUM + Synthetic
• 構造化ログ + Trace IDの連結
• SLO/SLIの定義とダッシュボード
• Error budgetのポリシー
• オンコールのローテーション + Runbook
• 深刻度・アラートの設計（Symptom-based）
• Postmortemのプロセス（Blameless）
• LLM可観測性（プロンプト・トークン・フィードバック）
• コストダッシュボード + レビュー周期
• カオスエンジニアリング・回復力の訓練
• セキュリティ・個人情報のガイド

第15章 · 次回予告 — Season 5 Ep 9:「データチームの組織とキャリア」

技術・ガバナンス・可観測性を積み上げたので、次は それを作る人たち だ。Ep 9はデータ・AIチームの組織とキャリアを扱う。

• データエンジニア vs アナリティクスエンジニア vs プラットフォームエンジニア vs サイエンティスト
• ML Engineer・AI Engineerの台頭
• Central vs Embedded vs Meshの組織モデル
• スタートアップ・大企業のチーム規模と役割
• オンコール・知識共有の文化
• リーダーシップの経路（マネージャー vs IC）
• グローバルなリモートと国内特有の事情
• 2025年の年俸・報酬体系
• 採用・面接のトレンド
• 学習・キャリア戦略

「ツールより大事なのはチーム」 — 2025年のデータ組織の現在地。

次回の記事で会おう。

要約: 2025年の可観測性は 「3大シグナル + α」（Metric・Log・Trace + Profile・RUM・Synthetic・LLMイベント）へ広がり、OpenTelemetryが収集の標準になったことでベンダーロックインは急速に解消しつつある。Grafanaスタックはオープンでコスパが良く、Datadog・New Relic・Splunk・Dynatraceは統合とエンタープライズ、Honeycomb・SigNoz・Axiomは新世代の低コスト・高探索性。SLO・Error Budget が開発と安定性のバランスを取る言語になり、LLM可観測性（LangFuse・Phoenix・Helicone・Datadog LLM）はEp 6の延長線上で主流になった。「可観測性は保険ではなくプロダクト品質だ」という宣言が2025年のデフォルト。韓国企業は網分離・韓国語・SLO文化を融合させつつあり、次回はその可観測性を作る データチームと人々 の話だ。