ネットワーク & サービスオブザーバビリティ 2026 完全ガイド — eBPF · Cilium Hubble · Pixie · Pyroscope · Grafana Loki + Tempo + Mimir · Netdata · OpenTelemetry 深掘り

プロローグ — 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年の差を作るのはツールではなく、その質問を投げられるようにするスタック設計だ。

この記事で扱うこと:

4本柱(metrics / logs / traces / profiles)とゴールデンシグナル
eBPF革命 — Cilium 1.16, Hubble, Tetragon, Pixie
OpenTelemetry 2026 — Collector, OTLP, 自動計装
メトリクススタック — Prometheus 3.0, VictoriaMetrics, Mimir
ログスタック — Loki 3, Elastic, Vector, Quickwit, OpenObserve, SigNoz
トレーススタック — Tempo 2, Jaeger 2, Zipkin, Honeycomb
Continuous Profiling — Pyroscope, Parca, Polar Signals
ネットワークオブザーバビリティ — Suzieq, Skydive, ntopng, ThousandEyes
RUM と合成モニタリング — Cloudflare, Checkly, Grafana Synthetic
APM 比較 — Datadog, New Relic, Dynatrace, AppDynamics
K8sオブザーバビリティ — Prometheus Operator, k9s, Lens
サービスメッシュ + オブザーバビリティ — Kiali, Linkerd dashboard
DevSecOps + オブザーバビリティ — Falco + OTel
ストレージバックエンド — VictoriaMetrics, Mimir, ClickHouse, MinIO
コストモデル — Datadog 35-70 USD/ホスト vs LGTM自己ホスト
韓国の事例 — NCsoft Pixie, Coupang Datadog, Naver OTel, Kakao Grafana
日本の事例 — Mercari, LINE Yahoo, CyberAgent
SLO/SLI とエラーバジェット運用
アラートとPagerDuty/Opsgenie/Incident.io
AIネイティブオブザーバビリティの輪郭
導入ロードマップ — どこから始めるか
参考文献

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が変えたもの:

言語非依存(language-agnostic)の計装 — Go/Java/Python/Rust問わず、カーネルが全syscallを見る。
ゼロコード変更(zero-code-change) — DaemonSetを1つ入れれば終わり。
低オーバーヘッド — カーネルレベルなのでCPU 1〜3%程度。
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は-javaagent1行、Pythonはopentelemetry-instrument1行で自動計装
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)
import { expect, test } from '@playwright/test'

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年基準で推奨する順は次の通り。

メトリクスから — Prometheus + Grafanaで始める。node-exporter、kube-state-metrics
ログの標準化 — LokiまたはElastic。Vector/Fluent Bitで収集を統一
トレースの導入 — Tempo + OTel Collector。自動計装から
eBPFで可視性 80%を埋める — Cilium HubbleかPixieのどちらか
continuous profilingを追加 — PyroscopeをGrafanaに統合
SLO定義 — Slothで主要サービス 3-5個のSLOをYAMLで
AI/LLMトレース — LLM使うならLangSmithかPhoenixをOTelと一緒に
インシデント管理自動化 — 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
専属のオブザーバビリティプラットフォームチーム