OSS監視スタック2026深掘り — SigNoz・Coroot・OpenObserve・Sentry・Grafana・UptraceでDatadogを置き換える

プロローグ — Datadog請求書、そしてその後

2025年、シリーズBスタートアップの四半期レビュー議事録から一行。「先月のDatadog請求は14万ドルでした」。CTOがノートPCを向け直すと部屋は静まり返った。売上の7%だ。インデックス済みログが半分、カスタムメトリクスが30%、APMホストが残り。次の四半期で90%削減することがOKRになった。

この光景は2024年からシリーズB以上のSaaS企業で四半期ごとに繰り返されている。一方にDatadog・New Relic・Splunkで構成されるSaaSマトリクスがあり、もう一方にはOpenTelemetry標準化で参入障壁を崩したOSS可観測性がある。2026年の答えはもう「どちらか一つを選ぶ」ではない。モジュラーなOSSスタックで核心を取りに行き、本当に価値の高い場所だけSaaSを残す。

この記事は2026年5月時点のOSSモニタリング風景の正直な地図だ。

SigNoz — OpenTelemetryネイティブ、ClickHouse保存、トレース・メトリクス・ログ・例外を統合。「本物のDatadog代替」と呼ぶに足る初のOSS。
Coroot — eBPFベースの計装ゼロAPM。一行も書き換えずにサービストポロジとSLOダッシュボードが出る。
OpenObserve — Rustで書かれた次世代ログ・トレース・メトリクス。S3 + Parquetバックエンドでペタバイト規模を5〜30%のコストに。
Sentry self-hosted — エラートラッキングのキャノン。Sentry SaaSの価格が重ければ依然として最初の答え。
Uptrace — 軽量ClickHouseベースAPM。単一ノードでOpenTelemetryを始める最良の選択肢。
Grafanaスタック — Loki・Tempo・Mimir・Pyroscope・k6・Beyla・Alloy。依然として最大規模のOSS可観測性エコシステム。

各ツールがどこで光るのか、ストレージバックエンドがなぜ決定的なのか、OpenTelemetry標準化が何を恒久的に変えたのか、そしてセルフホストの本当のコストまで — 幻想なしに見ていく。

1章 · OpenTelemetry — すべてを変えた標準

2026年にOSS可観測性が本当に脅威となった唯一の理由はOpenTelemetry(OTel)だ。それ以前はあらゆるSaaSが独自エージェントを強制し、コードはそのエージェントに閉じ込められた。一度Datadog APMに紐づくと、抜け出すこと自体がコードリファクタリングだった。

OTelが変えたもの:

計装がベンダー中立になった。OTLP/gRPCでメトリクス・トレース・ログを一つのフォーマットで送り出せば、受け手はSigNozでもDatadogでもGrafanaでも構わない。
セマンティック規約が標準化された。http.request.method、db.system、messaging.destination.nameのような名前があらゆるツールで同じ意味を持つ。
自動計装ライブラリが成熟した。Python・Node・Java・Go・.NET・Rubyすべてでzero-code instrumentationが可能。
OpenTelemetry Collectorが事実上のルータ・フィルタ・集約器として定着した。送り先を変えてもアプリは変えない。

2024年にOTelはCNCF Graduatedプロジェクトとなり、2025年にはログシグナルがGAになった。2026年現在、トレース・メトリクス・ログ・例外がすべて安定段階だ。プロファイリングはOTel Profilesとしてベータに突入している。

要点を一言: OTelさえきちんと敷けば、バックエンドは差し替え可能なオプションになる。これがすべてのOSSツールが同時に生き延びている理由だ。

2章 · 2026年OSS可観測性ランドスケープ俯瞰

まず比較マトリクス。横長なので横に開いて見てほしい。

