はじめに 以前マイクロサービスの分散トレーシングを導入する機会を頂き、OpenTelemetryについて色々と調べていました。 そこで今回は備忘録も兼ねて、OpenTelemetryとOpenTelemetry Collectorについて概要をまとめてみました。 OpenTelemetryとは OpenTelemetryは、トレース、メトリック、ログなどのテレメトリデータの作成と管理用に設計された、API、SDK、ツール、および統合のセットです。ベンダーに依存しない実装を提供し、選択したバックエンドにテレメトリーデータを送信する方法を標準化することを目的としています。 OpenTracingやOpenCensusの後継にあたる新たな標準化ツールとなります。つい最近ですが、ついにv1.0が公開され、今後テレメトリデータを扱うツールとして広まっていくのではないのでしょうか。 TraceとSpan OpenTelemetryにおけるトレース情報はTraceとSpanという概念で定義されています。 Trace: あるリクエストに対するSpanのまとまり Span: リクエスト内の各処理の情報（e.g. 処理名、実行時間、ステータスコードなどなど） より具体的には以下の図を見てもらうとわかりやすいです。 引用元 https://opentelemetry.lightstep.com/spans/ 以下、自分なりの解釈になります。（まちがいあるかも） これはあるクライアントからのリクエストをトレースした時のTraceとSpanの対応関係になります。 リクエスト全体の処理は、個々のコンポーネントが連携して行われます。連携するコンポーネントが多くなると、あるリクエストでエラーが発生した時にどのコンポーネントでエラーが発生したかを確認するのは大変な作業です。 そこで、Spanで個々のコンポーネントの処理を適宜記録することで、エラーが発生した箇所を特定しやすくします。 また、特定の順番でコンポーネントが連携した場合にのみ発生するエラーの場合は、Spanを独立して保存するだけでは対処しづらいと思います。そこで、Span同士に時系列で親子関係を持たせてTraceという1つのまとまりとして保存することで上記問題に対処していると考えられます。 パッケージと役割 OpenTelemetryは各言語ごとに先ほど説明したTraceやSpanのようなテレメトリデータを送信するパッケージが用意されています。 今回はGoにおけるOpenTelemetryの各パッケージの役割について説明します。 opentelemetry-go https://github.com/open-telemetry/opentelemetry-go/ コアリポジトリでありテレメトリデータ作成機能やJaeger、Zipkinといった主要なOSSにテレメトリデータをexportするためのExporterという機能を提供しているもの opentelemetry-go-contrib https://github.com/open-telemetry/opentelemetry-go-contrib コア機能でないものや、その他のオープンソースや商用のバックエンドのための実装を含むもの テレメトリデータの集約 テレメトリデータを集約するためにAWS X-RayやData Dog、Zipkinなどバックエンドに情報を送ることになると思います。 公式ドキュメントを確認すると、アプリケーションから直接トレース情報を送信するのではなく、後述するOpenTelemetry Collectorを利用する必要があるようです。 OpenTelemetry Collectorとは アプリケーションとテレメトリデータの可視化ツールとの中継役として、各ベンダー固有のテレメトリデータをバックエンドの対応したデータ形式に変換したりといった役割を持ちます。 イメージとしてはこんな感じです↓ 引用元 https://opentelemetry.lightstep.com/ ユースケース 引用元 https://opentelemetry.io/docs/ OpenTelemetry Collectorをサイドカーなどのようにアプリケーションと同じホスト上で動作させ、アプリケーションはOpenTelemetry Collectorに対しテレメトリデータを送信します。 2つのユースケースパターンがあるようです。 アプリケーション -> OpenTelemetry Collector -> バックエンド アプリケーション -> OpenTelemetry Collector(agent) -> OpenTelemetry Collector(service) -> バックエンド アーキテクチャ OpenTelemetry Collectorアプリケーションとテレメトリデータの可視化ツールとの中継役を担っていますが、実際にどのようにしてこれを実現しているのでしょうか、気になります。 軽くみていきましょう。 OpenTelemetry Collectorは大まかにReceiver、Processor、Exporterの3つの要素で構成されるようです。 引用元 https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/design.md Receiver どういうフォーマットでどのようにテレメトリデータを受信するかという設定 サードパーティのテレメトリデータを受け取って、内部的にTraceとSpanに変換する役割を持つ Processor テレメトリデータの加工、フィルター、リトライ、バッチ処理等の設定 Receiverから送られてきたTraceとSpan情報を特定の条件で加工する Exporter テレメトリデータのエクポートに関する設定 Processorから送られてきたデータを、Export先のデータ形式に変換し、送信する OpenTelemetry Collector自体はReceiver、Processor、Exporterをインターフェスとして提供することで、ベンダー依存を回避しているようですね。勉強になります。 さいごに 今回はざっくりとですが、OpenTelemetryに関する技術要素の概要をまとめました。 まだまだ知識としては浅いので間違った解釈などもあるかもしれませんが、その時はぜひご指摘いただけるとうれしいです。 さいごまで読んでいただきありがとうございます。 参考資料 https://signoz.io/blog/opentelemetry-collector-complete-guide/ https://opentelemetry.lightstep.com/the-collector-and-exporters/ https://lightstep.com/developers/opentelemetry/ https://qiita.com/uesyn/items/a595eb4cfe462dc8a438 https://zenn.dev/ww24/articles/beae98be198c94 https://opentelemetry.io/docs/