マイクロサービスやクラウドネイティブなシステムが主流になるにつれて、トレース・メトリクス・ログを統合的に収集・転送する仕組みの重要性が増しています。OpenTelemetry Collectorは、こうしたテレメトリーデータの収集パイプラインをベンダーに依存せず構築できるオープンソースのエージェントです。アプリケーションSDKから送られたデータを受信し、加工・フィルタリングを経て、任意のバックエンド（Prometheus、Jaeger、Datadog、New Relicなど）へ転送します。

2026年2月時点でCollectorのコアバージョンはv0.146系（API v1.52系）に到達しており、200を超えるコンポーネントが利用可能です（出典: OpenTelemetry公式）。

OpenTelemetryの全体像とCollectorが担う役割

OpenTelemetryは、テレメトリーデータの計装・収集・送信を標準化するCNCF（Cloud Native Computing Foundation）のオープンソースプロジェクトです。各言語向けのSDK、自動計装エージェント、プロトコル仕様（OTLP）、そしてCollectorの4つが主な構成要素となっています。

Collectorはこのエコシステムの中で「データの中継・加工ハブ」として機能します。SDKが生成したテレメトリーを集約し、バッチ処理やサンプリングといった加工を施してからバックエンドへ転送する、いわばテレメトリーパイプラインの中核です。

SDK直接送信との使い分け

アプリケーションSDKから直接バックエンドへデータを送信する構成も可能ですが、Collectorを介在させると次のような利点があります。

観点SDK直接送信Collector経由
構成の単純さシンプル（中継不要）Collectorの運用が必要
バックエンド切替アプリ側の設定変更が必要Collector設定のみで完結
データ加工SDK側で実装Processor群で柔軟に対応
リトライ・バッファSDK依存永続キューによる耐障害性
マルチバックエンド送信SDKごとに実装Exporterを追加するだけ

開発環境やシンプルな構成ではSDK直接送信で十分ですが、本番環境ではCollectorを配置してバックエンド非依存のパイプラインを構築するのが一般的です。

コンポーネント構成と内部アーキテクチャ

OpenTelemetry Collectorは5種類のコンポーネントで構成されています。日本語の記事ではReceiver・Processor・Exporter・Extensionの4つを取り上げるケースが多いですが、比較的新しいConnectorも含めて理解することが重要です。

Receiver（受信）

外部からテレメトリーデータを取り込むエントリーポイントです。プッシュ型（OTLP gRPC/HTTPなど）とプル型（Prometheusスクレイピングなど）の両方をサポートしています。

代表的なReceiver:

  • otlp — OTLP gRPC（ポート4317）/ HTTP（ポート4318）でデータを受信
  • prometheus — Prometheusエンドポイントをスクレイピング
  • jaeger — Jaeger形式のトレースデータを受信
  • kafka — Apache Kafkaからメッセージを読み取り

Processor（加工）

受信したデータをバックエンドへ送る前に変換・フィルタリング・集約する処理レイヤーです。パイプライン内で定義した順序に従って直列に適用されます。

主要なProcessor:

  • batch — 一定件数または一定時間でまとめてエクスポート（ネットワーク効率向上）
  • memory_limiter — メモリ使用量を監視し、閾値超過時にバックプレッシャーを発生
  • attributes — 属性の追加・削除・変換
  • filter — 条件に合致するデータを除外
  • tail_sampling — トレース単位でサンプリング判定

Exporter（送信）

加工済みデータをバックエンドサービスへ転送する出口です。1つのパイプラインに複数のExporterを定義してマルチバックエンド送信も可能です。

代表的なExporter:

  • otlp / otlphttp — OTLP形式で他のCollectorやバックエンドへ送信
  • prometheus — Prometheusがスクレイプ可能なエンドポイントを公開
  • prometheusremotewrite — Prometheus Remote Write APIへプッシュ
  • debug — 標準出力にデータをダンプ（開発・デバッグ用）
  • awsxray / googlecloud — クラウドベンダー固有のバックエンドへ送信

