OpenTelemetry Collector の中身と種類を知ろう
Author : 山口 能迪
こんにちは、デベロッパーアドボケイトの山口です。
AWS ではオブザーバビリティ関連サービスとして Amazon CloudWatch、Amazon X-Ray、Amazon OpenSearch Service、Amazon Managed Service for Prometheus などがあります。これらのサービスに自分で実装したアプリケーションからテレメトリーデータを送信する場合の選択肢として AWS Distro for OpenTelemetry (以下、ADOT) があります。
本記事では一般的な OpenTelemetry Collector の説明に加え、ADOT の詳細について解説します。
TL;DR
ADOT は OpenTelemetry Collector の AWS 向けのディストリビューションで、AWS およびパートナーのソリューションを利用する上で必要なコンポーネントがインストールされています。より凝った形で OpenTelemetry Collector を使いたい場合には、カスタムビルドを行いましょう。
OpenTelemetry とは
すでに多くの AWS ユーザーの方々が OpenTelemetry を活用していることと思いますが、あらためて簡単に OpenTelemetry について説明します。OpenTelemetry は CNCF 傘下のプロジェクトです。システムの計装 (インスツルメンテーション) およびテレメトリーの収集と送信を標準化を行っています。
図 1 : OpenTelemetry プロジェクトがフォーカスする範囲。
テレメトリーの保存や可視化は範囲外。
OpenTelemetry Collector とは
OpenTelemetry Collector (以下、コレクター)は、OpenTelemetry プロジェクトで仕様を策定、および参照実装を開発している、テレメトリーの計装、収集、送信を行うエージェントです。参照実装は単一のバイナリで動作し、Go で実装されています。
主にレシーバー (receiver)、プロセッサー (processor)、エクスポーター (exporter) の 3 種類のコンポーネントで構成され、配布する前に必要なコンポーネントを指定して単一バイナリにします。
- レシーバー : テレメトリーの受信を担当。
- プロセッサー : テレメトリーの加工やバッファリングなどの処理を担当。
- エクスポーター : テレメトリーのバックエンドへの送信を担当。
バイナリ内に同梱されたコンポーネントは設定ファイルで自由に連結できますが、レシーバー、プロセッサー、エクスポーターの方向にしか繋げられません。レシーバー、エクスポーターは 1 つのパイプライン内で 1 つずつですが、プロセッサーは複数連結可能です。
図 2 : 3 つのレシーバー、5 つのプロセッサー、2 つのエクスポーターを持つ
コレクターの概念図
たとえば次の設定ファイルは OTLP でテレメトリーを受信し、batch と memory_limiter のプロセッサーで送信するテレメトリーの流量を調整したあと、ふたたび OTLP でテレメトリーを送信しています。
receivers:
otlp:
processors:
batch:
memory_limiter:
limit_mib: 1536
spike_limit_mib: 512
check_interval: 5s
exporters:
otlp:
service:
pipelines:
metrics:
receivers: [otlp]
processors: [memory_limiter, batch]
exporters: [otlp]コレクターは GitHub の open-telemetry/opentelemetry-collector および open-telemetry/opentelemetry-collector-contrib のリポジトリで公式配布の各コンポーネントのソースコードを公開しています。さらに、OpenTelemetryプロジェクト公式版としていくつか 事前ビルド済みのコレクターのバイナリ、および それを同梱した OCI コンテナ を配布しています。
2025 年 2 月現在、公式配布のコレクターには含まれるコンポーネントの種類の違いによって 4 種類のビルドが提供されています 1 。
- otelcol-otlp : OTLP の受信と送信しかできないバイナリ。ファイルサイズは非常に小さいが機能がほぼない。
- otelcol : OpenTelemetryとしてサポートすべきOSSに対応しているバイナリ。
- otelcol-k8s : otelcol に加え Kubernetes 向けのコンポーネントが追加されたバイナリ。
- otelcol-contrib : OpenTelemetryプロジェクト配下で管理されている全コンポーネントを含めたごった煮のバイナリ。オブザーバビリティSaaS向けのもの含め全コンポーネントが使えるかわりにファイルサイズが非常に大きい。
1: 各バイナリのビルド用のマニフェストファイルは open-telemetry/opentelemetry-collector-releases のリポジトリ内で確認可能です。(otelcol-otlp、otelcol、otelcol-k8s 、otelcol-contrib)
ADOT (AWS Distro for OpenTelemetry) とは
AWS 向けのコンポーネントを利用したい場合、公式配布のコレクターでそれを実現しようと思うと、 otelcol-contrib を利用するしかありません。しかしこれは不必要なコンポーネントも大量に含んでいるため無駄に大きなバイナリを使うことになります。そこで、AWS では ADOT と呼ばれるコレクターのディストリビューションを提供しています。
ADOT は公式配布の otelcol で使われているコンポーネントに加えて、AWS サービスやパートナーの SaaS ソリューションを利用する上で便利なコンポーネントを追加したもの 2 を事前ビルドして 配布しています。ここで作成されたバイナリは、Amazon ECS や AWS Lambda などで指定すると起動できるようになっています。
AWS 上で OpenTelemetry の基本的な使い方をするのであれば、ADOTを使うのが第1選択肢になるでしょう。
2 : ADOT で同梱しているコンポーネントの一覧がリポジトリの README に 記載されています。実体は Go のソースコード で確認できます。
コレクターのカスタムビルド
AWS 上では ADOT Collector を使うのが良いと思いますが、ADOT 内にも利用しないコンポーネントは出てくることと思います。OpenTelemetry をより発展的に使いたい場合に、こうした不必要なコンポーネントを使わず、また逆に ADOT に含まれていないコンポーネントを使いたいという状況になるかもしれません。たとえば分散トレースのスパンをメトリクスに変換する Span Metrics Connector というコンポーネントは ADOT には入っていません。そのような高度なユースケースの場合には OpenTelemetry Collector builder (以下、ocb) を利用します。
ocb は YAML ファイルに必要なコンポーネントを Go のパッケージ名の形で列挙して指定することでビルドできる便利なツールになっています。詳細は 公式サイト に譲ります が、たとえば次のようなコンポーネントだけを入れたコレクターをビルドしたい場合は次のような YAML ファイル otelcol-foo.yaml を作成します。
dist:
name: otelcol-foo
description: Custom OpenTelemery Collector for Project foo AWS account
output_path: ./otelcol-foo
receivers:
- gomod: go.opentelemetry.io/collector/receiver/otlpreceiver v0.119.0
processors:
- gomod: go.opentelemetry.io/collector/processor/batchprocessor v0.119.0
- gomod: go.opentelemetry.io/collector/processor/memorylimiterprocessor v0.119.0
exporters:
- gomod: github.com/open-telemetry/opentelemetry-collector-contrib/exporter/awsemfexporter v0.119.0この YAML ファイルを用いて、次のように ocb コマンドを実行するとカスタムビルドのコレクターがビルドされます。
./ocb --config otelcol-foo.yamlおわりに
本記事で ADOT の中身についての理解が深まったことと思います。OpenTelemetry の発展とともに ADOT も発展してきています。実際 ADOT の中身はバージョンを追って多少の入れ替わりなどがあります。しかし中身はカスタムビルドをしているだけなので、その実態を知っていればなにも恐れることはありません。みなさんのプロジェクトに最適なコレクターの選択に活かされれば幸いです。
筆者プロフィール
山口 能迪 (Yoshi Yamaguchi / @ymotongpoo)
アマゾン ウェブ サービス ジャパン合同会社
シニアデベロッパーアドボケイト
AWS製品の普及と技術支援を担当し、特にオブザーバビリティ、SRE、DevOpsといった領域を専門とする。
AWS を無料でお試しいただけます