LabHub

ブログ

オブザーバビリティ 2026 完全ガイド - OpenTelemetry・Datadog・Grafana スタック（LGTM+Beyla）・Honeycomb・Prometheus・Jaeger・eBPF・SLO 徹底解説

2026-05-16 · 26 分で読めます · #observability#opentelemetry#datadog#grafana#honeycomb#prometheus#jaeger#tempo#loki#mimir#pyroscope#ebpf#slo#sli#monitoring

한국어English日本語

はじめに — 2026年5月、オブザーバビリティは OpenTelemetry が基本になった

2024年までは「どの APM を選ぶか」がベンダー選択の問題だった。2026年5月の今、その手前の問いが収束している。計装（instrumentation）は OpenTelemetry で行い、その後ろの 保存・可視化・アラート・根本原因分析 だけがベンダーごとに分かれる。OTel は CNCF で Kubernetes に次ぐ活動量を持つプロジェクトで、OTLP（gRPC/HTTP）は事実上の業界標準ワイヤーフォーマットになった。Datadog・New Relic・Splunk・Dynatrace・Honeycomb・Chronosphere・Grafana Cloud・Coralogix・Logz.io、いずれも OTLP を一級でサポートする。

もう一つの大きな変化は AI for observability である。2025年に Datadog Bits AI、New Relic AI（NRAI）、Dynatrace Davis AI がそろって、自然言語による根本原因サマリ、自動異常検知、インシデントタイムライン生成を標準機能として実装した。「なぜ p99 がスパイクしたのか」を問うインターフェースが、クエリ言語から自然言語へ移っている。

本稿はマーケティング比較ではない。2026年のプロダクションで何がどこに入るのか、OTel の上でどう組み立てるのか、SaaS と自前ホスティングをどう決めるのか、SLO とエラーバジェットをどう運用するのかを、正直に書く。

三本柱（three pillars） — そしてその先

伝統的なオブザーバビリティの三本柱は メトリクス（metrics）・ログ（logs）・トレース（traces） である。2026年には、さらに二つが一級市民になった。

  1. 継続的プロファイリング: CPU/メモリのプロファイルを24時間収集する（Pyroscope、Parca、Polar Signals、Datadog Continuous Profiler）。
  2. RUM（Real User Monitoring）とシンセティック: ブラウザ/モバイルから LCP、INP、FCP、ロングタスク、ネットワークウォーターフォールを収集する。

業界では MELT（Metrics、Events、Logs、Traces）、プロファイリングを含めて MELT+P と呼ぶことも増えた。三本柱より重要なのは 相互接続性 で、メトリクスからトレース、トレースからログ、ログからプロファイルへ、ワンクリックで飛べる必要がある。この「exemplar → trace → log → profile」のチェーンが2026年のオブザーバビリティ UX 標準である。

OpenTelemetry — 標準となった計装レイヤー

OTel は三つで構成される。

Python の自動計装はこのくらい短い。

# requirements.txt
# opentelemetry-distro==0.50b0
# opentelemetry-exporter-otlp==1.30.0

# 1行で終わる自動計装
# $ opentelemetry-bootstrap -a install
# $ OTEL_SERVICE_NAME=checkout-api \
#   OTEL_EXPORTER_OTLP_ENDPOINT=http://otel-collector:4317 \
#   opentelemetry-instrument python app.py

from fastapi import FastAPI
from opentelemetry import trace

tracer = trace.get_tracer(__name__)
app = FastAPI()

@app.get("/checkout/{order_id}")
def checkout(order_id: str):
    with tracer.start_as_current_span("validate_order") as span:
        span.set_attribute("order.id", order_id)
        # ビジネスロジック
        return {"ok": True, "order_id": order_id}

opentelemetry-instrument を付けるだけで、FastAPI、requests、SQLAlchemy、psycopg、Redis、Kafka クライアントなど50以上のライブラリが自動でトレースとメトリクスを発行する。手動計装はビジネスドメインのスパンだけに使う のが鉄則だ。

OTel Collector — パイプラインの心臓

