OTelはうまくいっていない（そしてそれについてスプレッドシートを作成した）

OTelはうまくいっていない（そしてそれについてスプレッドシートを作成した） 長年、チームをベンダー固有のSDKからOpenTelemetryに移行させようとする際に、最も信頼できる不満の1つは、「なぜこれがまだ終わっていないように見えるのか？」というバリエーションです。 オブザーバビリティのためのベンダーSDKは、慈善的に言えば、白痴でも使えるほど簡単です。それをインストールすると、ダッシュボードにデータがロードされ、他の誰かがそれらのピースがどのように組み合わさるかを心配し、あなたは自分の人生を続けることができます。それに対してOpenTelemetryは、ドアで多くの「実験的」スタンプと、任意のタスクを実行するための約6つの異なる方法であなたを迎えます。 OpenTelemetryの弁護として、これはプロジェクトとして決して目指していたものではありませんでした。ベンダーに依存しない真のシステムを構築するという彼らの主張を貫いたことを常に尊敬しています。データがどのように使用されるかを気にしません。OTelでベンダーが強く推奨されているという感覚は一度もありませんでした。これは、オブザーバビリティエコシステムがいかに儲かるかで論争の的であったかを考えると、かなりの偉業です。また、このプロジェクトのメンテナーの多くが、それらの企業に独占的に雇用されていることも考慮すると。 年月が経つにつれて、私は不安になり始めました。セマンティックコンベンションのリポジトリでの会話は延々と続きます。異なる言語は劇的に異なるストーリーを持っていました。GolangとDotnetはファーストクラスの市民でしたが、他の言語は何年も遅れていました。時間、予算、または感情的な帯域幅のない小規模なチームにOpenTelemetryを推奨する前に、多くの調査的な質問をするようになりました。自動インストルメンテーションは本当に魔法でしたが、「自動インストルメンテーションが機能する」と「今、手動でインストルメンテーションする必要がある」という崖は非常に急だったので、人々を突き落とす前に警告を与えるべきでした。 この物語はオブザーバビリティの分野でしばらく続いており、「OTelランドでは何かが間違っている」という漠然とした感覚があります。しかし、ここで実際のデータを生成してみましょう。実際の問題があるのでしょうか、それともコミュニティによる進捗の遅さの認識は想像上のものなのでしょうか？問題はメンテナーが足りないこと、スコープが大きすぎること、あるいはその中間でしょうか？ 私が始めたときの私の推測は、「ああ、これは古典的なオープンソースが手に負えないほど多くのものを引き受けたケースだ」でした。メンテナーが足りない、予算が足りない。今ではそれも一部ありますが、他に何か起こっています。OpenTelemetry内で実際に起こっている問題は、三つ巴のクラッシュです。バイナリスク安定性ゲートがあり、これは実際のメンテナーの非常に少ないベンチと組み合わせると、機能を実験的ではないとマークすることについて理解できる懸念を引き起こします。さらに、カバーしようとしている言語とフレームワークの巨大なスコープが加わります。これは、機能がロックインされて安定版として出荷されると決して変更できないため、機能が引き起こす可能性のある問題について議論するインセンティブを生み出す完璧な嵐を作り出します。 OpenTelemetryはどのように機能するか OpenTelemetryは現在、驚くほど多くの言語とフレームワークをサポートしようとしています。OpenTelemetryは巨大なプロジェクトです。数十の言語、数百のライブラリ、無数のバックエンドにまたがっています。物事を健全に保つために、プロジェクトは作業を2つのバケットに分割します。 コア → OTelプロジェクトによって直接メンテナンスされます。小さく、安定しており、ベンダーニュートラルで、厳密にレビューされています。これは「仕様定義」の表面です。 コントリブ → コミュニティおよびベンダーによって貢献されます。より広く、より速く動き、統合のロングテールをカバーします。 otel-collectorというものがあります。これは、ログ、メトリクス、トレースを送信できるように、そのものの横で実行されるものです。これは同じようなパターンをコピーします。しかし、言語に関しては、コアとコントリブについて話すとき、これは私たちが話していることです。 opentelemetry-python (コア) API、SDK、OTLPエクスポーター、コンテキスト伝播、リソース検出プリミティブ。 opentelemetry-python-contrib Flask、Django、requests、psycopg2、Redis、Kafka、boto3などのためのインストルメンテーションライブラリ。 壊れるものはコントリブに入り、壊れないものはコアに入ります。 これが競合を引き起こす理由。 コントリブはほとんどのプロジェクトにとって過剰です。通常必要なもの1つを追加するために300のエクスポーターを追加したくはありません。言語側では、これはそれほど大きな問題ではありません。pip install opentelemetry-instrumentation-flask は、Flaskに必要なものを提供します。しかし、コレクター側では、独自のコレクターを作成するためにOpenTelemetry Collector Builderを使用する必要があるか（または、単に波に乗ってうまくいくことを願うか）になります。これはクールですが、チームに任せるにはかなりのスコープです。 新機能追加のプロセス OTelに新機能を追加するワークフローを捉えられたと信じています。私の宿題はここで確認できます: OpenTelemetry Enhancement Proposal (OTEP) (https://github.com/open-telemetry/opentelemetry-specification/tree/oteps/) OTEPが承認されると、テキストは同じリポジトリのSpecificationディレクトリに入ります。その後、セマンティックコンベンションに進みます。ここが具体的な詳細にまで踏み込み、ほとんどの長い議論が行われる場所のようです。この時点で、私たちはこの設計に対するほぼ永久的なコミットメントについて話しており、ロックインプロセスは変更が非常に困難になります。 各SDKは、仕様で定義されたAPIサーフェスを実装します。SDKのいくつかは2.0の破壊的変更を行っているので、以前の「とにかく2.0は避ける」という感情は放棄されたようです（これは賢明で良いことだと思います）。 コントリブ / インストルメンテーション。 これは少し曖昧です。最新のAPI/SDKを追跡すべきですが、各コントリブパッケージは独立してバージョン管理できるため、設計としてはより柔軟です。 コレクター + OTLP。 データは実際どこかに送信される必要があります。OTLP（ワイヤープロトコル）は独自の安定性ライフサイクルと仕様（ここ）を持っています。コレクターコンポーネントは、READMEで独自の安定性を持っており、私の知る限りでは、それはどこにでもあるような状態です。 私があまり明確でないこと OTEPから仕様へのプロセスがどれくらいかかるかは不明です。Gitの履歴を調べましたが、予測可能な数やサイクルはないようです。これらすべての安定性コミットメントの関係が、私には完全には理解できません。コレクター+OTLPグループは連携して動作しますか？あまりにも遅れすぎると、言語は「スコープ外」になる可能性がありますか？ テストを試みる OpenTelemetryはCNCFプロジェクトなので、他のCNCFプロジェクトと比較するのが最も適切だと考えました。比較の基準はEnvoyとPrometheusです。 私は、オープンソースプロジェクトの「健全性」を測定するために以前使用したハッキーなPythonスクリプトを使用しました。おそらく最良の方法ではありません。しかし、チャートなしの生データをリンクに含めるので、人々がレビューできるようにし、（おそらく）私が生成したものに問題を見つけられるようにします。 Envoyの24ヶ月のアクティビティを見ると、かなり健全なプロジェクトであることがわかります。著者の分布、マージ担当者、問題解決者の分布が良いです。phlaxが明らかにプロジェクトにとって非常に重要ですが、一般的には、必要に応じてステップインできる人が十分にいます。既知のボットトラフィックはすべてフィルタリングしたつもりです。 これをOpenTelemetryの言語の1つと比較してみましょう。私が最も専門的な経験を持っているのはGolangとPythonですが、コミュニティの多くの人々から、RubyとPHPのものが非常に苦労していると聞いています。 これは同じ期間のPHPのものです。そのため、2人に集中しすぎていることがはっきりとわかります。これは健全なオープンソースプロジェクトではなく、OTelがカバーする必要のあるスコープをカバーするのに十分な人が明らかに不足しています。 Rubyでも同じ話です。 比較すると、私の意見では最も「強力な」OpenTelemetry SDKであるGolangとDotnet（Pythonも決して劣っていませんが）は、より健全に見えます。 Golang 最初の問題はおそらく最も驚くことではありません。少数のメンテナーに集中しすぎていることです。著者はマージ担当者や問題解決者でもあるべきではありません。理想的には、これらのタスクはより均等に分散されるべきです。 私の意見では、メンテナーは彼らを維持しようと良い仕事をしてきたと思います。