ツール	主シグナル	ストレージバックエンド	強み	弱み	ライセンス	適合規模
SigNoz	トレース・メトリクス・ログ・例外	ClickHouse	OTelネイティブ・統合UI	ClickHouse運用負荷	MIT + 一部Enterprise	中〜大
Coroot	メトリクス・トレース(eBPF)	Prometheus・ClickHouse	計装ゼロ・自動トポロジ	Windows非対応	Apache 2.0 + Enterprise	中規模K8s
OpenObserve	ログ・トレース・メトリクス	S3 + Parquet	ストレージ5〜30%	UI新興・互換性一部不足	AGPL-3.0	大規模ログ
Sentry self-hosted	例外・セッション・トレース	PostgreSQL・ClickHouse	エラーUX圧倒的	self-host方針変動リスク	FSL/BSL	全規模
Uptrace	トレース・メトリクス・ログ	ClickHouse	単一ノード起動容易	コミュニティ小	AGPL-3.0	小・中規模
Grafanaスタック	5分離	それぞれ別	最大エコ・LGTM	5ツール統合負担	AGPL-3.0	全規模

この表の本当の軸はストレージバックエンドだ。ClickHouseは圧縮率とクエリ速度、S3 + Parquetは低コスト長期保管、Prometheus TSDBはメトリクス特化。三者のトレードオフは後で再度見る。

3章 · SigNoz — 本物のDatadog代替

SigNozは2021年にOTelネイティブのAPM・ログ・メトリクス統合ツールとして始まった。2026年現在で4万GitHubスター、SOC 2 Type II認証、シリーズAの後続ラウンドまで完了済み。セルフホストは無料(Community Edition)、SaaSはGB・CPU・ホスト課金。

技術スタック:

計装 — OTel SDKそのまま。専用エージェントなし。
収集 — OpenTelemetry Collectorフルスタック、または直接OTLP。
保存 — ClickHouse(必須)。トレース・メトリクス・ログが同一DB。
クエリ — SigNoz UI + PromQL + ClickHouse SQL。
アラート — Grafana流ルールまたは独自UI。

なぜClickHouseか。OLAPカラム型DBは可観測性に自然にフィットする。トレース一行は通常30〜80の属性を持ち、ほぼ全てのクエリが「条件 + 集計」だ。カラム型は必要なカラムだけ読み、LZ4圧縮率は平均8〜12倍なのでストレージコストも低い。ClickHouse本体は分間数億行の取り込みを処理する。

中核となる差別化:

単一UIでトレース・メトリクス・ログをジャンプ — 同じtrace_idが3シグナルすべてに刻まれている。ワンクリックで移動。
Exceptionシグナル — Sentryのように例外だけを分離してグルーピング・集計。
PromQL + ClickHouse SQL — Grafanaユーザーにも親しみやすく、深い分析にはSQL。
テールベースサンプリング標準搭載 — エラー・遅いトレースだけ残すのが既定機能。

docker-compose一発起動:

git clone -b main https://github.com/SigNoz/signoz.git
cd signoz/deploy
./install.sh
# ブラウザ http://localhost:3301

KubernetesはHelmチャートで:

helm repo add signoz https://charts.signoz.io
helm install signoz signoz/signoz \
  --namespace platform \
  --create-namespace \
  --set otelCollector.replicaCount=3 \
  --set clickhouse.persistence.size=500Gi

サイジングガイド:

トレースRPS 1万未満 — 単一ClickHouseノードで可能。16 vCPU / 64 GB / 1 TB NVMe。
RPS 1万〜10万 — 3ノードClickHouseクラスタ、ZooKeeperまたはClickHouse Keeper。
RPS 10万以上 — 専任SREチーム必須。この時点でDatadogコストとセルフホスト人件費を再比較すべき。

運用上の罠:

ClickHouseのディスク圧迫はサイレントキラー。TTLポリシーを正確に設定(既定はトレース7日、メトリクス30日、ログ14日)。
OTel Collectorを一段で吊るすと単一障害点。DaemonSet + Gatewayパターンで分離。
カーディナリティ爆発。user_id、request_idをラベルに刺さない。属性として持つ。

4章 · Coroot — eBPFで計装ゼロAPM

Corootの目的は一行も書き換えずにAPMを始めることだ。eBPFでカーネルレベルからTCP接続をフックし、HTTP/gRPC/DBトラフィックを自動分類する。コードにSDKを挿す時間がない、あるいは挿す権限がない環境(レガシーJava・インハウスPHP・Node)に魅力的だ。