Connector（パイプライン間ブリッジ）

Connectorは、あるパイプラインのExporter側と別のパイプラインのReceiver側を橋渡しするコンポーネントです。パイプライン間でデータを変換・複製する際に利用します。

たとえばspanmetricsコネクターは、トレースパイプラインからスパンデータを受け取り、リクエスト数・レイテンシなどのメトリクスを自動生成してメトリクスパイプラインへ流します。従来はSpan Metrics Processorとして実装されていた機能が、Connectorとして再設計されました。

connectors:
  spanmetrics:
    dimensions:
      - name: http.method
      - name: http.status_code

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [spanmetrics]  # connectorをexporterとして指定
    metrics:
      receivers: [spanmetrics]  # 同じconnectorをreceiverとして指定
      processors: [batch]
      exporters: [prometheus]

Extension（拡張機能）

テレメトリーデータのパイプライン外で動作する補助機能です。Collectorの運用管理に関わる機能を提供します。

  • health_check — /health エンドポイントでCollectorの稼働状態を公開
  • zpages — デバッグ用のWebインターフェースを提供
  • file_storage — 永続キュー用のファイルストレージを提供
  • basicauth — Receiverへの認証を追加

Pipelineの定義（Service セクション）

各コンポーネントはservice.pipelinesセクションで組み合わせて初めて動作します。traces・metrics・logsの3種類のシグナルごとにパイプラインを定義します。

service:
  extensions: [health_check]
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlp/backend]
    metrics:
      receivers: [otlp, prometheus]
      processors: [memory_limiter, batch]
      exporters: [prometheusremotewrite]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp/backend]

Processorの記述順序がそのまま処理順序になる点に注意が必要です。memory_limiterは常にパイプラインの先頭に配置するのが推奨されています。

ディストリビューションの種類と選び方

OpenTelemetry Collectorには複数のディストリビューション（配布形態）があり、用途に応じて選択します。

Core（コア）

最小限のコンポーネントのみを含む公式ビルドです。OTLP Receiver/Exporter、debug Exporterなど基本的なコンポーネントだけが含まれます。Dockerイメージは otel/opentelemetry-collector で提供されています。

Contrib（コントリビュート）

コミュニティが開発した多数のコンポーネントを含む拡張ビルドです。Prometheus Receiver、各種クラウドベンダー向けExporterなど、実用的な構成を組む場合はこちらを利用するのが一般的です。Dockerイメージは otel/opentelemetry-collector-contrib です。

ベンダーディストリビューション

各クラウドベンダーや可観測性プラットフォームが独自に配布しているビルドもあります。

  • AWS Distro for OpenTelemetry (ADOT) — AWS X-Ray、CloudWatch向けに最適化されたCollector（aws-otel-collector）
  • Splunk OpenTelemetry Collector — Splunk Observability Cloud向けの拡張ビルド
  • Grafana Alloy — Grafana Labsが提供するCollectorベースのエージェント

カスタムビルド（OCB）

OpenTelemetry Collector Builder（OCB）を使えば、必要なコンポーネントだけを選んでカスタムビルドを生成できます。不要なコンポーネントを除外することでバイナリサイズの削減やセキュリティリスクの軽減につながります。

コンポーネントの安定性レベル

各コンポーネントには安定性レベルが設定されています。Development → Alpha → Beta → Stable → Deprecated の順で成熟度が示されており、本番利用の際はBeta以上を選ぶのが安全です。各コンポーネントのREADMEに安定性が記載されています（出典: OpenTelemetry Collector GitHub）。

デプロイメントパターンの選択

Collectorのデプロイには3つの代表的なパターンがあります。システム規模や要件に応じた適切な選択が、運用品質を大きく左右します。

Agentパターン（サイドカー / DaemonSet）

