OpenTelemetry Collectorのコンポーネント一覧
Receiver
データの受信器です。トレース、メトリクス、ログを受信、収集することができます。OTLP ReceiverによりSDKやAPIによるアプリからのトレースやメトリクス、または他のOTel Collectorからのデータ転送をOTLPで受信できます。
Host Metrics ReceiverによりOSのCPU、メモリ、ディスク、プロセスなどを収集できますし、ミドルウェア（NginxやMySQLなど）からもメトリクスを収集することができます。
ログ取得はfilelog receiverにより可能です。
その他にもHTTPテスト（HTTP Check Receiver）やファイル更新日時の取得（File Stats Receiver）といったものもあります。
例えば Prometheus などの監視ツールを利用している場合、Prometheus Receiverなどを活用することで、その監視ツール自体を統合することもできます。
このように Receiver は多岐にわたって提供されています。あらゆるテレメトリーデータを統合的に扱うことができるOTel Collector の特長が表れているポイントの一つと言えるかと思います。
どのようなReceiverが提供されているかはRegistyページから確認することができます。
Processor
データの処理器です。Receiverで取得したデータに対して処理を行うことができます。
データ送信負荷のコントロールをメモリリミッター（Memory Limiter Processor）や、バッチ化（Batch Processor）により行えます。
データの加工処理として、Attributes ProcessorによりAttribute（システム名や環境名などメタデータ）の追加・変更・削除、Resource Detection ProcessorによりOTel Collectorがインストールされているホスト情報（OSやAWS EC2の場合はリージョンなど）を取得しAttributeとして付与するなど、これも多岐に渡った柔軟な処理が可能です。
バックエンドがSaaSの場合に機密情報の取り扱いが議論になると思います。一般的な対策としてデータのフィルタリングやマスキングがありますが、それもProcessorを使用して対応することができます。
そして忘れてはならないのがSamplerです。
テレメトリーデータを取得する際に特にトレースが膨大になりがちで一般的にはサンプリング戦略を取る必要があります。
ここでは詳細には立ち入りませんが、ProcessorとしてはTail Sampling ProcessorやProbabilistic Sampling Processorが提供されています。
備考
- 複数定義した場合、定義順に処理されます。
- 何を使用すれば良いか迷うと思います。推奨のものを確認することができます。
- Processorの一覧もご確認ください。
Exporter
データの送信器です。Receiverで受信し、Processorで処理したデータをバックエンドに送信することができます。
標準的にはOTLP（HTTP / gRPC）でバックエンド、もしくは別のOTel Collectorに送信することができます。OTLPは近年のオブザーバビリティツールであれば多くのものが対応しています。OTLPでの受信方法は各バックエンド側がドキュメントとして公開しているでしょう。
ツール固有のExporterとして、例えばKafkaへ送信したり（Kafka Exporter）、ログをSplunkに送信することもできます。利用頻度が少ないデータはAWS S3に送ることもできますし（AWS S3 Exporter）、もしくはデバッグ用途にコンソールに出力することもできます（Debug Exporter）。
このExporterの柔軟性もOTel Collectorの優れたところです。例えば以下のユースケースに対応できます。
- 複数の宛先を指定しいくつかのバックエンドを同じデータで検証する
- 本番環境と検証環境でエージェントは統一しつつも別々のバックエンドに送り（本番は有償SaaS、検証はOSSなど）、コストを合理化する
- 本番環境の中でもデータの重要度、利用頻度に合わせてバックエンドを変えるOpenTelemetryに対応している（非網羅的な）ベンダーリストが参照できます。
備考
- Exporterの一覧をご確認ください。
Extension
Extensionはデータ送信パイプラインには直接的に関係しない拡張機能を提供します。
例えばzPagesはOTel Collectorの処理状況に関する統計情報を提供します。Health CheckはKubernetesにおけるLiveness / Readiness Probeで使用可能なOTel Collectorの稼働状況を返します。他にもExporterの認証を行うためのExtensionもあります（Basic、Bearer、OAuth2など）。
備考
- Extensionはパイプラインの外で定義します。後ほど例を見ます。
- Extensionの一覧をご確認ください。
Connector
Connectorは比較的最近開発された機能で、ReceiverとExporterの両方の役割を担うことでパイプライン間の橋渡しをすることができます。これにより、より柔軟なパイプラインを構成することができます。
トレースからRED（Request、Error、Duration）をメトリクスとして生成できるSpan Metrics Connectorや、ログのエラー数をAttribute別にカウントしメトリクス化（例えばアクセスログから4xx、5xxの件数をカウント）するCount Connectorなどがあります。
執筆時点（2024年8月）ではRegistryページはConnectorの情報が掲載されていないようです。Registryページの代わりに以下のOpenTelemetry Collectorのレポジトリを参照ください。
- https://github.com/open-telemetry/opentelemetry-collector/tree/main/connector
- https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/connector
