OpenTelemetryについて調べてみる
立場
- Datadog利用者
- Datadogの機能は便利だと思っている
- Datadogのサポートは低質だと思っている
- Datadogは高いとは思っている
- Datadogから離脱するプロジェクトとかは立ち上がってない
- 開発組織は数十人規模（調査時点）
OpenTelemetryとは
OpenTelemetry は、トレース、メトリクス、ログなどのテレメトリ データを作成および管理するために設計された Observability フレームワークおよびツールキットです。重要なのは、OpenTelemetry がベンダーやツールに依存しないことです。 つまり、Jaeger や Prometheus などのオープン ソース ツールや商用製品を含む、さまざまな Observability バックエンドで使用できます。 OpenTelemetry は、Cloud Native Computing Foundation (CNCF) プロジェクトです。
まだよくわからない。ベンダー中立が強調されている。
以下のコンポーネントで構成されるらしい。
- A specification for all components
- A standard protocol that defines the shape of telemetry data
- Semantic conventions that define a standard naming scheme for common telemetry data types
- APIs that define how to generate telemetry data
- A library ecosystem that implements instrumentation for common libraries and frameworks
- Automatic instrumentation components that generate telemetry data without requiring code changes
- Language SDKs that implement the specification, APIs, and export of telemetry data
- The OpenTelemetry Collector, a proxy that receives, processes, and exports telemetry data
- Various other tools, such as the OpenTelemetry Operator for Kubernetes
まだよくわからない気がするが登場人物を整理する。
ふんわり登場人物を整理
- 監視されるやつ：アプリケーションとそれに組み込まれるSDK
- 「組み込む」にinstrument / 計装 という単語がよく使われる
- アプリを監視してデータ収集するやつ
- 収集したデータを保存・視覚化するやつ
OpenTelemetryとは（再）
登場人物でいうところの以下二者を提供してくれるものということはわかった。
- 監視されるやつ（に組み込むSDK）
- データ収集するやつ
データを保存・視覚化するためのバックエンドについてはOpenTelemetryプロジェクトから直接提供はされず、対応プロダクトの中からOSSなりSaaSなり何か選んで採用することになる。
Datadogも対応バックエンドに含まれる。
他のバックエンドとしては以下のようなのがある。
OpenTelemetryの採用について考える
DatadogはOpenTelemetryのデータを取り込むバックエンドとして利用できる。
DD-TRACE LIBRARY→OTEL COLLECTOR / DATADOG AGENT→ANY BACKEND 経路が存在しないことについての余談
Datadog APMのトレースをOTEL Collectorが収集できるようにするreceiver（図でいうDD-TRACE LIBRARYとOTEL COLLECTORを結ぶもの）の開発をめぐり一騒動あったらしい。
1 年以上の遅れを経て、Datadog のアプリケーション パフォーマンス モニタリング (APM) プラットフォームからのデータのエクスポートを可能にするオープン ソース コードの貢献が、火曜日についに OpenTelemetry コンポーネントのコレクションに統合されました。
Datadog APM Receiver コードを作成したソフトウェア開発者である John Dorman 氏によると、遅延の理由は、約 1 年前に Datadog がソフトウェアを提出しないよう彼に依頼したためであるとのことです。
アプリケーションの監視（ログ、アプリのアクティビティの追跡、アプリケーションの実行を維持するために役立つその他の指標の収集と分析）に重点を置いているオープンソース コミュニティのメンバーは、DataDog が顧客を自社製品に閉じ込めることを好むと主張し、疑問を抱いていました。
この投稿の直後、ライバルのアプリケーション監視会社である Honeycomb.io の CEO である Charity Majors 氏が Twitter スレッドに OpenTelemetry のメリットを詳しく書き、OTEL を一方通行としてのみサポートしている Datadog を非難しました。
Datadogのアンサー（最後のセクション）
この投稿が最近の GitHub プル リクエストへの応答として解釈されていることが明らかになりました。それを踏まえて、Datadog が OpenTelemetry のサポートに全力で取り組んでいることを再確認したいと思います。その取り組みの一環として、私たちはエコシステム内のコミュニケーションを改善し続けます。 OTel ロードマップは顧客からのフィードバックに基づいて進化したため、レシーバーのプル リクエストのループを閉じる必要がありました。申し訳ございません。ポリシーとして、私たちはコミュニティ メンバーにコード寄稿の撤回を強制することは決してありません。これは OpenTelemetry だけでなく、私たちが参加しているあらゆるオープンソース エコシステムに当てはまります。
私たちはレシーバーを正式にサポートすることはできませんが、何をマージするかを決定するのはコミュニティであり、私たちではありません。私たちは OTel の将来に興奮しており、今後も定期的に更新されることを期待してください。
OpenTelemetry SDKだけを利用して「収集するやつ」の役割はDatadog Agentにやらせる方法と、
OTEL Collectorを「収集するやつ」として採用する方法がある。
現在は一気通貫でDatadogに依存している（DD-TRACE LIBRARY->DATADOG AGENT->DATADOG BACKEND）が、一部アプリにDatadogのライブラリが組み込まれていても活用はそれほどされていないという状況にある。
仮にOpenTelemetry SDKとOTEL Collectorに移行した場合、バックエンドをDatadogから他の製品にスイッチすることが理屈では可能になる。
アプリケーションのSDKをOpenTelemetryに取り替えるのは比較的小さい手間で済む（ゼロではない）が、Datadog AgentをOTEL Collectorに交換するのはそれなりのプロジェクトになりそう。
いずれにしろ手間はかかるため、あえてOpenTelemetryの採用を始めるなら目的が必要になり、その目的は「部分的または完全にDatadogから離脱する」ということになりそう。
完全に離脱する
完全に離脱すると決心したならば話は比較的単純で、アプリに計装済みのSDKをOpenTelemetry SDKに置き換え、OTEL CollectorをデプロイしてDatadog Agentの廃止を進め、Datadogへの依存がバックエンドだけになったらスイッチするということになる？
（道筋がはっきりしているというだけでやるのは大変そう）
部分的に離脱する
具体的に何をどうするまでは見えていないが、運用負荷の増大を受け入れてでもDatadogの料金を下げたくなったときにはありえる？
- SDKを併用
- Datadog Agent / OTEL Collectorを併用
- Datadogバックエンド / 他のバックエンドを併用
たとえば：Datadog APMが高いからAPMについてはOpenTelemetryと他のバックエンドを使う
実際離脱しようと思うのか？
自分もチームもDatadogにまったく不満がないとはいかないにしても、離脱をやっていく熱量もそこまで高まっておらず、当面OpenTelemetryの採用はなさそうだった。
OpenTelemetryとAWS
OpenTelemetryの採用可能性はなさそうだという結論の後で蛇足感があるものの、「OpenTelemetryとAWS」という切り口でも多少調べてみたので書いておく。
我々はAWSユーザーでもあるため「収集するやつ」ポジションにOTEL Collectorを利用するときには縁がありそうなもの。
OpenTelemetryは「SDK」と「Collector」を提供していることを前項で確認したが、それぞれの亜種（AWSによるカスタムバージョン）を利用するための一連の仕組みが「AWS Distro for OpenTelemetry」ということらしい。
EKSにコレクターをデプロイするには、EKSアドオンが利用できる。
CNIプラグインやGuardDutyエージェントのアドオンなどと違うのは、アドオンを作成してもCollector自体はデプロイされないという点。
アドオンを作成すると、「ADOT Operator」がクラスター上で動き始めるが、それだけではまだCollectorはデプロイされない。
このOperatorは「Collectorを表現するカスタムリソースに責任を持つコントローラー」なので、カスタムリソースOpenTelemetryCollector（そのまんまの名前）を作成すると、その宣言にしたがってCollectorをデプロイしてくれる。
（Datadog OperatorとDatadog Agentの関係みたいなもの。Datadog Operator使ってないけど…）
※OpenTelemetryCollectorのサンプル
結構大きなカスタムリソースなので、思い通りの設定のものをこしらえるのはそれなりに骨が折れそう。
バックエンド
EKS FargateのFluent BitがDatadogを送信先にできないのと違って
ADOT Collectorも（公式Collectorと同様）Datadogをバックエンドに選択することができる。
他にも複数のSaaSやOSSバックエンドに対応している。
とはいえManaged PrometheusやCloudWatch、X-Rayを使ってほしそうな雰囲気はある（それはそう）。
Discussion