OpenTelemetryとは? Collectorとバックエンドの3層でわかる仕組み | Guance

OpenTelemetry(オープンテレメトリー、略称 OTel)とは、トレース・メトリクス・ログという3種類のテレメトリーデータを生成・収集・転送するためのオープンな標準規格、およびその実装群です。 CNCF(Cloud Native Computing Foundation)のプロジェクトで、OpenTracing と OpenCensus が統合して生まれました。重要なのは、OTel 自体はデータの「作り方と運び方」だけを決めるもので、データを保存・可視化するバックエンド(監視サービス)は含まない、という点です。

3層構造で理解する

OpenTelemetry を理解する最短ルートは、役割の3層で分けることです。

[アプリ] --(1) API/SDK--> [Collector] --(3) エクスポート--> [バックエンド]
        計装する              受け取り・加工・転送           保存・可視化・検索

第1層: API/SDK(計装)。 アプリケーションにテレメトリーを仕込む部分です。Java エージェントのような自動計装と、コードに明示的に書く手動計装があります。ここで「どのデータをどんな属性(タグ)つきで出すか」が決まります。

第2層: Collector(コレクター)。 テレメトリーを受け取り(receivers)、加工し(processors)、送り出す(exporters)中継基盤です。SDK から OTLP(OTel の標準プロトコル)で受け取り、バッチ化・フィルタ・マスキングを経て、複数のバックエンドへ同時に送れます。

第3層: バックエンド。 Datadog、New Relic、Jaeger、Grafana、Guance など、データを実際に保存・可視化するサービスやソフトウェアです。OTel はここを規定しません。

この分離が OTel の最大の価値です。計装(第1層)を一度 OTel でやれば、第3層のバックエンドは Collector のエクスポート設定を変えるだけで乗り換えられる — つまりベンダーロックインを避けられるのです。

Collector の役割 — なぜ直接送らないのか

SDK からバックエンドへ直接送ることもできますが、本番では Collector を挟むのが一般的です。理由は3つ。

関連ガイドAPMとは？仕組み・監視項目・オブザーバビリティとの違いを実務で解説

バッチ化と再送: 送信をまとめて効率化し、障害時はキューイングで取りこぼしを防ぐ
加工の一元化: 個人情報のマスキング、属性の付与・削除、サンプリングを Collector 設定で集中管理できる
マルチ送信: 同じデータを検証中の新バックエンドと現行バックエンドに並行送信(デュアルライト)できる

最小構成のイメージ(概念例):

receivers:
  otlp:            # SDK からの標準プロトコルを受ける
    protocols:
      grpc:
      http:
processors:
  batch:           # まとめて送る
exporters:
  otlphttp/backend_a: { endpoint: "https://a.example.com" }
  otlphttp/backend_b: { endpoint: "https://b.example.com" }  # 並行送信
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/backend_a, otlphttp/backend_b]

実際のデュアルライト構築(Datadog と新バックエンドの並行稼働)は、英語版「Datadog to OpenTelemetry」に完全な YAML と言語別の切り替え表があります。

導入の進め方 — 4ステップ

対象を絞る: まず主要な取引経路 1〜2 本だけに自動計装を入れる
Collector を置く: OTLP で受けて現行バックエンドへそのまま転送する構成から始める
属性とサンプリングを整える: サービス名・環境・バージョンの属性を統一し、トラフィックに応じてサンプリング率を決める
バックエンドを評価する: 必要ならエクスポーターを追加して第2のバックエンドと並行稼働し、照合する

概念の土台(トレース、span、RED 指標)が曖昧なら、先に「APMとは」を読むと、OTel の各層が何のためにあるか腹落ちします。

よくある質問

Q. OpenTelemetry と Jaeger の違いは何ですか?
OTel はテレメトリーの生成・収集・転送の標準(第1〜2層)、Jaeger はトレースの保存・可視化をするバックエンド(第3層)です。競合ではなく、OTel で集めて Jaeger に送る組み合わせが一般的です。

Q. OpenTelemetry は無料ですか?
規格と実装はオープンソースで無料です。コストがかかるのはデータを保存・可視化するバックエンド側で、製品によって料金モデルが異なります(比較は「APMツールおすすめ7選」)。

Q. すでに Datadog の SDK(ddtrace)を使っています。OTel に移行すべきですか?
ベンダー非依存にしたい、複数バックエンドを評価したいなら検討価値があります。言語別の切り替え表と環境変数の対応(DD_* → OTEL_*)は「Datadog to OpenTelemetry」にあります。なお、ddtrace 互換の受け口を持つバックエンドなら、計装を変えずに送り先だけ変える選択肢もあります(「ddtrace クイックスタート」)。

Q. Collector は必須ですか?
小規模検証なら SDK から直接送って構いません。本番運用では、バッチ化・マスキング・マルチ送信のために Collector を挟む構成が標準です。

Q. 対応している言語は?
Java、Go、Python、Node.js、.NET、Ruby、PHP、Rust など主要言語に SDK があり、多くに自動計装があります(各言語の最新の対応状況は公式ドキュメントで確認してください)。

3層構造で理解する

Collector の役割 — なぜ直接送らないのか

導入の進め方 — 4ステップ

よくある質問

次に読む

関連記事

お問い合わせ