はじめに
こんにちは、StackdriverあらためGoogle Cloud Operations担当者です。先日、OpenTelemetryの現状まとめ、という記事を書きましたが、その流れで現状のOpenTelemetry関連プロジェクトの関係図に起こして（バックエンドサービスがある場合はGoogle Cloud Operationsとする）、各種機能がどうなっているかを簡単に整理しておこうと思います。
関係図
OpenTelemetryはご存知のとおり複数言語を対象とした計装用フレームワークなのですが、先の記事に書いたようにCollectorがGoで実装されてるため、プロジェクト全体でいうとGoで実装されたものの割合が多くなります。Goの実装に関係するコンポーネントを図にすると次のようになります。*1
この図の中にある数字は次のリストの数字と対応します。
- OpenTelemetry specification
- OpenTelemetry for Go (API, SDK)
- OpenTelemetry collector
- OpenTelemetry collector upstream exporter (アプリケーション → Collector)
- OpenTelemetry collector downstream exporter (Collector → Cloud Operations)
- OpenTelemetry receivers
- OpenTelemetry direct exporter
見ての通り地味に多い！自分が関わっているのは主に #7 の開発ですが、もし各種APMベンダーやOSSがそれぞれ対応するとしたらどの部分を実装しなければいけないかというと、この図で言うところの #5 と #7 の部分だけです。あるいは、あるとすればパイプライン に独自の処理を追加する場合には、上の図には登場しないですが Processor を実装する必要があります。（その場合のcontribute先は contrib レポジトリになる）
各言語向け実装
上の図で見てわかるように、各言語向けに実装しなければいけないのは #4 もしくは #7 の実装とわかります。そのうち各APMバックエンドが各言語向けに個別に提供しなければいけないのは #7 のみです。
Google Cloud Operationsの場合は次のとおりです。
まだ本家の仕様がstableになっていないこともあり、Python用とJava用のExporterは建設予定地としてプレースホルダが用意されているだけです。
おわりに
OpenTelemetryはまだ仕様が安定版に至ってはいませんが、ようやくその目処が立ち、様々なところでチラホラと話が聞こえてきた頃だと思います。そこでExporterという名前が出てきたときにどのExporterか混乱しないように、ぜひこの図を参照してください！大きな変更があれば今後もなるべくこのブログで情報を共有していこうと思いますが、とりあえずいまはこんな状況です。
*1:社内の説明用に描いた図ですが、すべて公開情報なのに公開しないのはもったいないので掲載するためにこのエントリーを書いた