各ホストまたはPodごとにCollectorを配置する方式です。Kubernetesの場合はDaemonSet（ノードごとに1つ）やSidecar（Podごとに1つ）として展開します。

利点: アプリケーションからの通信がローカルで完結するためレイテンシが低い。ホストメタデータの自動付与が容易。

欠点: Collectorインスタンスの数がノード/Pod数に比例するため、リソース消費が増加する。

Gatewayパターン（集約型）

1台以上のCollectorを集約ゲートウェイとして配置し、複数のAgentやアプリケーションからデータを受け取る方式です。KubernetesではDeploymentとして展開し、Serviceで負荷分散します。

利点: データの集約処理（tail sampling、レート制限など）を一元管理できる。バックエンドへの接続数を抑制できる。

欠点: ゲートウェイがSPOF（単一障害点）になりうる。高可用性にはレプリカとロードバランサーが必要。

No-Collectorパターン（SDK直接送信）

Collectorを一切使わず、SDKから直接バックエンドへテレメトリーを送る方式です。

利点: 運用コンポーネントが減りシンプル。開発環境に最適。

欠点: バックエンド変更時にアプリ設定の変更が必要。加工やバッファリング機能が限定的。

パターン推奨環境スケーラビリティ運用負荷
Agent本番（標準的）ノード数に連動中
Gateway大規模・マルチクラスタ水平スケール可能高
Agent + Gateway本番（推奨構成）高い柔軟性高
No-Collector開発・検証制約あり低

多くの本番環境では、AgentパターンとGatewayパターンを組み合わせた2段構成が採用されています。各ノードのAgentがローカルで収集・軽量加工を行い、Gatewayで集約処理とバックエンドへの送信を担当する構成です。

Docker / Docker Composeで始めるクイックスタート

OpenTelemetry Collectorの動作確認に最も手軽な方法が、Docker Composeを使ったローカル起動です。

設定ファイルの作成

まず、Collector用の設定ファイル otel-collector-config.yaml を作成します。

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:
    send_batch_size: 1024
    timeout: 5s

exporters:
  debug:
    verbosity: detailed

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [debug]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [debug]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [debug]

Docker Composeファイル

version: "3.9"
services:
  otel-collector:
    image: otel/opentelemetry-collector-contrib:latest
    command: ["--config=/etc/otelcol/config.yaml"]
    volumes:
      - ./otel-collector-config.yaml:/etc/otelcol/config.yaml:ro
    ports:
      - "4317:4317"   # OTLP gRPC
      - "4318:4318"   # OTLP HTTP
      - "8888:8888"   # Prometheus metrics (Collector自身)
      - "13133:13133" # health_check
    restart: unless-stopped

起動と動作確認

docker compose up -d

起動後、ヘルスチェックエンドポイントで稼働を確認できます。

curl http://localhost:13133/

OTLPでテスト送信するには、公式の telemetrygen ツールが便利です。

docker run --rm --network host \
  ghcr.io/open-telemetry/opentelemetry-collector-contrib/telemetrygen:latest \
  traces --otlp-insecure --traces 5

debug Exporterの出力は docker compose logs otel-collector で確認できます。

KubernetesへのデプロイとHelm Chartの活用

Kubernetes環境では、公式のHelm Chartを使うとCollectorの展開が効率化されます（出典: OpenTelemetry Helm Charts）。

Helmリポジトリの追加とインストール

helm repo add open-telemetry \
  https://open-telemetry.github.io/opentelemetry-helm-charts
helm repo update

DaemonSetモード（Agentパターン）でインストールする場合は以下のとおりです。

helm install otel-agent open-telemetry/opentelemetry-collector \
  --set image.repository="otel/opentelemetry-collector-k8s" \
  --set mode=daemonset

Gatewayパターンで展開する場合は mode=deployment を指定します。

