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大シグナル + α
第2章 · OpenTelemetry — 標準の成熟
第3章 · Grafanaスタック（オープン）
第4章 · Datadog・New Relic・Splunk・Dynatrace — SaaSの巨人たち
第5章 · 新世代 — Honeycomb・SigNoz・Axiom・Tinybird
第6章 · Logs・Metrics・Tracesの実装実践
第7章 · SLO・SLI・Error Budget
第8章 · LLM Observability（Ep 6の延長）
第9章 · カオスエンジニアリング・回復力
第10章 · アラート・オンコール・事故対応
第11章 · コスト最適化
第12章 · 韓国企業の可観測性
第13章 · アンチパターン10選
第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 比較

ツール	強み	弱み
Datadog	統合性	コスト
New Relic	透明な価格	機能の分散
Splunk	ログ・セキュリティ	コスト・複雑さ
Dynatrace	自動化	学習曲線
Grafana Cloud	コスパ	統合体験

第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項目

第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文化を融合させつつあり、次回はその可観測性を作る データチームと人々 の話だ。