ハクソク

世界を動かす技術を、日本語で。

OTelはうまくいっていない

2026年8月22日原文(matduggan.com)

概要

  • OpenTelemetry（OTel）はベンダーロックインを避けるための観測性フレームワーク
  • ベンダーSDKと比べ、導入や運用が難しく「未完成」感が拭えない現状
  • プロジェクトの進行が遅い原因は、メンテナ不足・巨大なスコープ・安定性要件の三重苦
  • コアとコントリブの分割、機能追加プロセスの複雑さも課題
  • 他OSS（Envoy、Prometheus）との比較で、OTelはメンテナ分散が不十分

OpenTelemetryの現状と課題

  • OpenTelemetry は、 ベンダーロックイン回避 を目指した 観測性フレームワーク
  • ベンダーSDK は「インストールするだけ」「ダッシュボード自動生成」など、 導入が容易
  • OTelは「 experimental」の多さや 複数の方法論 で、 学習コストが高い
  • 観測性エコシステム の複雑さと、 各言語ごとの進捗差 が顕著
    • Golang や Dotnet は進んでいるが、 Ruby や PHP は遅れ気味
  • 自動インストルメンテーション は便利だが、手動への移行は 学習コストが急増

プロジェクト進行の遅さの要因

  • 安定性ゲート （Binary Stability Gate）の存在
    • 一度安定化した仕様は 変更困難 になるため、慎重な議論が続く
  • メンテナ不足 と 巨大なスコープ
    • 多数の言語・フレームワーク・バックエンドへの対応
    • 主要メンテナがごく少数に集中
  • コア（core） と コントリブ（contrib） の分割
    • コア：API・SDK・OTLPエクスポータなど、 安定・ベンダーニュートラル
    • コントリブ： 各種インストルメントライブラリ やエクスポータ、 進化が速く不安定
  • コレクター（otel-collector）も同様の構造
    • 独自ビルド が必要な場合が多く、 運用負担が大きい

新機能追加のプロセス

  • OpenTelemetry Enhancement Proposal（OTEP） が起点
    • 承認後、 Specificationディレクトリ に反映
    • Semantic conventions で詳細設計・長期議論
    • 各SDKでAPI実装、 一部2.0ブレイク変更 も発生
  • contribパッケージ はAPI/SDKに追従しつつ、 独立したバージョン管理
  • Collector/OTLP は独自の安定性ライフサイクルを持つ

メンテナ分散状況と他OSSとの比較

  • Envoy や Prometheus は、 メンテナ分散が良好
    • 複数のコアメンバーが活発に活動
  • OTelの多くのSDK は、 1～2人に作業が集中
    • 例：opentelemetry-phpは2人、opentelemetry-rubyは1人が大半を担当
    • Golang や Dotnet は比較的分散
  • メンテナの負担増加、 長期的な安定性維持の難しさ
    • 趣味レベルでは対応困難、 企業支援必須

機能追加・仕様策定のボトルネック

  • Semantic conventionsリポジトリ での議論が長期化
    • 例：Gen-AIやGCP、Azure関連のPRは100日以上かかるケースも
  • ただし SDK/API側への伝播は限定的
    • Pythonではsemconv以外の要因で遅延するPRも多い
  • 根本的な課題は「人手不足」＋「安定性への過剰な配慮」
    • 結果として「 プロジェクトの凍結」に近い状況

まとめと今後の展望

  • OpenTelemetry は 理想的なベンダーニュートラル を目指すが、 実装・運用コストが高い
  • メンテナの分散・増員、 安定性ポリシーの見直し が急務
  • 趣味・副業レベル では支えきれない規模感
  • 企業・コミュニティによる本格的な支援体制 の構築が必要
  • 導入検討時は、チームのリソースや目的を慎重に見極めることが重要

Hackerたちの意見

器具については特に大きな問題だとは思ったことがないな。確かに手間はかかるけど、ビジネスイベントを理解すればその分価値が増すからね。

OTelは本当にイライラする。もしこの分野で明らかな勝者になりそうじゃなかったら、こんなに文句言わないんだけど。今日の時点で、1. 主要なベンダーはまだ変なアルファ/ベータサポートの状態だし、時間が経っても改善されてない。2. パフォーマンスの影響が大きすぎて、同じワークロードを動かすのに今は倍のコンピュータ/RAMが必要になると、パフォーマンス計測の意味が疑問に思えてくる。3. サーバーレスのランタイムは、OTelを使うとコールドスタートのペナルティが重い。4. 実際の使用には、ゲートウェイコレクターとエッジコレクターの両方を動かさざるを得ない。5. 目的地のエクスポーターをユニークな方法で設定する必要がある。このせいでOTelの価値が何だったのか疑問に思う。6. OTelの範囲を超えるベンダーは、やっぱり独自の計測が必要だし、結局何のためにやってるのか分からなくなる。

