OTelはうまくいっていない？メンテナー不足と安定性のジレンマをデータで検証
OTel isn't going well (and I made a spreadsheet about it)
OpenTelemetryは、ベンダーに依存しないオブザーバビリティ基盤として広く採用されているが、その開発プロセスには深刻な問題がある。著者はCNCFプロジェクトであるEnvoyやPrometheusと比較し、各言語SDKのマージ担当者が極端に少ないこと、セマンティックコンベンションのPRが長期化していることをデータで示す。さらに、安定性へのコミットメントが変更を難しくし、議論が長引く構造を「三つ巴の衝突」と分析する。
安定性ゲートと少数のメンテナー、そして膨大なスコープが組み合わさることで、一度安定とマークされた機能は永遠に変更できないため、潜在的な問題について議論するインセンティブが生まれる。
- cute_boi
OTelなんてなければよかったのに。あれは設計がひどい抽象化で、OTelのおかげでコードがめちゃくちゃ汚くなって、ひどいことになる。
- bilalq
OTelには本当にイライラさせられる。この分野で明確な勝者になりつつなかったら、そこまで文句は言わないだろう。でも現状は：
1. 主要ベンダーはみんな、これだけ時間が経ってもまだOTelの対応がアルファ版やベータ版のまま。
2. パフォーマンスの低下が大きくて、同じワークロードを動かすのに2倍の計算リソースやRAMが必要なら、パフォーマンス計装の意味って何なのか疑問に思う。
3. サーバーレスランタイムはOTelでコールドスタートに大きなペナルティを払う。
4. 現実的な使い方をするには、ゲートウェイコレクタとエッジコレクタの両方を動かさざるを得ない。
5. それでも宛先エクスポーターを独自に設定する必要がある。これだとOTelの価値って何だったのか疑問に思う。
6. OTelの範囲を超えるベンダーは、独自の計装をまだ必要としている。それなら一体何の意味があったのか？
- brikym
計装が大きな問題だと思ったことは一度もない。確かにより多くの労力はかかるが、ビジネスイベントを理解すれば、はるかに多くの価値が得られる。