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

はじめに — 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年には、さらに二つが一級市民になった。

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

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

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

OTel は三つで構成される。

API/SDK: GA 言語11個（Java、Go、Python、.NET、JS、Ruby、Rust、C++、PHP、Erlang、Swift）+ ベータ群。
Collector: 収集・変換・転送のためのプラガブルなルーター。Agent モードと Gateway モードがある。
Semantic Conventions: 属性名の取り決め（http.request.method、db.system、k8s.pod.name など）。2024年に 1.0 GA、2026年は 1.30 系まで進行中。

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 にはカーディナリティと保持期間の限界があるので、通常は 長期保存バックエンド とセットで使う。

Grafana Mimir（旧 Cortex）: マルチテナント、S3 バックエンド、PromQL/MQL 互換、Grafana Labs OSS。
Thanos: sidecar + global query + S3、コミュニティ標準。
Cortex: Mimir 分裂前の本家、現在も維持されている。
VictoriaMetrics: 高圧縮率と単一バイナリ配布が強み。2026年も OSS モメンタムは強い。
Chronosphere: カーディナリティ制御がコア価値提案。M3DB 出身のチーム。

典型的な 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方向ある。

高カーディナリティはトレース/ログへ: メトリクスのラベルではなくイベント属性として保存する（Honeycomb の哲学）。
Adaptive sampling + ドロップルール: OTel Collector の transformprocessor や Datadog の Metric Pipelines で未使用ラベルを自動ドロップ。
カーディナリティ制御 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 コード生成までサポートする。

長所は明確だ。

統合の天国。Kubernetes、Lambda、Postgres、Kafka、Stripe をワンクリックで接続。
強力な UI/UX と高速なクエリ。p99 もインデックスフレンドリー。
Watchdog の AI/ML 異常検知が本当に機能する。
LLM Observability（2025年 GA）: プロンプト、トークン、モデル別コストの集計。

短所も明確だ。

高い。ホスト1台あたり月23〜40ドル + インデックス済みログ + カスタムメトリクス + RUM セッション。四半期ごとに請求書シミュレーションをしないと痛い目を見る。
ロックイン。DD agent + DogStatsD から OTel への乗り換えは、1〜2四半期かかる作業になる。

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 が基本単位で、すべてのクエリでどの次元もアドホックにグルーピング/フィルタできる。カーディナリティ制限はない。

BubbleUp: 「この異常な低速トレース群と正常群との差分」を次元ごとに自動比較して見せる。2026年最も真似されている UX パターン。
SLOs: エラーバジェットを一級市民として扱う。バーンレートアラートは単純な閾値より賢い。
OpenTelemetry-native: 当初から OTLP フレンドリー。2024年に Refinery（サンプリングゲートウェイ）も OSS 化した。

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

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

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

Jaeger: Uber 発、CNCF Graduated。2024年に v2 が OTel Collector の上で動くディストリビューションとして再出発。ClickHouse、Cassandra、Elasticsearch のストレージに対応。
Tempo: Grafana Labs、オブジェクトストレージ親和。インデックスを最小化してトレース ID 検索だけにする設計でコスト効率が高い。TraceQL が強み。
Zipkin: Twitter 発、2012年から運用。シンプルさが武器。新規採用よりレガシー互換用途。

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

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

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

Pixie（New Relic 買収）: K8s クラスタに DaemonSet を1つ入れれば、HTTP/gRPC/DNS/MySQL トラフィックが自動で取れる。PxL というスクリプト言語。
Cilium Tetragon: セキュリティと観測の統合。syscall + ポリシー + トレースを単一データモデルへ。
Grafana Beyla: 上で紹介した自動計装ツール。Cilium Hubble とも連動する。
Parca: クラスタ全体の継続的プロファイリング。CPU プロファイルを pprof 形式で常時収集。
Coroot: SaaS と OSS のデュアル。eBPF ベースのサービスマップと SLO 自動生成。
Polar Signals: Parca ベースの SaaS。継続的プロファイリングの New Relic。

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

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

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

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

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

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

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