└
  1. 実際の使用には、ゲートウェイコレクターとエッジコレクターの両方を動かさざるを得ない。そんなことは全然ないよ。アプリを（特に「サーバーレス」なら）コレクターエージェントなしで動かせるから。アプリからエージェント、エージェントからシンクへの通信は同じプロトコルを使うから、トレース/ログ/メトリクスのエクスポーターを設定して、直接シンクと話すだけでいい。最近では、通常はURLとDSNヘッダーを指定するだけだね。
└

じゃあ、代替案は何なの？（本気の質問、仮定の皮肉じゃないよ。）

OpenTelemetryについていつも不思議に思うのは、トレース、メトリクス、ログがそれぞれ独立して設計されていること。コードベースを一度だけ注釈付けして、メトリクス/ログ/トレースとして何かを公開するかの最終的な判断を実行時に動的にできる方法があればいいのに。例えば、モニタリングダッシュボードでグラフを見て何か怪しいものを見つけたら、「次にこういうことが起きたら、トレースを保存しておいてね」と言いたい。マウスを一回クリックするだけでそれができるべきだと思う。トレースの仕様やSDKがリリースされた時に「さあ、次はメトリクス/ログに進もう」と言ってたのを覚えてるけど、それはどうも腑に落ちなかった。

└

それを実現する一つの戦略は、デフォルトで全てをトレースして、後でサンプリングするものを選ぶことだね。例えば、https://grafana.com/docs/grafana-cloud/observe-and-act/adapt...

└

Lispではそれができるよ。ラッパーを自由に再定義して、他のロジックを持たせたりできるからね。

└

トレーシングは一番一般的なもので、実装に気をつけないと一番高くつくよ。トレーススパンは「起こったこと」の時間制限付きの単位で、スパン同士は木構造の関係にあって、それぞれのスパンには任意のタグ（キー/バリューのペア）やイベント（時間/バリュー）が持てるんだ。そこから、必要ならメトリクスやログを導き出すこともできる。コツは、トレーシングから始めて、実際にプログラムに組み込むことだね。後からほぼ自動的に追加しようとするのはダメだよ。

└

この感情が理解できないんだ。メトリクスをトレースとしてどう表現するの？できないよ。ログからトレースを再構築するのも、せいぜい難しいのに。例えば、ガーベジコレクタのメトリクスをログやトレースからどうやって取得するの？無理だよ。魔法の弾丸なんてない。可観測性は、ただ付け足して終わりってわけにはいかない。トレースとログは表面的には似てるかもしれないけど、全然違うし、メトリクスはまた別物だよ。それらを無理に統一しようとするのは「間違った抽象化」の典型例だね。>「次にこういうことが起きたら、トレースを保存しておいてください。」このための基本要素は存在する。可観測性プラットフォームは、単に（ハハ）パターン検出器を実装して、サンプリングの決定に使えばいいんだ。

└

OTELが必ずしも「悪い」とは思わないよ。可観測性エコシステム全体にわたって分断があるからね。例えば、Grafanaのソリューション群には、Loki（ログ）、Tempo（トレーシング）、Mimir（メトリクス）があって、全ての軸のストレージとクエリをカバーしているんだ。それぞれが非常に異なる処理とパフォーマンス特性を持っているから、直感的には三つの領域に大きな重複があるように見えるかもしれないけど、実際には驚くほど少ないんだ。少しだけ重複している部分（例えば、トレースログの相関）については、OTELが標準を提供しているよ。

└

OTELはOpenTracing（複数のトレーシング実装にわたるトレーシングのためのもの）やログ、メトリクスを一つの可観測性標準にまとめた標準化された集約物として登場したのはほぼ避けられないことだと思う。歴史的に見ても、ログとメトリクスはずっと異なる問題領域で、異なる実装があったからね。さて、君の言う通り、トレーシングが一番愛されているし、ログやメトリクスをトレースに追加するための構造も含まれている（実際にはスパンだね）。だから、彼らは単一のインターフェースを開発しようとしていると言えるかもしれない。>「次にこういうことが起きたら、トレースを保存しておいてください。」これが欲しいなら、関与する可能性のある全てのポイントにこの条件を伝播させる必要があるか、常に全てのトレースを出力して、その条件をフィルターに含める必要があるんだ。そして、その条件をクリックしたシステム/UIからフィルターする場所に動的に伝播できるようにしなきゃいけない。これが、私たちが常にトレースを伝播させて出力し、処理の前にフィルタリングする理由の一つなんだ。

K8sにすごく似てるね。使うためのフレームワークじゃなくて、その上にフレームワークを構築するためのフレームワークだ。観測ベンダーが裏でそれを使うようになって、もっと簡単に組み合わせられるようになればいいのに。ほとんどのフレームワークやバックエンドでOTelのサポートがすごくバグだらけじゃなければいいのに。

Hacker Newsで議論の続きを見る