Collector は receivers → processors → exporters のパイプラインを YAML で宣言する。2026年の標準デプロイは agent + gateway の2層構成だ。

# otel-collector-gateway.yaml
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:
    send_batch_size: 8192
    timeout: 5s
  memory_limiter:
    check_interval: 1s
    limit_percentage: 80
    spike_limit_percentage: 25
  resourcedetection:
    detectors: [env, system, eks, gcp]
  tail_sampling:
    decision_wait: 30s
    policies:
      - name: errors-policy
        type: status_code
        status_code: {status_codes: [ERROR]}
      - name: slow-policy
        type: latency
        latency: {threshold_ms: 500}
      - name: baseline-policy
        type: probabilistic
        probabilistic: {sampling_percentage: 5}

exporters:
  otlp/datadog:
    endpoint: api.datadoghq.com:443
    headers: {dd-api-key: "$DD_API_KEY"}
  otlphttp/grafana:
    endpoint: https://otlp-gateway.grafana.net/otlp
  prometheus:
    endpoint: 0.0.0.0:9464

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, resourcedetection, tail_sampling, batch]
      exporters: [otlp/datadog, otlphttp/grafana]
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, resourcedetection, batch]
      exporters: [prometheus, otlphttp/grafana]

要は tail sampling だ。エラーと遅いトレースは100%残し、それ以外は5%程度のサンプリングでコストを抑える。Datadog の Trace API は基本ヘッドサンプリングだが、OTel Collector ならゲートウェイで tail decision を下せるので自由度が高い。

メトリクス — Prometheus とその先

Prometheus は2026年も依然としてメトリクス標準である。PromQL は業界の共通語で、OTel Collector → Prometheus Remote Write も GA。ただし単体 Prometheus にはカーディナリティと保持期間の限界があるので、通常は 長期保存バックエンド とセットで使う。

典型的な PromQL レコーディングルール（SLI として 5xx 比率）はこうなる。

# recording-rules.yaml
groups:
  - name: checkout-sli
    interval: 30s
    rules:
      - record: job:http_request_errors:ratio_5m
        expr: |
          sum(rate(http_server_request_duration_seconds_count{job="checkout-api",http_response_status_code=~"5.."}[5m]))
          /
          sum(rate(http_server_request_duration_seconds_count{job="checkout-api"}[5m]))
      - record: job:http_request_latency:p99_5m
        expr: |
          histogram_quantile(0.99,
            sum by (le) (rate(http_server_request_duration_seconds_bucket{job="checkout-api"}[5m]))
          )
      - alert: HighErrorRate
        expr: job:http_request_errors:ratio_5m > 0.01
        for: 10m
        labels: {severity: page, service: checkout}
        annotations:
          summary: "checkout 5xx > 1% for 10m"

histogram_quantile と OTel ヒストグラム互換は2025年中頃に native histogram（exponential）で統一された。旧 le-bucket 方式よりメモリ使用量は5〜10倍小さく、精度は高い。

カーディナリティ危機とコスト管理

OTel Collector で未使用メトリクスと属性をドロップする transform processor の例。

# カーディナリティ・ドロップルール
processors:
  transform/metrics:
    metric_statements:
      - context: datapoint
        statements:
          - delete_key(attributes, "request_id")
          - delete_key(attributes, "build_sha")
      - context: metric
        statements:
          - drop() where name == "unused_metric_legacy"
  filter/spans:
    spans:
      exclude:
        match_type: regexp
        attributes:
          - key: http.url
            value: "/healthz|/metrics|/readyz"

2024年から業界共通の頭痛のタネが カーディナリティ爆発 だ。user_id、request_id、build_sha のようなラベルを何気なく付けると、時系列が数百万件に膨らむ。Datadog、Splunk Observability、New Relic はカスタムメトリクスごとに課金されるので、四半期ごとに請求書が2倍になる事故が珍しくない。

2026年の模範解答は3方向ある。

  1. 高カーディナリティはトレース/ログへ: メトリクスのラベルではなくイベント属性として保存する（Honeycomb の哲学）。
  2. Adaptive sampling + ドロップルール: OTel Collector の transformprocessor や Datadog の Metric Pipelines で未使用ラベルを自動ドロップ。
  3. カーディナリティ制御 SaaS: Chronosphere Control Plane、Grafana Adaptive Metrics、Cribl Stream が未使用シリーズを識別して自動削除。