Pyroscope（Grafana Labs 買収）: Go、Python、Java、Ruby、Node.js に対応。フレームグラフ比較 UX が強み。
Parca: Polar Signals OSS。eBPF ベースなので、言語を問わずゼロコンフィグでプロファイルが取れる。
Polar Signals: Parca の SaaS 版。クラスタ全体のコスト削減分析。
Datadog Continuous Profiler: 1年以上前から production-grade。ASP.NET、JVM、Go、Python に対応。
AWS CodeGuru Profiler: Java/Python 限定の AWS ネイティブ。

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

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

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

Datadog RUM: 自動セッションリプレイ、INP/LCP/CLS の収集、OTel RUM 互換。
New Relic Browser: APM と統合。分散トレースをブラウザまで延ばす。
Sentry（元はエラートラッキング → 観測に進化）: JS とモバイル RUM、リプレイ、パフォーマンス。
Grafana Faro（2024年 GA）: OSS RUM SDK + Loki/Tempo で自前ホスティング可能。
SpeedCurve、Calibre: Core Web Vitals 専門 SaaS。
Synthetic: Catchpoint、Checkly、Datadog Synthetic、k6 Cloud（Grafana）。Playwright ベースの Checkly が新規採用の先頭を走る。

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

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

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

Nobl9: マルチデータソース（Datadog、Prometheus、NR）の SLO 統合。2025年に BSD ベースの OSS コアを公開。
Datadog SLO: ネイティブ統合、自動でバーンレート通知。
Grafana Cloud SLO: Mimir/Loki/Tempo の上で動作。
OpenSLO: 仕様。YAML で SLO を宣言的に定義し、ツール間で持ち運ぶ。
Sloth: PromQL の SLO ルールジェネレータ。Prometheus 単体で 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つに整理できる。

RED（Tom Wilkie）: Rate・Errors・Duration。リクエスト/レスポンス系サービスの標準。
USE（Brendan Gregg）: Utilization・Saturation・Errors。システムリソースの標準。
LETS（Tammy Bryant）: Latency・Errors・Traffic・Saturation。Honeycomb 流の派生。
Google Four Golden Signals: Latency・Traffic・Errors・Saturation。SRE 本の標準。

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

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

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

traceparent ヘッダー: 00 ハイフン trace-id ハイフン parent-id ハイフン flags
tracestate ヘッダー: ベンダー拡張
baggage ヘッダー: ユーザ定義のコンテキスト（user_id、tenant_id など）

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 を分離する形だ。

Vector（Datadog 製 OSS）: Rust ベース、スループットとメモリで業界トップ。VRL という変換言語。
Fluent Bit: CNCF Graduated。軽量な K8s サイドカーのデファクト。Lua と Wasm のフィルタ。
Fluentd: Fluent Bit の親。ノードエージェントとして今も多く使われる。
Logstash: Elastic 陣営の ETL。重いが grok パターンが豊富。
OTel Collector: ログの receiver/exporter も GA。メトリクス・トレースと同じパイプラインに収まる。

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

Elasticsearch / OpenSearch: フルテキスト検索と集計が強い。Elastic Observability の完成度は高い。
Loki: ラベルだけインデックスし、本文は圧縮チャンク。コスト効率は最高だがフルテキスト検索は弱い。
ClickHouse: カラムストア。Cloudflare、Uber、Discord が自前運用。コストと速度は優秀だが運用負荷あり。
Splunk: 老舗の絶対王者、検索言語（SPL）が強力。請求額が最も高いことで有名。

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

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