中核アーキテクチャ:

coroot-node-agent — DaemonSetで全ノードにeBPFプローブ。
coroot-cluster-agent — Kubernetesメタデータ収集。
coroot — UI + ルールエンジン。Prometheusメトリクス + ClickHouseトレース + 独自インベントリ。

eBPFが捕えるもの:

サービストポロジ — 自動。
SLO・SLI推定 — レスポンスタイム・エラー率を自動算出。
DB・メッセージキュー呼び出し — Postgres・MySQL・Redis・Kafkaプロトコルをデコード。
コンテナ単位のCPU・メモリ — cgroupベース。
ノードのネットワーク損失・再送 — TCP統計。

eBPFが捕えないもの:

ビジネスコンテキスト(注文ID・決済金額のようなドメイン属性)
関数単位のトレース(コード内部の呼び出しグラフ)
Windows(eBPFはLinuxカーネル機能)
TLS終端後の平文HTTP — uprobeでSSLライブラリをフックする必要がある(Coroot部分対応)

2026年のCorootライセンスは二系統。コアはApache 2.0 OSS、AIベースRCA(Root Cause Analysis)とSSO・RBACはEnterprise。無料セルフホストで80%は十分カバーできる。

Kubernetesインストール:

helm repo add coroot https://coroot.github.io/helm-charts
helm install coroot coroot/coroot \
  --namespace coroot \
  --create-namespace \
  --set clickhouse.shards=1 \
  --set prometheus.retention=15d

UIを一度起動すると「自分のクラスタにこんなものが走っていたのか」が初めて見える。それがCorootの本当の価値だ。計装ゼロ + 即時可視性。

組み合わせて使うと良いパターン: Corootで自動ベースライン、その上にSigNoz・Sentryでビジネスコンテキストが必要な箇所だけ手動計装。

5章 · OpenObserve — RustとS3でペタバイトを5%のコストに

OpenObserveは2023年登場のRustベースログ・トレース・メトリクスプラットフォーム。2026年現在でGitHubスター1.6万、シリーズA調達済み、AGPL-3.0ライセンス。最大の武器はストレージコスト。

ベンチを一言。同量のログをElasticsearch比で140倍少ないストレージ、Splunk比で140分の1の運用コスト。どうやって? S3 + Parquet + インデックスレスのフルテキスト検索。

伝統的なログシステム(Elasticsearch・Splunk)は:

全フィールドをインデックス化 — ディスクが爆発。
インデックスをメモリにキャッシュ — 高価なインスタンスが必須。
ローカルディスクに保存 — 長期保管用コールドストレージを別途持つ必要。

OpenObserveの違うアプローチ:

インデックスレス。ログをParquetに圧縮し、直接S3に積む。
インメモリ・ブルームフィルターで一次フィルタ、カラムスキャンで実際のマッチ。
S3自体が事実上無限 + 安価 + 11ナインの耐久性。コールド/ホット分離が自動。

トレードオフ:

インデックスがないので「全ログからXを探す」はElasticsearchより遅いことがある。
だが時間範囲 + 1〜2フィールド絞り込みは速い(実際の90%のクエリパターン)。
フルテキストはブルームフィルター + Parquet統計で大半をカバーできる。

2026年時点でOpenObserveは以下を対応:

ログ — JSON・Syslog・Fluentbit・OTLP。
トレース — OTLP/gRPC + Jaeger互換。
メトリクス — Prometheus Remote Write + OTLP。
アラート・ダッシュボード — 独自UI。
マルチテナンシー・SSO・RBAC — Enterprise。

dockerワンライナー:

docker run -d \
  -v $PWD/data:/data \
  -p 5080:5080 \
  -e ZO_ROOT_USER_EMAIL=admin@example.com \
  -e ZO_ROOT_USER_PASSWORD=admin \
  public.ecr.aws/zinclabs/openobserve:latest

Kubernetes + S3モード:

# values.yaml (Helm)
config:
  ZO_S3_BUCKET_NAME: my-o2-logs
  ZO_S3_REGION_NAME: ap-northeast-1
  ZO_DATA_STREAM_TYPE: s3