helm install otel-gateway open-telemetry/opentelemetry-collector \
  --set image.repository="otel/opentelemetry-collector-k8s" \
  --set mode=deployment \
  --set replicaCount=2

values.yamlによるカスタム設定

Collectorの設定は config キー配下にYAMLで記述します。

# values.yaml
mode: daemonset
image:
  repository: otel/opentelemetry-collector-contrib
config:
  receivers:
    otlp:
      protocols:
        grpc:
          endpoint: 0.0.0.0:4317
  processors:
    memory_limiter:
      check_interval: 1s
      limit_mib: 512
      spike_limit_mib: 128
    batch:
      send_batch_size: 1024
  exporters:
    otlp:
      endpoint: "otel-gateway.monitoring:4317"
      tls:
        insecure: true
  service:
    pipelines:
      traces:
        receivers: [otlp]
        processors: [memory_limiter, batch]
        exporters: [otlp]

Helm ChartにはPresetsと呼ばれる機能もあり、kubernetesAttributesやclusterMetricsを有効化するだけでKubernetes固有のメタデータ収集設定を自動生成できます。

Prometheus連携の設定パターン

OpenTelemetry CollectorとPrometheusの連携は、大きく2つの方向で行えます。

Prometheus Receiverによるスクレイピング

既存のPrometheusターゲットのメトリクスをCollectorで直接スクレイピングし、OTLP形式に変換して転送する構成です。

receivers:
  prometheus:
    config:
      scrape_configs:
        - job_name: "my-service"
          scrape_interval: 30s
          static_configs:
            - targets: ["app:8080"]

exporters:
  otlp:
    endpoint: "backend:4317"

service:
  pipelines:
    metrics:
      receivers: [prometheus]
      processors: [batch]
      exporters: [otlp]

2025年以降、Prometheus Receiverのネイティブヒストグラム対応（receiver.prometheusreceiver.EnableNativeHistogramsフィーチャーゲート）がStable化し、デフォルトで有効となっています。

Prometheus ExporterでCollectorからメトリクスを公開

Collectorが受信したOTLPメトリクスをPrometheus形式で公開し、既存のPrometheusサーバーからスクレイプさせる構成です。

exporters:
  prometheus:
    endpoint: "0.0.0.0:8889"
    resource_to_telemetry_conversion:
      enabled: true

Remote Write APIへ直接プッシュしたい場合はprometheusremotewrite Exporterを使います。GrafanaクラウドやThanos、Cortexなどへの送信に適しています。

本番運用で押さえるべき設計指針

開発環境での動作確認から本番運用に進む段階で、考慮すべきポイントがいくつかあります。

メモリ制限とバッチ処理の調整

memory_limiter ProcessorはCollectorのOOM（Out of Memory）を防ぐ最重要コンポーネントです。パイプラインの先頭に必ず配置し、コンテナやPodのメモリ上限の80%程度をlimit_mibに設定します。

processors:
  memory_limiter:
    check_interval: 1s
    limit_mib: 1536      # コンテナ上限2GBの場合
    spike_limit_mib: 384  # limit_mibの25%程度
  batch:
    send_batch_size: 2048
    send_batch_max_size: 4096
    timeout: 10s

exporters:
  otlp:
    endpoint: "backend:4317"
    sending_queue:
      enabled: true
      num_consumers: 10
      queue_size: 5000
      storage: file_storage
    retry_on_failure:
      enabled: true
      initial_interval: 5s
      max_interval: 30s
      max_elapsed_time: 300s

extensions:
  file_storage:
    directory: /var/lib/otelcol/queue
    timeout: 10s

service:
  extensions: [file_storage, health_check]
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlp]

永続キューによるデータ損失の防止

Exporterのsending_queueをファイルストレージと組み合わせると、Collectorの再起動やバックエンド障害時にもデータを保持できます。file_storage Extensionを追加し、Exporterのstorageパラメータで参照する構成です。