PagerDuty: 2009年からのカテゴリ定義者。2024年に PagerDuty Operations Cloud としてリブランド。
Opsgenie（Atlassian）: Jira・Confluence・Statuspage 統合が強み。2026年は新規採用が減り、PagerDuty や Incident.io への移行が進む。
Incident.io: 2021年創業の英国スタートアップ、Slack ネイティブのインシデント管理。2024年に on-call を追加して PagerDuty 代替の座を獲得。
FireHydrant: 米国発のインシデント管理とランブック。Slack ワークフロー自動化が強い。
Squadcast: インド/SF 発、コスパの良い on-call とインシデント管理。
Rootly: Slack ネイティブ、ステータスページ統合。
Grafana OnCall（2023年 GA、Apache 2.0）: OSS 代替。PagerDuty を捨てたいチーム向け。
Alertmanager: Prometheus 陣営の標準。ルーティング、グルーピング、サイレンシング。

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 ベースのアシスタントをリリースした。

Datadog Bits AI: 自然言語によるトレース/ログ分析、インシデント要約、IaC コード生成、ランブック自動化。
New Relic AI（NRAI）: クエリ生成、異常検知の説明、エラークラスタリング。
Dynatrace Davis AI: 2017年からの因果分析エンジン。2025年に LLM 連携の Davis CoPilot を投入。
Honeycomb Query Assistant: 自然言語から BubbleUp クエリへ。
Grafana ML / LLM: 異常検知と自然言語ダッシュボード生成。
Splunk AI Assistant for SPL: 自然言語から SPL への変換。

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

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

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

Naver PinPoint（2015年 OSS 化）: Java APM、Apache 2.0。Java/PHP/Python/Go のエージェントを持つ。2026年も活発にメンテされている。
Naver D2 メトリクス文化: 検索や LINE 時代からのメトリクス運用ノウハウ。ELK ベースのログ分析ガイドが公開されている。
Toss SRE: 自前の OTel + Grafana Stack + Pyroscope。Toss 公式ブログに運用事例が多い。
Kakao: 自前モニタリング KAMS から Datadog・Grafana ハイブリッドへ。tech.kakao.com にトレース・メトリクス関連の投稿が多い。
NHN: NHN Cloud 内の自前監視サービス Watch。PinPoint と互換。
Coupang: Datadog の大型顧客。韓国最大級の利用事例。
Karrot (Daangn): Datadog + Sentry。モバイル RUM 中心。

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

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

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

LINE Promgen / Promscale: LINE 製の Prometheus 運用自動化ツール、2018年 OSS 化。数万ターゲットを管理する。
Mercari: 2017年からの Datadog 大口顧客。SRE ブログに KPI 運用や Bits AI 導入記が多数。
GREE: ゲームインフラで Elastic Stack（ELK + APM）を運用。
DeNA: AWS + Datadog + 自前監視。Pococha などリアルタイムサービスの観測知見を公開。
CyberAgent / AbemaTV: Datadog と New Relic を併用。AbemaTV はライブストリーミング観測の事例を公開。
Rakuten: 多目的マイクロサービスを抱え、自前 + New Relic + Datadog のハイブリッド。
SmartHR / freee: 新興 SaaS、Datadog + Sentry が標準。

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

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

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

年間観測費が100万ドル未満: SaaS が圧倒的に安い。人件費と機会費用まで入れると、自前ホスティングは大抵損になる。
年間費用が100万〜500万ドル: 損益分岐点。多くはSaaS + 一部自前（ログの cold tier など）。
年間費用が500万ドル超: 自前ホスティングが正当化される。ClickHouse + Tempo + Mimir + Pyroscope + Beyla のフルスタックを整えるチームが増えている。

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

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

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

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

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

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

References

OpenTelemetry 公式 — 標準仕様、SDK、Collector
Datadog — 統合 SaaS APM
Grafana — Loki/Mimir/Tempo/Pyroscope/Beyla
Honeycomb — wide events 観測
New Relic — APM + Pixie + NRAI
Dynatrace — Davis AI、OneAgent
Splunk — Splunk Observability Cloud
Prometheus — メトリクス標準
Jaeger — 分散トレーシング OSS
Google SRE Book — SLO/SLI の標準教科書
Google SRE — Embracing Risk — エラーバジェットの原典
OpenTelemetry Community — ガバナンス
Chronosphere — カーディナリティ制御
Coralogix — ログ分析 SaaS
Sentry — エラートラッキング + パフォーマンス