ingester:
  replicaCount: 3
querier:
  replicaCount: 2

ペタバイトスケールでログが核心の会社(セキュリティ・フィンテック・ゲーム)にはOpenObserveが本当の答えになる。Loki + S3と比べてもOpenObserveの単一ツール統合は運用負荷をさらに下げる。

6章 · Sentry self-hosted — 依然エラーのキャノン、しかし方針が揺らいだ

Sentryは2008年からエラートラッキングの事実上の標準だった。セルフホストも長く無料だった。だが2024年から流れが変わった。

2023年にFSL(Functional Source License)へ転換。2年後にApache 2.0へ自動転換されるBSL派生。
2024年から一部の新機能(Replay・Crons)はSaaS優先、OSS遅延リリース。
2025年にself-hostパッケージがさらに重くなる(50 GBディスク、多数のコンポーネント)。
Sentry公式見解「self-hostは継続維持、ただしSaaS優先の開発ペースは加速する」。

2026年5月現在、self-hostは生きている。毎月リリースがあり、コア機能(Error・Performance・Profiling・Crons)はすべて入っている。ただし運用負担は決して軽くない。

self-host構成要素:

Snuba — ClickHouseの上のクエリ層
Relay — イベント収集・フィルタゲートウェイ
Kafka — イベントキュー
Redis — キャッシュ・レートリミット
PostgreSQL — メタデータ
Sentry本体 — Django + Celery
Symbolicator — ソースマップ・シンボル解決

全部合わせて8〜12コンテナ、50 GBディスクがスタートライン。単一ノードで日次100万イベントまでは無理なく回る。それ以上はKafka・ClickHouseの分離が始まる。

インストール:

git clone https://github.com/getsentry/self-hosted.git
cd self-hosted
./install.sh
# .envでSENTRY_EVENT_RETENTION_DAYS=90のようなオプションを調整

3つのシナリオ:

純粋なエラートラッキング — Sentry self-hostが圧倒。グルーピング・トレンド・リリース比較が同等のOSSにない。
エラー + フルスタック可観測性 — SigNozが統合で優位。Sentryの例外はSigNozでも1級シグナル。
エラー + コスト圧力大 — Sentry SaaSのDeveloper/Team価格が痛ければself-hostが答え。

よくある質問: 「SentryはOTel互換か?」部分的にYES。OTelトレースをSentryに送れる(Performanceシグナル)が、エラーは依然としてSentry SDKが標準だ。2026年からOTel Exceptionシグナルとのグルーピング統合作業が進行中。

7章 · Uptrace — 軽量ClickHouse APM

UptraceはSigNozと同じClickHouseベースOTel APMだが、単一ノードで軽く始めることが美点だ。AGPL-3.0、セルフホスト無料、SaaSは別途課金。

SigNozとの違い:

単一バイナリで起動可能 — dockerもワンコンテナ。
ClickHouse 1ノードで十分 — 日次5,000万スパンまで無理なく対応。
UIがよりシンプル — トレース中心、メトリクスは補助。

いつUptraceを選ぶか:

チームが小さく、セルフホスト要員1名でも厳しいとき。
ClickHouseは初めてだが一度敷いてみたいとき。
トレース一種だけを深く見たいとき。

いつSigNozへ向かうか:

トレース + メトリクス + ログ + 例外をすべて統合で見たいとき。
チームが大きくなりClickHouseクラスタ運用を受け入れられるとき。

dockerワンライナー:

docker run -d --name uptrace \
  -p 14317:14317 -p 14318:14318 \
  -v $PWD/uptrace.yml:/etc/uptrace/uptrace.yml \
  uptrace/uptrace:latest

UptraceはOTel Collectorを内包する構成も提供する(Standaloneモード)。OTel初心者チームにとって「最も参入障壁の低いオプション」だ。

8章 · Grafanaスタック — 最大のエコ、最もモジュラーな選択

Grafana Labsが2017年から積み上げてきたスタックは2026年OSS可観測性最大の単一陣営だ。ツール別に見ると:

Prometheus — メトリクスの事実上の標準。2024年OTLP受信対応でOTel互換完成。
Mimir — Prometheusの水平拡張バックエンド。マルチテナント、S3保存。
Loki — ログ。「ラベルだけインデックス」哲学でストレージコスト低め。
Tempo — 分散トレース。S3・GCS・MinIO保存可能。
Pyroscope — コンティニュアスプロファイリング。eBPF + 言語別SDK。
Grafana — ダッシュボードの標準。LGTMデータを一画面に。
Alloy — OpenTelemetry Collector配布版。2024年Grafana Agentの後継。
Beyla — eBPF自動計装。Corootより軽量、単一サービス単位。
k6 — 負荷試験。可観測性シグナルと自然に連結。

長所:

各ツールが一分野を深く。可観測性人材がいるチームに有利。
連合運用が可能。Mimirはここ、Tempoはここ、Lokiはあちらと責務分散。
Grafanaダッシュボードのエコシステムが巨大。どのツールでも描くのが慣れている。

短所:

5ツールを運用する。単一統合UIはGrafanaだがバックエンドは別。
始動が重い。docker-compose一つでは終わらない。
アラート・ルールがツールごとに違う。標準化が必要。

いつGrafanaスタックか:

既にPrometheusを使っており自然に拡張するケース。
可観測性専任SREチームがいるケース。
マルチテナント・連合クラスタ要件があるケース。

いつSigNoz・Uptraceの方が良いか:

統合UIひとつで全部見たいとき。
運用人材が足りないとき。
初めて始めるチーム。

Grafana Cloudの無料枠がかなり潤沢で「セルフホスト vs Grafana Cloud」比較は常に並行で見る。2026年の無料枠はメトリクス10kシリーズ、ログ50 GB、トレース50 GB、14日保存。

9章 · ストレージバックエンド — 本当の決定

ツール選択の8割はバックエンド選択だ。3つのパターンが市場を二分する。

9.1 ClickHouse — カラム型OLAP

使う場所: SigNoz、Uptrace、Sentry(Snuba)、Coroot(トレース)。

長所:

圧縮率8〜12倍。ディスクコスト低。
分間数億行の取り込み。
カラムスキャンで絞り込みクエリが高速。
SQLそのまま使える。

短所:

運用難易度高。バックアップ・レプリカ・キーパーすべてに学習が必要。
マージ・ミューテーションのコスト。頻繁な更新には不向き。
カーディナリティ爆発に脆弱。ラベル設計を誤るとディスク暴走。

9.2 S3 + Parquet — インデックスレス・オブジェクトストレージ

使う場所: OpenObserve、Tempo、Loki(ブロック)、Mimir(ブロック)。

長所:

事実上無限 + 11ナインの耐久性 + 安価。
コールドストレージが自動。ホット/コールド階層化オプション。
コンピュート分離 — クエリノードだけ増やせる。

短所:

ローカルディスクより遅い。キャッシュ層必須。
クエリパターンが時間 + 狭いフィールドに限られるとき効率的。
重いフルテキスト分析に弱い。

9.3 Prometheus TSDB — 時系列専用

使う場所: Prometheus、Mimir、Cortex、VictoriaMetrics。

長所:

メトリクスに圧倒的に最適化。ディスク少、クエリ高速。
PromQLエコシステムが標準。
運用が単純(単一ノード基準)。

短所:

トレース・ログには合わない。時系列のみ。
水平拡張はMimir・Thanosのような別ツールが必要。

組み合わせガイド:

メトリクスが80% — Prometheus + Mimir。
ログが80% — OpenObserveまたはLoki + S3。
トレースが80% — SigNoz・Uptrace + ClickHouse、またはTempo + S3。
3つともバランス — SigNoz単体。

10章 · Datadog → SigNoz実際の移行事例

2025年末、5万ホスト規模のSaaSの移行ノートを再構成した。

10.1 開始時点

月次請求14万ドル(APM 8万、ログ4万、メトリクス2万)。
Java・Go・Nodeバックエンド80サービス。
Datadog Agentによる自動計装。
カーディナリティ暴走でカスタムメトリクスが毎月12%増。

10.2 段階的移行

Phase 1 — 計装抽象化(4週)

