OTel はイケてない（でもやっぱり最高！）
Blog posts are not updated after publication. This post is more than a year old, so its content may be outdated, and some links may be invalid. Cross-verify any information before relying on it.
OpenTelemetry（OTel）は、ベンダー非依存と包括的なデータ収集を約束する、オブザーバビリティの未来としてよく紹介されます。 しかし、日常的に使っている人たちにとっての現実はどうでしょうか。 私たちは数人のエンジニアや SRE に話を聞き、OTel に対する率直な意見を集めました。 その結果は、OTel を使った仕事の良い面、悪い面、そして時にフラストレーションを感じる面についての率直な対話でした。
KubeCon での講演 OTel Sucks (But Also Rocks!) の準備として、Juraci はコミュニティメンバーに話を聞き、多くの貴重なインサイトを集めました。 時間の制約からすべての内容をプレゼンテーションに含めることはできなかったため、この記事はコミュニティの貢献を正当に伝えるための試みです。
OTel のイケてないところ
OTel に対する率直な意見の中で、エンジニアや SRE は共通の課題を挙げました。 Delivery Hero の Elena は、「安定した Collector バージョンの欠如」と「変更の速いペース」を大きな課題として挙げました。 これらの頻繁なアップデートにより、本番環境の安定性を維持するために面倒なチェックやテストが必要になります。
Atlassian の James と Pismo の Alexandre は、セマンティック規約の変更によって引き起こされるフラストレーションを表明しました。 これらの変更は既存のダッシュボードを壊す可能性があり、大規模なシステム全体の計装を更新するために多大な労力を必要とします。 Alexandre は特に、属性の変更を会社全体に指示することの難しさに言及し、開発者たちはそれを快く思っていなかったと述べました。
Liatrio の Adriel は「計装は難しい」と指摘し、情報やオプションのあまりの多さにより、始めるだけでも圧倒されかねないと述べました。 また、手動計装の最初のハードルを乗り越えてもらうことの難しさにも言及しました。 James も Java エージェントの「マジック」について触れ、強力ではあるものの、時としてデバッグが困難な予期しない問題につながることがあると述べました。
インタビューに応じた全員が、OTel には学習曲線があることに同意しました。 特に Collector、設定、セマンティック規約の理解に関してです。 Adriel は「それを理解するのに多くの概念的なオーバーヘッドがかかった」と述べました。 Alexandre もまた、ドキュメントは改善されてきているものの、もっと多くの例があるとさらに良くなるだろうと述べました。
OTel の最高なところ
課題がある一方で、インタビューに応じた方々は OTel の大きなメリットも認めていました。
たとえば、Pismo の Alexandre はベンダー非依存の重要性を強調しました。 OTel によってすべてのデータを統合し、特定のエコシステムにロックインされることなく、好きなベンダーに切り替えることができます。
Atlassian の James は、何かうまくいかないときに小さなモジュラーパーツを置き換えられる、OTel のモジュラー設計を称賛しました。 この柔軟性は、セットアップをカスタマイズする必要があるパワーユーザーにとって特に重要です。
Delivery Hero の Elena は、OTel を使ってログから分散トレーシングに移行したことがいかに変革的だったかを語りました。 彼女はログに戻ることを「非効率」と表現しました。 James もまた、Java エージェントがモノリシックアプリケーションの「かつてないほどの全体像」を提供することを強調しました。
OTel コミュニティに深く関わっている Adriel は、オープンソースの価値とコントリビューションできることの重要性を強調しました。 彼は「最初の難しさを乗り越えて使い始めてしまえば、そこからは楽勝で、非常に強力だ」と述べました。
Pismo の Alexandre は、OTel でテイルサンプリングを導入したことで、オブザーバビリティのコストを大幅に削減した説得力のあるエピソードを共有しました。 リソース配分を最適化し、Collector の過剰なスケーリングを回避することができました。
最後に、Alexandre はオブザーバビリティの運用に標準化をもたらす OTel の役割を強調しました。 OTel 導入前は、ベンダー固有のライブラリや社内の Collector が混在しており、不整合やトレースの断裂が発生していました。 OTel はデータ品質を大幅に向上させる「単一のライブラリ、単一の標準」を提供しました。
コミュニティこそが大事！
OpenTelemetry コミュニティはメンバーから高く評価されています。 Adriel Perkins は、このコミュニティが初めてオープンソースに積極的に関わった経験だと述べ、その大きな理由は人々との楽しいやり取りだったと語っています。 彼は、常に喜んでガイダンスを提供してくれる、聡明で親切で協力的な人が多くいることを強調しています。 コミュニティメンバーは経験豊富であり、Adriel はそのおかげで自身がエンジニアとして成長できたと信じています。 さらに、コミュニティは非常に協力的で情熱的であり、プロジェクトの未来にワクワクしていることが特徴です。 メンバーは時に率直ではありますが、概して礼儀正しく親切です。
James Moessis もまた、コントリビューターはコミュニティ内の熱心な人々にコードをレビューしてもらえること、そして開発者がコントリビューションを受け入れる姿勢を持っていることを指摘しています。 コントリビューター体験サーベイの存在は、コントリビューター体験を理解し改善しようとするコミュニティの姿勢を示しています。 全体として、コミュニティはメンバーが学び成長できる、支え合いと協働の環境を育んでいます。
結論
インタビューから明らかになったのは、OTel との複雑な関係性でした。 完璧なソリューションではなく、それなりの課題を伴います。 しかし、その複雑さを乗り越える意志がある人にとって、OTel は強力な機能と大きなメリットを提供します。 Atlassian の James が述べたように、「OTel がイケてないときでも、良いのはイケてなくならないように設計されていることで、あちこちの小さなモジュラーパーツを置き換えられるんだ」。
結局のところ、OTel の価値はその柔軟性、ベンダー非依存、そして複雑なシステムへの深い洞察にあります。 成長の痛みや改善の余地はあるものの、OTel はオブザーバビリティのための強力なツールであることは間違いありません。
Elena Kovalenko、James Moessis、Adriel Perkins、Alexandre Magno の皆さんが OpenTelemetry に関する正直で洞察に満ちた経験を共有してくださったことに感謝します。 彼らのストーリーは、OTel の導入を検討中の方や現在使用中の方にとって、貴重な視点を提供してくれます。