Honeycomb の Charity Majors が2017年から訴え続けた「wide、structured events」が、2026年に実際の標準になった。メトリクスは SLI/SLA 用のカウンタやゲージだけにとどめ、次元の多いデータは events/traces に流す。

Datadog — 統合 SaaS の絶対王者

Datadog は2026年に売上30億ドル超、800以上の統合を持つ事実上のカテゴリ定義者である。APM、Logs、RUM、Synthetic、Continuous Profiler、Database Monitoring、Network Performance Monitoring、CWPP/CNAPP まで一つのコンソールで見られる。2025年に GA した Bits AI は、自然言語によるトレース分析、インシデント要約、IaC コード生成までサポートする。

長所は明確だ。

短所も明確だ。

Grafana Stack — OSS 陣営の LGTM+Beyla

Grafana Labs は Loki（ログ）+ Mimir（メトリクス）+ Tempo（トレース）+ Pyroscope（プロファイル）+ Beyla（eBPF 自動計装）でフルスタックをそろえた。Apache 2.0 + AGPL（エディション別）のライセンスで、自前ホスティングも Grafana Cloud SaaS も選べる。

Loki の LogQL は PromQL に似た直感的なクエリだ。

# Loki LogQL — 直近5分の checkout 5xx 推移
{service_name="checkout-api"} |= "ERROR"
  | json
  | http_response_status_code >= 500
  | rate(5m)

# Tempo TraceQL — p99 で1秒を超えた checkout トレース
{ resource.service.name = "checkout-api" && duration > 1s && status = error }

# Mimir PromQL — ノード CPU 使用率
100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

Tempo TraceQL は2024年 GA 以降、2026年現在で最も表現力の高いトレースクエリ言語と評価されている。スパン属性、リソース属性、子スパンの条件を1クエリにまとめられる。

Beyla は2024年にリリースされたゼロインストルメンテーション eBPF 自動計装ツールだ。コードを1行も変えずに HTTP/gRPC スパンと RED メトリクスを抽出する。Go、Java、Python、Node.js、Rust すべて対応。2026年の Beyla 1.10 系では mTLS トラフィックもデコードできる。

Honeycomb — wide events と BubbleUp の哲学

Honeycomb は2016年に Charity Majors と Christine Yen が Facebook Scuba から着想を得て創業した。数十〜数百次元の wide event が基本単位で、すべてのクエリでどの次元もアドホックにグルーピング/フィルタできる。カーディナリティ制限はない。

価格はイベント数ベースで Datadog より安めだが、メトリクスとログを別途処理するならコストは増える。2026年は「デバッグと SLO に本気のチーム」が好む Datadog/New Relic 代替として位置づいている。

Jaeger / Tempo / Zipkin — 分散トレーシング3強

OSS のトレースバックエンドは3つに集約される。

Jaeger v2 + Tempo + OTel Collector の組み合わせが、2026年の自前ホスティング標準だ。ClickHouse をトレースバックエンドとして直接使う会社（Uber、Cloudflare）も増えている。

eBPF Observability — コード変更なしの観測

eBPF が観測ツールの新カテゴリを生み出した。カーネルで syscall・ネットワーク・CPU イベントを直接取りに行き、コード変更ゼロで RED メトリクス、分散トレース、プロファイルを抽出する。

eBPF の弱点は Go などのユーザ空間ランタイムでパラメータ抽出が限定的 な点だ。だからビジネスロジックのスパンは引き続き OTel SDK が必要になる。2026年の標準は「eBPF で RED + ゴールデンシグナル、OTel SDK でドメインスパン」の分業である。

Prometheus 運用の現実 — Mimir vs Thanos vs Cortex vs VictoriaMetrics

長期保存バックエンドの選択は、2026年もまだ決着がついていない議論だ。