OTel SDKへ移行。コード変更を最小化するため自動計装ライブラリ優先。一部のビジネス属性のみ手動追加。

Phase 2 — デュアルバックエンド(6週)

OTel CollectorからDatadog・SigNoz両方へ同時送信。SigNozはdev・staging先行、1週ずつ本番サービスの一部に適用。データ整合性を検証。

Phase 3 — SLO検証(4週)

中核アラート・ダッシュボードをSigNozで再構築。レスポンスタイム・エラー率SLOがDatadog Monitorと同じ挙動かを確認。on-callがSigNoz UIに慣れる時間。

Phase 4 — Datadog除去(2週)

サービス単位で段階遮断。最後にDatadog Agentを除去。

10.3 結果

月次請求14万 → SigNozインフラ1.2万 + SRE負担増 → 正味コスト90%削減。
トレース保存30日 → 15日に短縮(必要性再検討の結果十分)。
カーディナリティポリシーでカスタムメトリクス50%削減。
on-call MTTRは変化なし。

10.4 後悔項目

デュアル運用期間が短すぎた。8週推奨。
ログ移行を同時に進めるべきだった。別にしたらコンテキストが切れた。
ClickHouseディスク監視を最初に忘れ、ディスクフル事故を一度起こした。

11章 · セルフホストの本当のコスト

「OSSなら無料」は嘘だ。正直なコストモデルはこうだ。

インフラ: ClickHouse・S3・Prometheusノード、バックアップ、マルチAZ。月1万〜5万ドル規模(50〜500ホスト基準)。
人件費: SRE 0.3〜1名フルタイム。年5万〜15万ドル。
ダウンタイムリスク: 可観測性そのものが死ぬとトラブルシュートが止まる。HA設計必須。
学習曲線: ClickHouse・Kafka・S3ライフサイクル、OTel Collectorチューニング、保存ポリシー。最初の6か月は試行錯誤。

いつセルフホストが勝つか:

月額3万ドル以上で、
SREがいて、
データを外に出せないコンプライアンス事情があり、
カーディナリティ・保存ポリシーを自分でコントロールしたいとき。

いつSaaSが勝つか:

小規模チームでSREがいない。
月額5,000ドル以下。
セキュリティ・コンプライアンスがSaaSを止めない。
すぐ始める価値の方が大きい。

中間の選択肢: Grafana CloudまたはSigNoz Cloud。OSSのバックエンドをマネージドで受け取る。請求書がDatadogの30〜50%でありながら運用負担がゼロ。

12章 · アンチパターン集

長い時間で蓄積された罠。

**「可観測性 = ログ」**との誤認 — ログだけ積むとトレース・メトリクスがなく因果追跡不能。
カーディナリティ爆発 — user_id、request_idをラベルに刺した瞬間に終わり。属性に。
サンプリングなしのフルスロットル — トラフィック1万RPSでトレース100%保存? ディスクが爆発する。テールベースサンプリングでエラー・遅いものだけ。
アラート爆撃 — 一人に時間あたり30アラートはすぐに無視される。SLOベースアラートで意味のあるものだけ。
単一OTel Collector — 単一障害点。DaemonSet + Gatewayの二段構成。
TTL未設定 — ディスクが満杯になって初めて気付く。セルフホストの初週に必ず。
ダッシュボード200個 — 誰も見ない。5つのゴールデンダッシュボード + 自動アラートの方が効果的。
開発者の計装義務化なしでツールだけ展開 — ツールは敷かれたのにデータがない。計装ゲート + CI検証必須。
OTelセマンティック規約無視 — 自分で作ったキー名は1週間後には自分でも見つけられない。標準規約に従う。
バックエンド1か所に全部 — ClickHouseが落ちるとSigNoz・Sentry・Uptraceが同時死。分離。

13章 · 導入意思決定フローチャート

質問に順に答える。

