プロローグ — 2026年、オブザーバビリティは「なぜ?」に答える

2015年、オブザーバビリティはメトリクス・ログ・トレースの3本柱(three pillars)という言葉で始まった。2023年にはCNCFがそこに**continuous profiling**を4番目の柱として正式に加えた。そして2026年現在、本当の変化は別のところで起きている。**計装(instrumentation)が消えた**ということだ。

5年前、JavaアプリにトレースをつけるにはOpenTelemetry SDKをimportし、すべてのメソッドにアノテーションを付け、コンテキスト伝搬をコードで書く必要があった。2026年の標準は**eBPFでカーネルレベルから自動で取る**である。Cilium Hubbleはクラスタの全パケットを見る。PixieはK8sノードにDaemonSetを1つ入れるだけで、すべてのHTTP/gRPC/SQL呼び出しを見る。Beyla、Coroot、Carettaは、コードを一行も変えずにゴールデンシグナルを抽出する。

それでもSDKの時代が終わったわけではない。**OpenTelemetryは2024年にCNCF Graduated**となり、OTLPは事実上のワイヤープロトコル標準になった。eBPFが「タダで手に入る80%」だとすれば、OTel SDKは「残り20%のビジネス的な意味」を埋めるものだ。つまり2026年のスタックの本当の姿は、**eBPF + OTelのハイブリッド**である。

この記事はその地図を描く — 4本柱、知っておくべきeBPFツール群(Cilium / Hubble / Tetragon / Pixie / Inspektor Gadget / Coroot / Beyla / Caretta)、Grafana LGTM(Loki + Tempo + Mimir + Pyroscope)、Datadog/New Relic/Dynatraceといった商用大手、ネットワーク専用ツール(Suzieq、ntopng、ThousandEyes)、そして韓国・日本企業の実際の運用事例まで。

> **オブザーバビリティはモニタリングの上位集合だ。**モニタリングが「決まった指標が閾値を超えるか見るもの」なら、オブザーバビリティは「事前に予想しなかった任意の質問に答えられる、システムの性質」だ。2026年の差を作るのはツールではなく、**その質問を投げられるようにするスタック設計**だ。

この記事で扱うこと:

1. 4本柱(metrics / logs / traces / profiles)とゴールデンシグナル

2. eBPF革命 — Cilium 1.16, Hubble, Tetragon, Pixie

3. OpenTelemetry 2026 — Collector, OTLP, 自動計装

4. メトリクススタック — Prometheus 3.0, VictoriaMetrics, Mimir

5. ログスタック — Loki 3, Elastic, Vector, Quickwit, OpenObserve, SigNoz

6. トレーススタック — Tempo 2, Jaeger 2, Zipkin, Honeycomb

7. Continuous Profiling — Pyroscope, Parca, Polar Signals

8. ネットワークオブザーバビリティ — Suzieq, Skydive, ntopng, ThousandEyes

9. RUM と合成モニタリング — Cloudflare, Checkly, Grafana Synthetic

10. APM 比較 — Datadog, New Relic, Dynatrace, AppDynamics

11. K8sオブザーバビリティ — Prometheus Operator, k9s, Lens

12. サービスメッシュ + オブザーバビリティ — Kiali, Linkerd dashboard

13. DevSecOps + オブザーバビリティ — Falco + OTel

14. ストレージバックエンド — VictoriaMetrics, Mimir, ClickHouse, MinIO

15. コストモデル — Datadog 35-70 USD/ホスト vs LGTM自己ホスト

16. 韓国の事例 — NCsoft Pixie, Coupang Datadog, Naver OTel, Kakao Grafana

17. 日本の事例 — Mercari, LINE Yahoo, CyberAgent

18. SLO/SLI とエラーバジェット運用

19. アラートとPagerDuty/Opsgenie/Incident.io

20. AIネイティブ オブザーバビリティの輪郭

21. 導入ロードマップ — どこから始めるか

22. 参考文献

1. 4本柱とゴールデンシグナル — 何を測るか

オブザーバビリティの出発点は「何を見るか」だ。2026年現在のコンセンサスは4本柱である。

- **メトリクス(Metrics)** — 時系列の数値。`http_requests_total`や`cpu_usage_seconds_total`のようなカウンター/ゲージ/ヒストグラム。最も安く、最も長く保存できる。

- **ログ(Logs)** — イベントのテキスト。事件が起きた瞬間のコンテキストが豊富だが、高価で検索が遅い。