項目MimirThanosCortexVictoriaMetrics
ライセンスAGPL v3Apache 2.0Apache 2.0Apache 2.0
マルチテナント強い普通強い強い
圧縮効率良い良い良い非常に良い
単一バイナリNoNoNoYes
運用コスト高い中高い低い
商用サポートGrafanaコミュニティコミュニティVictoriaMetrics
カーディナリティ上限1億+5,000万1億+5億+

大規模 SRE チームなら Mimir、運用人員が少なければ VictoriaMetrics、既に Thanos を運用しているなら無理に乗り換える理由はない。

継続的プロファイリング — Pyroscope、Parca、Polar Signals

継続的プロファイリングは2024〜2025年に独立したカテゴリとして固まった。CPU/メモリ/ロックのプロファイルを24時間収集して、回帰を捕まえ、コストを最適化する。

各社が一番よく見つける問題は、(1) JSON シリアライズのホットスポット、(2) 正規表現の都度コンパイル、(3) Go GC GOGC の未チューニング、(4) Python の GIL コンテンションだ。

RUM とシンセティック — ユーザ視点の観測

サーバ側のメトリクスだけ見ても「なぜユーザは遅いと言っているのか」は分からない。RUM（Real User Monitoring） と シンセティックモニタリング がそのギャップを埋める。

2025年に Google が INP を LCP・CLS と並ぶ Core Web Vital に昇格させ、RUM でのロングタスクと入力遅延の測定が必須になった。

SLO とエラーバジェット — Google SRE の遺産

SLO（Service Level Objective）は2018年の Google SRE 本以降、業界の共通語になった。2026年には SLO 専用ツールカテゴリも確立している。

典型的な SLO 定義はこうなる。

# slo.yaml — Sloth 形式
version: prometheus/v1
service: checkout-api
slos:
  - name: availability
    objective: 99.9
    description: "checkout 5xx 比率を 0.1% 以下に"
    sli:
      events:
        error_query: sum(rate(http_server_request_duration_seconds_count{job="checkout-api",http_response_status_code=~"5.."}[{{.window}}]))
        total_query: sum(rate(http_server_request_duration_seconds_count{job="checkout-api"}[{{.window}}]))
    alerting:
      page_alert:
        labels: {severity: page}
      ticket_alert:
        labels: {severity: ticket}

99.9% SLO は月間 43.2 分のダウンタイム予算に相当する。この予算を バーンレート で追跡すると、単純な閾値アラートよりはるかに賢い。5分窓で 14.4 倍のバーン（1時間で年間予算を使い切るペース）なら即ページ、6時間窓で 6 倍ならチケット、というのが定石だ。

RED、USE、LETS、Golden Signals — 観測方法論の整理

観測メトリクスを選ぶ方法論は4つに整理できる。

実務では「ユーザが影響を受ける表面（API、ページ）= RED + Saturation」と「インフラリソース（ノード、DB、キュー）= USE」をセットで見る。

分散トレースのコンテキスト伝播 — W3C TraceContext + Baggage

分散トレーシングが機能するには、すべてのサービス hop で trace ID、span ID、サンプリング決定が伝播する必要がある。2026年の標準は W3C TraceContext + W3C Baggage だ。

OTel SDK はデフォルトプロパゲータでこれを自動処理するが、gRPC メタデータ、Kafka メッセージヘッダー、Lambda コンテキストなど非 HTTP 経路では明示的な計装が必要になる。

ClickHouse をトレースバックエンドにしたときの典型的なクエリ。

-- 直近1時間の p99 トレース検索
SELECT
    TraceId,
    SpanName,
    Duration / 1e6 AS duration_ms,
    SpanAttributes['http.url'] AS url,
    ResourceAttributes['service.name'] AS service
FROM otel_traces
WHERE Timestamp > now() - INTERVAL 1 HOUR
  AND ResourceAttributes['service.name'] = 'checkout-api'
  AND StatusCode = 'STATUS_CODE_ERROR'
ORDER BY duration_ms DESC
LIMIT 50;

ログパイプライン — Vector、Fluent Bit、Logstash、Elastic、Splunk

