LabHub

ブログ

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

2026-05-16 · 27 分で読めます · #observability#ebpf#cilium-hubble#pixie#pyroscope#loki#tempo#netdata#opentelemetry#monitoring#japanese

한국어English日本語

プロローグ — 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本柱である。

ここに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 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-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 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の違い:

項目VictoriaMetricsGrafana Mimir
アーキシングルバイナリ分散マイクロサービス
ストレージローカルディスクS3/GCS/MinIO
クエリ言語PromQL + MetricsQLPromQL
圧縮非常に高い中程度
運用難易度低中
適合する規模単一〜中規模マルチテナント大規模

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

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

# 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 一般論:

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

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

# 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%のオーバーヘッドで取る。

代表的なユースケース:

# 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例: 全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):

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

// 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強はいまだに同じ顔ぶれだ。

項目DatadogNew RelicDynatrace
強み統合の広さ、UX価格、AIDavis AI、自動検出
価格ホストあたり 35-70 USDGBあたり 0.30 USD (体感)DPS単位(複雑)
OTel対応1級市民1級市民1級市民
自動計装非常に良い非常に良い最も良い(OneAgent)
K8s強い強い強い
AI分析Bits AINew Relic AIDavis AI(元祖)

その他のオプション:

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

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

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

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

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

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

# 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

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

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

データ種別HotWarmCold
メトリクス15日90日13ヶ月+
ログ7日30日1年+ (S3 IA)
トレース3-7日30日90日+
プロファイル7日30日通常破棄

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

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

SaaS価格(2026年公示価):

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

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

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

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

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

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

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

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

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

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

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

ツール:

# 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. アラートとインシデント管理

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

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

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

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

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人):

中規模(20-200人):

大規模(200人+):

22. 参考文献

原文を読む: https://www.youngju.dev/blog/culture/2026-05-16-network-service-observability-2026-ebpf-cilium-hubble-pixie-pyroscope-grafana-loki-tempo-netdata-deep-dive.ja

コメント

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

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