- **トレース(Traces)** — 分散リクエストの因果関係。1つのユーザーリクエストがサービスA → B → C → DBをどう辿ったかを示す。

- **プロファイル(Profiles)** — CPU/メモリ/ロックの関数単位の分布。どの関数がCPUを最も食うかを常に(continuously)追跡する。

ここにGoogle SRE本の**4つのゴールデンシグナル**を対応付けるのが標準的な運用視点だ。

| ゴールデンシグナル | 定義 | メトリクス例 |

| ------------------ | ----------------------------------- | ---------------------------------- |

| Latency | リクエスト処理にかかった時間 | p50/p95/p99 応答時間 |

| Traffic | システムが受けている負荷 | RPS, QPS, MB/s |

| Errors | 失敗率 | 5xxの割合、例外カウント |

| Saturation | リソース飽和度 | CPU使用率、キュー長、ディスクIOPS |

> **USEメソッドとREDメソッド再訪** — Brendan GreggのUSE(Utilization / Saturation / Errors)はリソース中心、Tom WilkieのRED(Rate / Errors / Duration)はリクエスト中心。どちらもゴールデンシグナルのいとこで、どちらの視点で始めるかが最初のダッシュボードの形を決める。

2. eBPF革命 — Cilium, Hubble, Tetragon, Pixie

2026年オブザーバビリティの本当の変曲点は**eBPF**(extended Berkeley Packet Filter)である。Linuxカーネルの中に安全な仮想マシンを立てて、パケット・syscall・ソケットイベントを横取りする技術だが、これがオブザーバビリティに与えた影響は決定的だ。

**eBPFが変えたもの**:

1. **言語非依存(language-agnostic)の計装** — Go/Java/Python/Rust問わず、カーネルが全syscallを見る。

2. **ゼロコード変更(zero-code-change)** — DaemonSetを1つ入れれば終わり。

3. **低オーバーヘッド** — カーネルレベルなのでCPU 1〜3%程度。

4. **L7可視性** — HTTP/gRPC/SQLパーサーをeBPFで動かし、メソッド・パス・ステータスコードまで取る。

**代表的なツール**:

- **Cilium 1.16**(Isovalent、2024年にCisco買収) — K8sネットワーキング + オブザーバビリティ。CNI、サービスメッシュ(Cilium Service Mesh)、セキュリティ、可視化を一括で。

- **Cilium Hubble** — Ciliumの上に乗るフロー(flow)可視化レイヤー。`kubectl exec`でHubble CLIを立ち上げると、どのPodがどのPodにどのポートで話しているかをリアルタイムで見られる。

- **Tetragon** — Ciliumのランタイムセキュリティ姉妹プロジェクト。どのプロセスがどのファイルを開き、どのsyscallを呼んだかを追跡。

- **Pixie**(New Relic買収、CNCF Sandbox) — K8sにDaemonSet 1行で入れると、すべてのHTTP/gRPC/Postgres/Redis呼び出しを自動キャプチャ。PxLという独自クエリ言語を持つ。

- **Inspektor Gadget** — eBPFベースのK8sデバッグツールキット。`kubectl gadget trace dns`のようなコマンドで即座にトレース。

- **Coroot, Caretta, Beyla** — eBPFでサービスマップ・ゴールデンシグナルを自動生成する新世代ツール。BeylaはGrafana Labs出身。

- **bpftrace / BCC Tools** — Brendan Greggのクラシック。`execsnoop`、`tcptracer`、`biolatency`のような単一目的のトレーサー。

Cilium Hubble UIインストール(helm)

cilium install --version 1.16.0

cilium hubble enable --ui

cilium hubble port-forward

http://localhost:12000 でリアルタイムフロー可視化

> **Pixieの魔法** — 通常、分散トレーシングを付けるには全サービスにOTel SDKを埋め込む必要がある。PixieはK8sノードにPEM(Pixie Edge Module)DaemonSetを1つインストールすれば終わりだ。5分で全マイクロサービスのHTTP・gRPC呼び出しグラフが見える。

3. OpenTelemetry 2026 — 事実上の標準

**OpenTelemetry(OTel)は2024年にCNCF Graduated**になった。CNCFの中でKubernetesに次ぐ2番目の大プロジェクトということだ。2026年現在、OTelは「観測データのワイヤー標準」と呼んで差し支えない。

**構成要素**:

- **OTel SDK** — Go / Java / JS / Python / Rust / .NET / PHP / Ruby / Swiftなど11言語を公式サポート