ログはメトリクスやトレースより高価で扱いが難しい。2026年の標準は、コレクタ段で精製・ドロップ・フィールド抽出を済ませ、cold storage を分離する形だ。

ストレージバックエンドは3方向に分かれる。

インシデント管理 — Alertmanager・PagerDuty・Opsgenie・Incident.io・FireHydrant・Squadcast

アラートが鳴ってからが本番である。2026年のインシデント管理ラインアップ。

Alertmanager ルーティングの典型構成。

# alertmanager.yml — severity ベースのルーティング
route:
  receiver: default
  group_by: [alertname, service]
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  routes:
    - matchers: [severity="page"]
      receiver: pagerduty-critical
      continue: true
    - matchers: [severity="ticket"]
      receiver: jira-ops
    - matchers: [service="checkout"]
      receiver: slack-checkout
receivers:
  - name: pagerduty-critical
    pagerduty_configs:
      - service_key: '$PAGERDUTY_KEY'
  - name: slack-checkout
    slack_configs:
      - api_url: '$SLACK_WEBHOOK'
        channel: '#checkout-alerts'

Slack ベースの ChatOps は2026年のすべてのツールで基本機能だ。インシデントチャネルの自動生成、ロール（IC、comms、scribe）の自動割当、ポストモーテムテンプレートの自動生成まで行う。

AI for Observability — Bits AI、Davis AI、NRAI

2025年にすべての主要 SaaS が LLM ベースのアシスタントをリリースした。

現実的な評価は「予測は誇大広告だったが、検索と要約は本当に時間を節約する」だ。RCA（根本原因分析）は依然として人間の仕事である。

韓国での実装 — PinPoint、Naver D2、Toss、Kakao

韓国の観測エコシステムは、OSS 貢献の面で意外なほど強い。

PinPoint は Java 陣営の「エージェント装着型 OSS APM」として依然として圧倒的で、MSA トランザクション可視化が強みだ。

日本での実装 — LINE Promgen、Mercari Datadog、GREE Elastic

日本のインターネット企業の観測スタックも深い。

LINE Engineering ブログと Mercari Engineering ブログは、日本語の観測関連一次資料として欠かせない。

SaaS と自前ホスティングの選択ガイド

この問いに普遍解はないが、パターンはある。

また データ主権 要件（EU の GDPR、韓国のクラウドセキュリティ認証、日本政府案件）が強い場合は、自前ホスティングが強制されることもある。

コスト管理チェックリスト

請求書爆発事故を避けるために、次の7つをチェックする。

  1. 高カーディナリティラベル禁止: user_id、request_id をメトリクスラベルに入れない。
  2. Adaptive sampling: エラーは100%、正常系は1〜5%。
  3. ログのティアリング: hot 7〜14日、warm 30〜90日、cold 1年以上。S3 Glacier を活用。
  4. ドロップルール: OTel Collector や Cribl で未使用シリーズ/ログを自動ドロップ。
  5. 明示的な TTL: すべてのデータ型に保持期間ポリシーを。
  6. 四半期ごとの請求書シミュレーション: トラフィック2倍時のコストを試算。
  7. カーディナリティアラート: 新しいラベルが追加されたら自動アラート。

2026年のオブザーバビリティ・トレンド5選

  1. OTel デフォルト: 新規プロジェクトは最初から OTel SDK で始める。
  2. eBPF ゼロインストルメンテーション: Beyla、Pixie が Java・Go・Python の RED メトリクスをコード変更なしで取れる。
  3. AI アシスタントの日常化: 自然言語からクエリへ、インシデント要約、ランブック生成。
  4. カーディナリティ SaaS の台頭: Chronosphere、Adaptive Metrics、Cribl の価値提案が明確に。
  5. OpenTelemetry Logs の GA: メトリクス・トレースに続き、ログシグナルが1.0安定化。1つの SDK で3シグナル全部。

References

原文を読む: https://www.youngju.dev/blog/culture/2026-05-16-observability-opentelemetry-datadog-grafana-honeycomb-prometheus-jaeger-ebpf-slo-2026-deep-dive.ja

コメント

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

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