現在の月額可観測性コストは? 1万ドル未満なら → SaaS継続。
SREまたは可観測性担当はいるか? いなければ → SaaSまたはマネージド(Grafana Cloud・SigNoz Cloud)。
コンプライアンスで外部送信禁止か? Yesなら → セルフホスト決定。
主シグナルは何か?
- トレース + メトリクス + ログ統合 → SigNoz。
- ログが支配的 → OpenObserveまたはLoki。
- eBPFで計装ゼロから始める → Coroot。
- エラートラッキングが核心 → Sentry self-host。
- 軽量単一ノード → Uptrace。
- モジュラー運用 → Grafanaスタック。
今後3年の規模予測は? ペタバイトログ見込み → OpenObserve・Loki。それ以下 → SigNoz。

14章 · 2026年以降の風向き

OSS可観測性はどこへ向かっているか。

OTel Profiles GA — 2025年ベータ、2026年後半GA見込み。コンティニュアスプロファイリングが4つ目のシグナルに。
AIベースRCA — Coroot・SigNoz・Grafanaいずれも独自RCA機能をOSSとEnterpriseで分けてリリース中。LLMがインシデント初動の仮説を投げるのが標準になる見込み。
eBPF普及 — Beyla・Coroot以外にもより多くのツールがeBPFベース自動計装を採用する。
ストレージ分離・連合標準化 — Iceberg・Parquetベースの共通フォーマットがツール別ロックインを解いていく流れ。
カーディナリティ課金の終わり — Datadog・New Relicもラベルカーディナリティベース課金からの後退圧力。OSSの自由さが課金モデル自体を圧迫している。

3年後の予測一行: OTel + S3-Parquet + ClickHouse + eBPFの組み合わせがOSS可観測性の事実上の基本スタックとなる。Datadog・New Relicは依然存在するが、市場シェアは30〜40%台まで落ちる可能性が高い。

エピローグ — セルフホストは権利であり、責任である

古い真理: 可観測性は保険ではなく製品だ。その製品のバックエンドをSaaSに任せるのも正当な選択で、自分で運用するのも正当な選択だ。ただし両方にコストがかかる。SaaSは請求書として、セルフホストは時間とSRE人件費として。

2026年が興味深い理由は選択肢が本当に増えたことだ。OpenTelemetryがベンダーロックインを破り、ClickHouse・S3-Parquetがストレージコスト曲線を引き下げ、eBPFが計装労力をゼロに収束させた。結果として一つのツールがすべてをうまくこなす時代は終わり、複数ツールをモジュラーに組み合わせる時代になった。

14.1 導入チェックリスト

14.2 アンチパターン要約

可観測性 = ログと勘違いする。
カーディナリティ爆発を無視。
サンプリングなし100%保存。
アラート爆撃で信頼を失う。
単一OTel Collectorで運用。
TTLを設定しない。
ダッシュボード200個。
計装義務化なしでツールだけ展開。
セマンティック規約を無視。
バックエンド1か所に全集中。

14.3 次回予告

次回はOTel Collectorの深掘りを扱う。DaemonSet vs Gateway、プロセッサ・フィルタ・ルータ構成、テールベースサンプリングの実装、Kafkaバッキング・リトライ・DLQまで。OSS可観測性の本当の運用開始地点はそこにある。

参考 / References

OpenTelemetry: https://opentelemetry.io/
OTel Collector: https://opentelemetry.io/docs/collector/
SigNoz: https://signoz.io/ · https://github.com/SigNoz/signoz
Coroot: https://coroot.com/ · https://github.com/coroot/coroot
OpenObserve: https://openobserve.ai/ · https://github.com/openobserve/openobserve
Sentry self-hosted: https://develop.sentry.dev/self-hosted/ · https://github.com/getsentry/self-hosted
Uptrace: https://uptrace.dev/ · https://github.com/uptrace/uptrace
Grafana Loki: https://grafana.com/oss/loki/
Grafana Tempo: https://grafana.com/oss/tempo/
Grafana Mimir: https://grafana.com/oss/mimir/
Grafana Pyroscope: https://grafana.com/oss/pyroscope/
Grafana Beyla: https://grafana.com/oss/beyla-ebpf/
Grafana Alloy: https://grafana.com/oss/alloy-opentelemetry-collector/
ClickHouse: https://clickhouse.com/
Prometheus: https://prometheus.io/
CNCF Observability TAG: https://github.com/cncf/tag-observability