- **OTel Collector** — データパイプライン。収集(receivers) → 処理(processors) → 送信(exporters)

- **自動計装(Auto-instrumentation)** — Javaは`-javaagent`1行、Pythonは`opentelemetry-instrument`1行で自動計装

- **OTLP プロトコル** — gRPC + HTTP。メトリクス/ログ/トレース/プロファイル(2025年GA)を1つのプロトコルで送信

otel-collector-config.yaml

receivers:

otlp:

protocols:

grpc:

endpoint: 0.0.0.0:4317

http:

endpoint: 0.0.0.0:4318

processors:

batch:

timeout: 10s

exporters:

prometheus:

endpoint: 0.0.0.0:8889

loki:

endpoint: http://loki:3100/loki/api/v1/push

otlp/tempo:

endpoint: tempo:4317

tls:

insecure: true

service:

pipelines:

metrics:

receivers: [otlp]

processors: [batch]

exporters: [prometheus]

logs:

receivers: [otlp]

processors: [batch]

exporters: [loki]

traces:

receivers: [otlp]

processors: [batch]

exporters: [otlp/tempo]

> **なぜOTelが勝ったか** — 5年前まではDatadog Agent、New Relic Agent、Jaeger Client、Zipkin Braveが各々独自のSDKを強要していた。1社がDatadogからNew Relicに移るのに数ヶ月かかった。OTelは「データを標準化し、バックエンドを自由に」という約束でこのlock-inを壊した。2026年にはDatadogですらOTLPを1級市民として受ける。

4. メトリクススタック — Prometheus 3.0と仲間たち

メトリクスは最も古く、最も成熟した柱だ。2026年現在、標準は明確に**Prometheus エコシステム**である。

- **Prometheus 3.0**(2024.11リリース) — UTF-8ラベル、ネイティブヒストグラム、OTLPレシーバー内蔵

- **VictoriaMetrics** — Prometheus互換の高性能代替。シングルバイナリ、10倍圧縮

- **Grafana Mimir** — Prometheusの水平拡張バックエンド。AWS S3/GCS/MinIOに長期保存

- **Thanos** — Mimirの先輩。Prometheus + S3 + マルチリージョン グローバルビュー

- **Cortex** — Mimirの前身。いまだに一部インストールで使われる

- **Datadog / New Relic / Dynatrace** — 商用メトリクススタック。SaaSダッシュボードまで含む

Prometheus 3.0 scrape例 + OTLP受信

global:

scrape_interval: 15s

OTLPレシーバー(3.0新機能)

otlp:

promote_resource_attributes:

- service.name

- service.namespace

- deployment.environment

scrape_configs:

- job_name: 'kubernetes-pods'

kubernetes_sd_configs:

- role: pod

VictoriaMetricsとMimirの違い:

| 項目 | VictoriaMetrics | Grafana Mimir |

| ------------ | ------------------ | ------------------------ |

| アーキ | シングルバイナリ | 分散マイクロサービス |

| ストレージ | ローカルディスク | S3/GCS/MinIO |

| クエリ言語 | PromQL + MetricsQL | PromQL |

| 圧縮 | 非常に高い | 中程度 |

| 運用難易度 | 低 | 中 |

| 適合する規模 | 単一〜中規模 | マルチテナント大規模 |

5. ログスタック — Loki, Elastic, Vector, Quickwit

ログは最も高価で、最も問題を起こす柱だ。2026年は**インデックスを減らしてカラムストアを使う**という方向が確固たるものになっている。

- **Grafana Loki 3.x** — 「ラベルだけインデキシング」するログDB。Prometheusと同じモデル、S3バックエンド

- **Elasticsearch / OpenSearch** — クラシック。全文インデキシング。強力だが高価

- **Quickwit** — Rustで書かれた検索エンジン。S3優先、全文インデキシング、Elasticの代替

- **VictoriaLogs** — VictoriaMetricsチームのログDB。高速な全文検索

- **OpenObserve** — Rustベースのオールインワン(メトリクス・ログ・トレース)

- **SigNoz** — ClickHouse上のオープンソース オブザーバビリティ(メトリクス・ログ・トレース)

- **ClickHouse** — カラムストア。Uber、Cloudflareがログバックエンドとして採用

- **Fluentd / Fluent Bit / Vector** — ログコレクター。Vectorは2021年にDatadogが買収したRustベースの新世代

Fluent Bit -> Loki パイプライン例

[INPUT]

Name tail

