はじめに — 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 は三つで構成される。

- **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方向ある。

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 コード生成までサポートする。

長所は明確だ。

- 統合の天国。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）: **R**ate・**E**rrors・**D**uration。リクエスト/レスポンス系サービスの標準。

- **USE**（Brendan Gregg）: **U**tilization・**S**aturation・**E**rrors。システムリソースの標準。

- **LETS**（Tammy Bryant）: **L**atency・**E**rrors・**T**raffic・**S**aturation。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つをチェックする。

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

- [OpenTelemetry 公式](https://opentelemetry.io/) — 標準仕様、SDK、Collector

- [Datadog](https://www.datadoghq.com/) — 統合 SaaS APM

- [Grafana](https://grafana.com/) — Loki/Mimir/Tempo/Pyroscope/Beyla

- [Honeycomb](https://www.honeycomb.io/) — wide events 観測

- [New Relic](https://newrelic.com/) — APM + Pixie + NRAI

- [Dynatrace](https://www.dynatrace.com/) — Davis AI、OneAgent

- [Splunk](https://www.splunk.com/) — Splunk Observability Cloud

- [Prometheus](https://prometheus.io/) — メトリクス標準

- [Jaeger](https://www.jaegertracing.io/) — 分散トレーシング OSS

- [Google SRE Book](https://sre.google/) — SLO/SLI の標準教科書

- [Google SRE — Embracing Risk](https://sre.google/sre-book/embracing-risk/) — エラーバジェットの原典

- [OpenTelemetry Community](https://github.com/open-telemetry/community) — ガバナンス

- [Chronosphere](https://chronosphere.io/) — カーディナリティ制御

- [Coralogix](https://coralogix.com/) — ログ分析 SaaS

- [Sentry](https://sentry.io/) — エラートラッキング + パフォーマンス