永続キューが満杯になるとデータのドロップが発生するため、queue_sizeはピーク時のスループットとバックエンド復旧にかかる時間を見積もって設定します。リトライのデフォルトは最大5分間（max_elapsed_time: 300s）で、指数バックオフ＋ジッターで再送を試みます（出典: OpenTelemetry Resiliency）。

Collectorの水平スケーリング

Gatewayパターンで運用する場合、負荷増大に応じてCollectorレプリカを水平に増やせます。ただし、Tail Samplingなど「トレースID単位の処理」を行うProcessorがある場合は、同一トレースIDのスパンが同じCollectorインスタンスに到達する必要があります。これにはロードバランサーでトレースIDベースのルーティングを実装するか、loadbalancing Exporterを用いて2段構成にする方法が有効です。

キャパシティプランニングでは、Collector自身の内部メトリクス（後述）を基にCPU使用率・メモリ使用量・キュー占有率を監視し、スケールの判断基準を定めます。

Collector自身のモニタリング（Internal Telemetry）

Collectorはデフォルトでポート8888にPrometheus形式の内部メトリクスを公開しています。監視すべき主要メトリクスは以下のとおりです（出典: OpenTelemetry Internal Telemetry）。

メトリクス名意味
otelcol_receiver_accepted_spansReceiverが正常に受け入れたスパン数
otelcol_receiver_refused_spansReceiverが拒否したスパン数
otelcol_exporter_sent_spansExporterが送信に成功したスパン数
otelcol_exporter_send_failed_spansExporterが送信に失敗したスパン数
otelcol_exporter_queue_size送信キューの現在サイズ
otelcol_exporter_queue_capacity送信キューの最大容量
otelcol_process_memory_rssCollectorプロセスのメモリ使用量

内部メトリクスをOTLP経由で外部バックエンドへプッシュすることも可能です。

service:
  telemetry:
    metrics:
      level: detailed
      readers:
        - periodic:
            exporter:
              otlp:
                protocol: http/protobuf
                endpoint: https://monitoring-backend:4318
    logs:
      level: info
      encoding: json

otelcol_exporter_queue_size が queue_capacity に近づいている場合はバックエンドへの送信が追いついていないサインであり、Collectorのスケールアウトやバックエンド側の改善が必要です。

よくある質問（FAQ）

OpenTelemetry Collectorとは何ですか？

OpenTelemetry Collectorは、テレメトリーデータ（トレース・メトリクス・ログ）の受信・加工・転送を担うベンダー非依存のエージェントです。アプリケーションSDKとバックエンドの間に配置し、データパイプラインを構成します。Receiver・Processor・Exporter・Connector・Extensionの5つのコンポーネントを組み合わせてYAMLで設定します。

オープンテレメトリ（OpenTelemetry）とは何ですか？

テレメトリーデータの計装・収集・送信を標準化するCNCFのオープンソースプロジェクトです。各言語向けSDK、OTLP（OpenTelemetry Protocol）、Collectorなどを通じて、特定ベンダーに依存しない可観測性基盤を構築するための枠組みを提供しています。

PrometheusとOpenTelemetryの違いは何ですか？

Prometheusは時系列メトリクスの収集・保存・クエリに特化した監視システムであるのに対し、OpenTelemetryはメトリクスに加えてトレースとログも包括するテレメトリー収集の標準規格です。両者は競合ではなく補完関係にあり、OpenTelemetry CollectorのPrometheus ReceiverやExporterを使って連携させるのが一般的な構成です。

OpenTelemetry形式（OTLP）とは何ですか？

OTLP（OpenTelemetry Protocol）は、テレメトリーデータの伝送に用いるプロトコル仕様です。gRPCとHTTP/Protobufの2つのトランスポートをサポートし、トレース・メトリクス・ログを統一的に扱えます。主要な可観測性バックエンドの多くがOTLPのネイティブ受信に対応しており、ベンダーロックインを避けたデータ送信が実現します。