Path /var/log/containers/*.log

Parser docker

Tag kube.*

[OUTPUT]

Name loki

Match kube.*

Host loki.observability.svc

Port 3100

Labels job=fluentbit

**Loki vs Elasticsearch 一般論**:

- ログをメトリクスと同じように扱いたい → Loki

- 全文検索、SIEM、セキュリティ分析が第一優先 → Elasticsearch / OpenSearch

- Rustスタック、S3優先 → Quickwit / VictoriaLogs

- メトリクス・ログ・トレース統合 → SigNoz / OpenObserve

6. トレーススタック — Tempo 2, Jaeger 2

分散トレースはマイクロサービスの因果関係を見るものだ。「あるユーザーリクエストはどこで遅かったか」の答えをくれる。

- **Grafana Tempo 2.x** — ラベルだけインデキシング、S3バックエンド、Lokiと同じ哲学

- **Jaeger 2**(CNCF Graduated、2024年フル再書き) — OTel Collectorベースで再構築。v1互換

- **Zipkin** — Twitter発祥。今でもシンプルなインストールを望むときに良い

- **Honeycomb** — イベントベース オブザーバビリティの元祖。Charity Majorsの影響力

- **Lightstep**(ServiceNow買収) — 大規模トレース分析

- **AWS X-Ray / GCP Cloud Trace / Azure Monitor** — クラウドネイティブオプション

- **Datadog APM / New Relic APM / Dynatrace** — 商用統合

Python OTel 自動計装の1行

pip install opentelemetry-distro opentelemetry-exporter-otlp

opentelemetry-bootstrap -a install

opentelemetry-instrument --traces_exporter otlp \

--exporter_otlp_endpoint http://tempo:4317 python app.py

> **Jaeger 2の意味** — 1.x時代のJaegerは独自のCassandra/Elasticsearchバックエンドと独自のSDKを持っていた。2024年のJaeger 2はすべてをOTel Collectorベースで再構築した。これは「トレースバックエンドももはやlock-inではない」という宣言だ。

7. Continuous Profiling — Pyroscope, Parca

2023年からオブザーバビリティの**4番目の柱**として定着しているのがcontinuous profilingだ。本番でCPU/メモリ/ロックのプロファイルを常時、1〜5%のオーバーヘッドで取る。

- **Grafana Pyroscope** — CNCF、Polar SignalsのParcaと合流した後継

- **Parca** — オリジナルのeBPFベース プロファイリング。2024年にPyroscopeに統合

- **Polar Signals Cloud** — Parcaの商用ホスティング

- **Datadog Continuous Profiler** — APMに統合された商用オプション

- **Pyroscope OSS** — 自己ホスト可能

代表的なユースケース:

- **CPUホットスポット発見** — どの関数がCPUの60%を食うかを一目で

- **メモリリーク追跡** — 時間に沿ったalloc/freeグラフ

- **ロック競合分析** — どのmutexが最も頻繁にブロッキングか

Kubernetes上にPyroscopeを配備(Helm)

helm repo add grafana https://grafana.github.io/helm-charts

helm install pyroscope grafana/pyroscope \

--set pyroscope.config.scrape_configs[0].job_name=k8s-pods

> **eBPF + Pyroscopeの組み合わせ** — PyroscopeのeBPFプロファイラはノードレベルで全プロセスのCPUプロファイルを自動収集する。コード変更なしにGo、Rust、C++、Pythonまで一度に取れる。

8. ネットワークオブザーバビリティ専用ツール

サービスオブザーバビリティとは別の系統である**ネットワーク自体**の可視性も重要なカテゴリだ。

- **Suzieq** — ネットワーク オブザーバビリティ。スイッチ・ルーター・ファイアウォール状態をSQLでクエリ

- **Skydive** — リアルタイムのネットワークトポロジー + トラフィック可視化

- **ntopng / ntop** — フロー分析(NetFlow / IPFIX / sFlow)のクラシック

- **Netflix Atlas** — Netflix製の時系列モニタリング。クラウドネットワークメトリクスに強い

- **Wireshark / tcpdump** — パケットキャプチャの標準。eBPF時代でも最後の答え

- **Cisco ThousandEyes** — インターネット経路モニタリングSaaS。BGP、DNS、CDN可視性

- **Catchpoint / Pingdom** — 合成モニタリングとインターネットモニタリングの商用

- **Kentik** — 大規模ネットワーク分析SaaS

- **Arista CloudVision** — データセンターネットワーク オブザーバビリティ

Suzieq例: 全BGPセッション状態をSQLで照会

$ suzieq-cli

suzieq> bgp show state=NotEstd

namespace hostname vrf peer state

prod leaf01 default 10.0.0.2 Active

prod leaf03 default 10.0.0.6 Connect

> **クラウドと共にネットワークオブザーバビリティが再び重要になった理由** — 5年前は「ネットワークはクラウドベンダーが面倒を見る」だった。2026年にはマルチクラウド、マルチリージョン、サービスメッシュ、ゼロトラストネットワークが日常になり、**誰が誰と何について話しているか**が再び中心的な問いとなった。

9. RUM(Real User Monitoring)と合成モニタリング

サーバー側オブザーバビリティ同様に重要なのは**ユーザーの画面で実際にどう見えているか**だ。

**RUM(Real User Monitoring)**:

- **Datadog RUM** — 最も成熟。セッションリプレイまで

- **New Relic Browser** — ブラウザモニタリングのクラシック

- **Cloudflare Browser Insights** — CDNと統合されたRUM

- **Sentry Performance** — エラー追跡と統合されたRUM(別記事で扱う)

- **PostHog Session Replay** — プロダクト分析 + セッションリプレイ

**合成モニタリング(Synthetic Monitoring)**:

- **Checkly** — コード優先の合成モニタリング。Playwright統合

- **Datadog Synthetics** — マルチステップAPI/ブラウザチェック

- **Grafana Synthetic Monitoring** — Grafana Cloudに統合

- **Pingdom** — クラシックな可用性モニタリング

- **UptimeRobot, Better Stack** — 単純なpingモニタリングの低コスト

// Checkly 合成モニター例(Playwright)

test('homepage loads', async ({ page }) => {

const res = await page.goto('https://example.com')

expect(res.status()).toBeLessThan(400)

await expect(page.locator('h1')).toContainText('Welcome')

})

> **2026年のRUM標準** — Core Web Vitals(LCP、INP、CLS)をOTLPでOTel Collectorに送り、Grafanaで見るパターンが定着した。Cloudflareはこれを無料で提供する。

10. APM比較 — Datadog vs New Relic vs Dynatrace

商用APM市場の3強はいまだに同じ顔ぶれだ。

| 項目 | Datadog | New Relic | Dynatrace |

| ----------- | -------------- | ----------------- | ------------------ |

| 強み | 統合の広さ、UX | 価格、AI | Davis AI、自動検出 |

| 価格 | ホストあたり 35-70 USD | GBあたり 0.30 USD (体感) | DPS単位(複雑)|

| OTel対応 | 1級市民 | 1級市民 | 1級市民 |

| 自動計装 | 非常に良い | 非常に良い | 最も良い(OneAgent)|

| K8s | 強い | 強い | 強い |

| AI分析 | Bits AI | New Relic AI | Davis AI(元祖) |

**その他のオプション**:

- **AppDynamics**(Cisco/Splunk) — エンタープライズ

- **Elastic Observability** — Elastic Stack統合

- **Splunk Observability**(旧SignalFx) — Splunk Cloud統合

- **Honeycomb** — イベントベース オブザーバビリティの威信ブランド

- **Logz.io / Sumo Logic** — SaaS ELK/統合

> **2026年のトレンド** — 「Datadog 1ベンダーlock-in」から「Grafana LGTM自己ホスト + DatadogやNew Relicは一部領域だけ」のハイブリッドに移る会社が増えている。コスト圧力が主な理由だ。

11. K8sオブザーバビリティ — Operator, k9s, Lens

Kubernetesオブザーバビリティは独立カテゴリで語れるほど豊富だ。

- **Prometheus Operator** — PrometheusをK8sネイティブで運用。`ServiceMonitor`、`PodMonitor` CRD

- **kube-prometheus-stack** — Helm chart統合(Prometheus + Grafana + Alertmanager + node-exporter)

- **kube-state-metrics** — K8sリソース状態をPrometheusメトリクスとして公開

- **node-exporter** — ノードのシステムメトリクス

- **k9s** — ターミナルK8sクライアントの最終形

- **Lens / OpenLens** — GUI K8s IDE

- **k0s, k0sctl** — 軽量K8sディストリビューション

- **Cilium + Hubble + OTel + Pixie** — eBPFフルスタック

Prometheus OperatorのServiceMonitor例

apiVersion: monitoring.coreos.com/v1

kind: ServiceMonitor

metadata:

name: my-app

labels:

release: prometheus

spec:

selector:

matchLabels:

app: my-app

endpoints:

- port: metrics

interval: 30s

12. サービスメッシュとオブザーバビリティ

サービスメッシュはサイドカーが全トラフィックを横取りするため、本質的に**トレース/メトリクスの自動生成器**だ。

- **Istio + Kiali** — KialiはIstioサービスメッシュ トポロジー可視化の標準

- **Linkerd dashboard** — 単純さが強み。CNCF Graduated

- **Consul Connect + Consul UI** — HashiCorpスタック

- **Cilium Service Mesh** — eBPFベースのサイドカーなしメッシュ

- **Envoy Admin** — 全メッシュのデータプレーン。`/stats`エンドポイントで1,000+メトリクス

> **サイドカーなしメッシュ** — Istio Ambient ModeとCilium Service Meshが2024-2025年にGAになり、「ノードレベル データプレーン」が標準になった。オブザーバビリティ観点では、サイドカーが消えても同じデータが得られる点がポイントだ。

13. DevSecOpsとオブザーバビリティの統合

ランタイムセキュリティとオブザーバビリティは同じデータを見るが、違う質問をする。

- **Falco** — eBPF/syscallベースのランタイムセキュリティ(CNCF Graduated)

- **Tetragon** — Ciliumのセキュリティ姉妹プロジェクト

- **OPA / Gatekeeper** — ポリシーエンジン

- **Kubescape** — K8sセキュリティスキャナー(CNCF Incubating)

- **Cloud SIEM** — Datadog Cloud SIEM, Elastic Security, Sumo Logic Cloud SIEM

- **CrowdStrike Falcon / Wiz / Lacework** — CSPM/CNAPP商用

Falco ルール例: コンテナ内でシェルが起動したらアラート

- rule: Terminal shell in container

desc: A shell was used as the entrypoint/exec point in a container

condition: spawned_process and container and shell_procs

output: "A shell was spawned in a container (user=%user.name container=%container.id)"

priority: WARNING

14. ストレージバックエンド — VictoriaMetrics, Mimir, ClickHouse, MinIO

オブザーバビリティデータの量は爆発的だ。どこにどれくらい長く保存するかが核心だ。

- **VictoriaMetrics** — メトリクス長期保存。非常に高い圧縮率

- **Grafana Mimir** — Prometheusメトリクスの分散バックエンド。S3優先

- **Grafana Loki** — ログ。S3優先

- **Grafana Tempo** — トレース。S3優先

- **ClickHouse** — カラムストア。ログ/トレースバックエンドとして急速に採用(SigNoz, OpenObserve, Cloudflare)

- **MinIO** — S3互換オブジェクトストレージ。自己ホスト オブザーバビリティの標準バックエンド

- **AWS S3 / GCS / Azure Blob** — クラウドオプション

保存期間のガイドライン:

| データ種別 | Hot | Warm | Cold |

| ---------- | --------- | --------- | ----------------- |

| メトリクス | 15日 | 90日 | 13ヶ月+ |

| ログ | 7日 | 30日 | 1年+ (S3 IA) |

| トレース | 3-7日 | 30日 | 90日+ |

| プロファイル | 7日 | 30日 | 通常破棄 |

15. コストモデル — SaaS vs 自己ホスト

オブザーバビリティのコストは通常、インフラコストの5-15%を食う。大規模では30%まで行くことも珍しくない。

**SaaS価格(2026年公示価)**:

- **Datadog APM**: ホストあたり約 35-70 USD/月、カスタムメトリクスは別途

- **New Relic**: ユーザーあたり 99 USD/月 + データGBあたり 0.30 USD体感(実際のモデルはより複雑)

- **Dynatrace**: DPS(Davis Platform Subscription)単位、通常ホストあたり 80-200 USD/月

- **Honeycomb**: イベント量ベース、無料枠の後はGBあたり

- **Grafana Cloud Pro**: 使用量ベース、無料枠の後にメトリクスシリーズ/ログGBで課金

**自己ホストLGTM コスト(概算)**:

100ホスト / 日 1TB ログ / 日 100GB トレース想定:

- コンピュート: K8sノード 10台 約 3,000 USD/月

- S3ストレージ: 約 500-800 USD/月(1年保存)

- 運用人件費: 0.5 FTE以上(最大の隠れコスト)

> **結論** — 50ホスト以下ならほぼ常にSaaSが安い。200ホスト以上ならほぼ常に自己ホストが安い。その間は会社事情次第だ。コスト圧力が強い韓国・日本の会社はこの閾値を急速に超えて自己ホストに行く傾向がある。

16. 韓国企業の事例 — NCsoft, Coupang, Naver, Kakao

韓国ビッグテックのオブザーバビリティ導入は、2020年頃のDatadog導入期を経て、2024年以降は段階的に自己ホスト回帰へ移るパターンが見える。

- **NCsoft** — PixieとeBPF導入事例をKubeConで発表(2023年)。ゲームバックエンドのマイクロサービストレースに活用

- **Coupang** — Datadogの大規模ユーザー。APMとインフラモニタリングを統合

- **Naver** — OpenTelemetry導入。独自メトリクス/トレースバックエンド構築事例をDEVIEWで共有

- **Kakao** — Grafanaスタック自己ホスト。メッセンジャーバックエンドのメトリクス可視性に活用

- **配達の民族(우아한형제들)** — Datadog + 自己ホストGrafanaのハイブリッド

- **カカオバンク/Toss** — 金融規制ゆえに自己ホスト比率が高い。ELK + Grafanaが多い

- **当根市場(Daangn)** — Datadog APM + Sentryの組合せ

- **LINEプラス韓国** — OpenTelemetry + Grafana

> **共通パターン** — 韓国の会社は(1)初期の素早い可視性はDatadog/New Relicで始め、(2)コストが一定の閾値を超えるとLGTMスタックに移しつつ、RUM/Sentryは残すハイブリッドが一般的だ。

17. 日本企業の事例 — Mercari, LINE Yahoo, CyberAgent

日本市場は韓国よりOpenTelemetryとeBPFの採用が一歩早いという評価がある。

- **Mercari** — Datadogのメジャーユーザー。OTel移行をSRECon 2024で発表

- **LINE Yahoo** — 合併後にOpenTelemetry標準化を加速。独自メトリクスバックエンド

- **CyberAgent** — Cilium大規模導入。KubeConでeBPF発表多数

- **DeNA** — Datadog + Grafanaハイブリッド

- **Rakuten** — Splunkの大規模ユーザー。APMはNew Relic

- **PayPay** — AWSネイティブ オブザーバビリティ + Datadog

- **Smartbank / Kyash** — フィンテックスタートアップのOTel導入事例

- **メルカリ MLチーム** — Pyroscope/Parcaで機械学習ワークロードのプロファイリング

> **日本のSREカルチャー** — Mercari、CyberAgentを中心としたSREコミュニティ(SRE Lounge、SRE NEXTカンファレンス)がオブザーバビリティのベストプラクティス普及に大きな役割を果たしている。韓国より一拍早いOTel採用の背景だ。

18. SLO/SLIとエラーバジェット運用

オブザーバビリティの行き着く先は**SLO(Service Level Objective)**だ。「p99応答時間が200ms以下で、可用性は99.9%」を定義し、それをメトリクスでモニタリングし、違反したらエラーバジェットを消費するモデルだ。

ツール:

- **Sloth** — PrometheusベースのSLOジェネレーター。YAMLでSLO定義

- **Pyrra** — SlothのようなSLOコントローラー

- **OpenSLO** — SLO定義のYAML標準

- **Nobl9** — SLO専門SaaS

- **Datadog SLO / Honeycomb SLO** — APM内蔵オプション

Sloth SLO 定義例

version: prometheus/v1

service: my-api

slos:

- name: requests-availability

objective: 99.9

sli:

events:

error_query: sum(rate(http_requests_total{code=~"5.."}[5m]))

total_query: sum(rate(http_requests_total[5m]))

alerting:

page_alert:

labels:

severity: page

ticket_alert:

labels:

severity: ticket

19. アラートとインシデント管理

オブザーバビリティの最終段はアラートとインシデント対応だ。

- **Alertmanager** — Prometheusエコシステムの標準

- **Grafana Alerting** — Grafana統合オプション(マルチデータソース)

- **PagerDuty** — インシデント管理のSaaS標準

- **Opsgenie**(Atlassian) — PagerDutyの競合

- **Incident.io** — チャット優先の新世代インシデント管理。Slack統合が強力

- **FireHydrant, Rootly** — インシデント管理の新興SaaS

- **Better Stack** — Uptime モニタリング + インシデント管理統合

> **2026年の流れ** — Slack/Teamsがインシデントルームの標準になり、Incident.ioのようなツールがその上で自動でチャネルを作り、ステータスページを更新し、ポストモーテムを始める。PagerDutyも同じ方向に急速に進化中。

20. AIネイティブ オブザーバビリティの輪郭

2026年最大の話題は**AIがオブザーバビリティをどう変えるか**だ。

- **自動根本原因分析(RCA)** — Dynatrace Davis、New Relic AI、Datadog Bits AI

- **自然言語クエリ** — Honeycomb Query Assistant、Grafana LLM、Datadog AI Assistant

- **異常検出の自動化** — すべてのメジャーAPMがMLベースの異常検出を提供

- **LLM オブザーバビリティそのもの** — LangSmith、Helicone、Phoenix、Arize、OpenLLMetry。LLM応答のlatency/cost/qualityをトレース

- **エージェントトレース** — OTelのGenAI semantic conventionsが2025年に発表。エージェントツール呼び出しのトレース標準

> **AIワークロードのオブザーバビリティ** — LLMは非決定的で高価だ。「このユーザーリクエストはGPT-4oに行ったのかClaude 3.5に行ったのか、トークンをいくつ使ったか、誰がクエリをキャッシュしたか」が新しいゴールデンシグナルになりつつある。

21. 導入ロードマップ — どこから始めるか

オブザーバビリティスタックを新しく組むなら、2026年基準で推奨する順は次の通り。

1. **メトリクスから** — Prometheus + Grafanaで始める。node-exporter、kube-state-metrics

2. **ログの標準化** — LokiまたはElastic。Vector/Fluent Bitで収集を統一

3. **トレースの導入** — Tempo + OTel Collector。自動計装から

4. **eBPFで可視性 80%を埋める** — Cilium HubbleかPixieのどちらか

5. **continuous profilingを追加** — PyroscopeをGrafanaに統合

6. **SLO定義** — Slothで主要サービス 3-5個のSLOをYAMLで

7. **AI/LLMトレース** — LLM使うならLangSmithかPhoenixをOTelと一緒に

8. **インシデント管理自動化** — Incident.ioかPagerDutyをSlackに統合

**スタートアップ(1-20人)**:

- SaaSをフル活用 — DatadogかNew Relic + Sentry + Better Stack

- 学習曲線を買わずにコードを書こう

**中規模(20-200人)**:

- Grafana Cloud + Sentry + Incident.io

- コストを見ながらLGTM自己ホストに段階的移行

**大規模(200人+)**:

- LGTM自己ホスト + 一部領域(RUM、APM)だけSaaS

- 専属のオブザーバビリティ プラットフォームチーム

22. 参考文献

- [OpenTelemetry Project](https://opentelemetry.io)

- [OpenTelemetry CNCF Graduation Announcement](https://www.cncf.io/announcements/2024/09/12/cloud-native-computing-foundation-announces-opentelemetry-graduation/)

- [Cilium Project](https://cilium.io)

- [Hubble — Cilium Flow Observability](https://github.com/cilium/hubble)

- [Tetragon — eBPF Security Observability](https://tetragon.io)

- [Pixie — Auto-instrument K8s with eBPF](https://px.dev)

- [Inspektor Gadget](https://www.inspektor-gadget.io)

- [Grafana Pyroscope](https://grafana.com/oss/pyroscope/)

- [Grafana Tempo](https://grafana.com/oss/tempo/)

- [Grafana Loki](https://grafana.com/oss/loki/)

- [Grafana Mimir](https://grafana.com/oss/mimir/)

- [Jaeger 2 Announcement](https://www.jaegertracing.io/docs/2.0/)

- [Prometheus 3.0 Release Notes](https://prometheus.io/blog/2024/11/14/prometheus-3-0/)

- [VictoriaMetrics](https://victoriametrics.com)

- [Quickwit — Cloud-native Search](https://quickwit.io)

- [SigNoz — Open Source Observability](https://signoz.io)

- [Coroot — eBPF Observability](https://coroot.com)

- [Beyla — eBPF Auto-instrumentation](https://grafana.com/oss/beyla-ebpf/)

- [Brendan Gregg — BPF Performance Tools](https://www.brendangregg.com/bpf-performance-tools-book.html)

- [Google SRE Book — Service Level Objectives](https://sre.google/sre-book/service-level-objectives/)

- [Honeycomb — Observability Engineering Book](https://www.oreilly.com/library/view/observability-engineering/9781492076438/)

- [Datadog Pricing](https://www.datadoghq.com/pricing/)

- [Sloth — Prometheus SLO Generator](https://sloth.dev)

- [Falco — Runtime Security](https://falco.org)