OTLP（OpenTelemetry Protocol）は、トレース・メトリクス・ログなどの観測データをシステム間で送るための規約です。一方、OpenTelemetry Collectorは、データを受信し、必要に応じて加工し、別の送信先へ渡す実行プロセスです。アプリからOTLPでCollectorへ送る構成は一般的ですが、OTLP自体がCollectorを意味するわけではなく、Collectorがデータの保存・検索画面を提供するわけでもありません。
1. OTLPとCollectorは別のもの
OTLPはデータを送受信する規約
OTLPは、OpenTelemetryの観測データを送る際のデータ形式と通信方式を定めます。アプリ内のSDKやAgentが作ったSpanなどを、別のプロセスへ渡す共通の方法です。
OTLPはgRPCとHTTPの伝送方式を定義しています。HTTPではProtobufをバイナリまたはJSON形式で扱えますが、利用するエクスポーターと受信口の実装・設定が一致していなければ受信できません。
「OTLPを有効化した」というだけでは、どこへ送るか、誰が受けるかは決まりません。まずは送信元、宛先、プロトコル、ネットワーク経路を特定します。
Collectorは受信と転送を担うプロセス
Collectorはアプリと観測バックエンドの間に置ける、ベンダー中立のサービスです。OTLPの受信口を開き、処理し、宛先へ渡せます。構成によっては他の形式を受けたり、OTLP以外の形式へ出したりもできます。
ただしCollectorの使用は必須ではありません。バックエンドが対応する受信口を備えていれば、アプリから直接送れる場合もあります。複数アプリの送信設定を共通化したい、フィルタや転送先を集中管理したい場合にCollectorが役立ちます。
Collectorは通常、長期保存やトレースの検索画面そのものではありません。表示や分析には、別途対応するバックエンドを用意します。
2. データが通る道筋を読む
receiverが入力を受ける
Collectorのreceiverはデータの入口です。otlp receiverにHTTPまたはgRPCの受信口を設定すると、対応するクライアントからデータを受け取れます。
慣例的なポートはOTLP/gRPCが4317、OTLP/HTTPが4318です。HTTPでトレースを送る標準的なパスは/v1/tracesで、メトリクスとログにはそれぞれ/v1/metrics、/v1/logsを使います。
ポート番号は設定次第で変えられます。4318へgRPCを送ったり、4317へHTTPを送ったりしないよう、両端の方式を明示的に合わせてください。
processorとexporterが経路をつなぐ
processorはデータを転送途中で処理する部品です。例としてbatchはデータをまとめて後続へ渡します。processorは必要に応じて選びますが、初学者は「受けたものに何を加え、何を失うか」を意識すると設定を読みやすくなります。
exporterは出口で、別のCollectorやバックエンドへ送ります。ローカル確認用のdebug exporterならCollectorのログへ受信データを出せますが、永続保存するバックエンドにはなりません。
この3種類の部品を定義するだけでは動きません。service.pipelinesで、信号ごとにreceiver、processor、exporterを結び、実際の経路として有効にします。
3. 最小のトレース用パイプライン
設定例を読み解く
次はCollectorの設定ファイル例です。HTTPとgRPCを同一ホストのループバックアドレスで待ち受け、受けたトレースをbatch処理の後にCollector自身のログへ表示します。アプリも同じホスト上にあるローカル検証用です。
receivers:
otlp:
protocols:
grpc:
endpoint: 127.0.0.1:4317
http:
endpoint: 127.0.0.1:4318
processors:
batch: {}
exporters:
debug:
verbosity: detailed
service:
pipelines:
traces:
receivers: [otlp]
processors: [batch]
exporters: [debug]アプリ側はOTLP/HTTPの場合、共通endpointをhttp://localhost:4318、通信方式をhttp/protobufに設定します。Collectorの設定例はあくまで構造を読むためのもので、使用する配布版・バージョンで各コンポーネントが含まれるか確認してください。デバッグ用の詳細ログは機密データを出し得るため、検証後に無効化します。
pipelineは信号ごとに分ける
上のtraces pipelineはトレース専用です。otlp receiverがメトリクスやログを受け取れる設定でも、対応するmetricsまたはlogs pipelineを定義していなければ、その信号を目的のexporterへ転送する構成にはなりません。
たとえばメトリクスも必要なら、対応するprocessorとexporterを検討したうえでservice.pipelines.metricsを追加します。全信号を機械的に同じ宛先へ送るのではなく、バックエンドの対応と費用を確認してください。
Collectorをコンテナで動かすと、ループバックアドレスはコンテナの内部です。別コンテナから接続する構成では待受アドレスとアプリ側の宛先を別途設計し、必要以上に外部公開しないようにします。
4. endpointの指定で迷うところ
共通設定と信号別設定はパスの扱いが違う
OTLP/HTTPの共通endpointをOTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4318とすれば、SDK側はトレースなどに対応するパスを追加します。一方、信号別のOTEL_EXPORTER_OTLP_TRACES_ENDPOINTを使う場合は、通常http://localhost:4318/v1/tracesまで指定します。
この違いを見落として/v1/tracesを二重に付けたり、信号別URLからパスを省いたりすると、受信口の404などにつながります。利用する言語の実装と受信側の期待するURLを両方確認します。
OTLP/gRPCではHTTPの/v1/tracesパスを指定しません。ポートとURLの見た目だけで判断せず、OTEL_EXPORTER_OTLP_PROTOCOLの値を確認してください。
AgentやSDKの既定値を混同しない
OpenTelemetry Java Agent 2.0以降はOTLPの既定プロトコルとしてhttp/protobufを使います。一方、一般的なSDKの自動設定はgrpcを既定とするため、同じ「OTLPを使用」という説明でも送信先ポートが異なり得ます。
テストでは方式とendpointを両方明示し、Collectorのreceiverの有効化、送信元からの到達性、Collectorのログ出力を順番に確かめます。接続できない場合の詳細な原因は、まず「Spanが生成されているか」と「Collectorが受信できるか」を分けて調べます。
5. 実務でCollectorを置く判断
直接送信と中継の違い
一つのアプリから一つのバックエンドへ送り、追加処理も不要なら直接送信は構成が単純です。受信口がOTLPに対応していることと、通信の認証・TLSを確認します。
複数のアプリで送信先を共通化したい、機密属性を除く処理を一箇所で管理したい、バックエンドの切替をアプリへ波及させたくないならCollectorの中継が有用です。ただし、中継点が停止すれば影響範囲も広がるため、Collector自体の可用性と監視が必要です。
小さく始める場合はアプリ→Collector→debug exporterで受信まで確認し、それから安全な認証設定と本来のバックエンド向けexporterを追加します。実運用の接続情報をサンプル設定へ直書きしません。
セキュリティと運用を別途設計する
ローカル検証の127.0.0.1は同一ネットワーク名前空間からしか到達できません。別ホストや別コンテナのアプリから受けたい場合は、明示的な待受アドレス、ネットワーク制限、TLS、必要に応じた認証を設計します。単に0.0.0.0へ変更して公開してはいけません。
Collectorで処理できるデータにはURL、属性、場合によっては個人情報が含まれます。受信前・加工後・exporterの宛先で何が残るかを点検します。debugの詳細ログを本番で常時有効にすることも避けます。
転送先障害時のキューや再試行、処理量、メモリ制限は使用するコンポーネントと配布版の設定に依存します。Collectorを置いただけで欠損がなくなるわけではないため、用途に応じて運用設定を検証します。
まとめ
OTLPは送受信の規約、Collectorはreceiver・processor・exporterをpipelineで結ぶ中継プロセスです。4317のgRPCと4318のHTTPは一般的な組み合わせですが、実際は両端の設定が優先します。最小構成で受信を確認した後、保存先・認証・TLS・可用性を独立して設計しましょう。
