📊 私のアプリケーションデータ、どこに送るべき？OpenTelemetryデータエクスポート完全ガイド

9月 12, 2026

—

cslab

in IT Security

こんにちは！今日は、私たちが開発するアプリケーションで収集された膨大なデータ（トレース、メトリクス、ログ）を、どのようにして目的の分析システムに送信できるのか、その全体的な道のりと核心的な方法について見ていきましょう。🧐

多くの方がデータを「どのように作成するか」に焦点を当てがちですが、「どのように送信するか」を知らなければ、データはアプリケーション内部に閉じ込められてしまいます。データの生成から最終目的地までの全体的な流れを理解することが重要です！

🗺️ データの壮大な旅：どこで生まれ、どこへ行くのか？

アプリケーションで生成されたテレメトリーデータが分析ツールに到達するまでの道のりは、大きく4つの段階に分けられます。

計測 (Instrumentation) 💻: 開発者がコードに特定のライブラリ（API Package）を使用して、「この操作は50msかかった」「ここでDB呼び出しを開始した」といったデータを生成する段階です。
標準化 (Standardization) 🏷️: 生成されたデータに、http.method = “GET”のように誰でも理解できる標準化されたラベル（Semantic Conventions）を付与する段階です。データの「意味」を統一するプロセスですね。
処理 (Processing) ⚙️: 収集されたデータをサンプリングしたり、フィルタリングしたりするなど、中間処理を行います。
エクスポート (Exporting) 🚀: 最後に、これらすべてのデータをJaeger、Prometheus、Datadogのような最終目的地に送信する段階です。今日の主役です！

この全体像を理解することは、各部分を個別に知ることよりもはるかに重要です。それでは、各段階の主要なアクターであるAPIとSemantic Conventionsが「エクスポート」とどのように異なるのかをまず確認していきましょう。

🤔 ちょっと待って、APIとSemantic Conventionsはデータを送信する役割ではないのですか？

結論から言うと、違います！これらはデータを「作成し」「説明する」重要な役割を担いますが、外部に「送信する」機能とはかけ離れています。

API Package: データを「生成」する建築家 🏗️

APIパッケージは、私たちのコード内でトレースデータ（Span）を開始したり、コンテキストを伝播したりするなど、テレメトリーデータを「作成する」ツールです。開発者がコードを通じて直接計測するためのインターフェースを提供します。

主な役割：

新しいスパン(Span)の開始と終了
スパンにイベントや属性(Attribute)を追加
サービス間のコンテキスト伝播

つまり、データを「生産」する最初の段階を担当します。しかし、このデータを特定のシステムにどのように送信するかという設定には一切関与しません。

Semantic Conventions: データに「ラベル」を貼る司書 🏷️

セマンティックコンベンションは、データの「内容」を標準化する約束事です。例えば、ある開発者がHTTPメソッドをhttp_methodと記録し、別の開発者がhttp.req.methodと記録した場合、データを統合して分析することは非常に困難になりますよね？

セマンティックコンベンションは、http.method、db.system、rpc.serviceのようにデータフィールドの名前を標準で定義し、どの言語やフレームワークで収集されたデータであっても一貫した意味を持つことを保証します。

主な役割：

トレース、メトリクス、ログデータの標準命名規則の定義
データの一貫性と相互運用性の保証

このように、データのコンテンツを標準化するだけであり、このデータをどこに「エクスポートするか」を決定する役割は果たしません。

🚀 真の主役登場：Exporter Package！

では、収集されたデータは一体誰がエクスポートするのでしょうか？それはまさにExporterがその役割を担います！

Exporterは、OpenTelemetry SDKが収集および処理したデータを、特定のバックエンド（分析システム）が理解できる形式に変換して送信するプラグインです。

様々な種類のExporterが存在し、目的に合わせて選択できます。

Console Exporter: データをターミナルコンソールに出力します。開発やデバッグ用途に非常に便利です。
OTLP Exporter: OpenTelemetryの標準プロトコル（OTLP）を使用してデータを送信します。特定のベンダーに依存せず、OpenTelemetryをサポートするすべてのバックエンドと柔軟に連携できます。
Vendor-specific Exporter: Jaeger、Prometheus、Zipkinなど、特定の分析ツールの固有フォーマットに合わせてデータを送信するExporterです。

🛠️ 実践例：コードでExporterを設定し、データを確認する

言葉だけの説明ではピンとこないですよね？Node.js環境でConsole Exporterを設定し、スパンデータがどのように生成され、外部に「出力」されるのかをコードで直接確認してみましょう。

1. コード設定 (Node.js)

ConsoleSpanExporterを使用してTracerProviderを設定するコードです。このコードは、生成されるすべてのスパン情報をコンソールに出力するように指示します。

// 必要なモジュールをインポート
const { NodeTracerProvider } = require('@opentelemetry/sdk-trace-node');
const { ConsoleSpanExporter, SimpleSpanProcessor } = require('@opentelemetry/sdk-trace-base');
const { registerInstrumentations } = require('@opentelemetry/instrumentation');
const { HttpInstrumentation } = require('@opentelemetry/instrumentation-http');

// 1. Exporter設定: すべてのスパンをコンソールに出力するようにConsoleSpanExporterを作成します。
const consoleExporter = new ConsoleSpanExporter();

// 2. Provider設定: Tracerを生成および管理する主体です。
const provider = new NodeTracerProvider();

// 3. ProviderとExporterの接続: SimpleSpanProcessorを通じて、スパンが終了するたびに即座にconsoleExporterに送信するように設定します。
provider.addSpanProcessor(new SimpleSpanProcessor(consoleExporter));

// 4. Provider登録: OpenTelemetry APIがこのProviderを使用するようにグローバルに登録します。
provider.register();

// 自動計測設定（例：HTTPリクエスト）
registerInstrumentations({
  instrumentations: [new HttpInstrumentation()],
});

console.log("✅ OpenTelemetry with ConsoleExporter is running...");

// テストのために簡単なHTTPサーバーを実行
const http = require('http');
http.createServer((req, res) => {
  res.end('Hello, World!');
}).listen(8080);

2. 生データ確認 (コンソール出力)

上記のコードを実行し、curl コマンドでサーバーにリクエストを送信すると、ターミナルに次のようなスパンデータ（生データ）が出力されるのが確認できます。これこそがConsoleExporterが「エクスポートした」結果です！

{
  "traceId": "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6",
  "parentId": undefined,
  "name": "HTTP GET",
  "id": "1a2b3c4d5e6f7a8b",
  "kind": 1,
  "timestamp": 1762021445123456,
  "duration": 15678,
  "attributes": {
    "http.method": "GET",
    "http.target": "/",
    "http.status_code": 200,
    "net.peer.ip": "::1"
  },
  "status": {
    "code": 0
  },
  "events": []
}

ご覧のように、http.methodのようなセマンティックコンベンションに従って名前が付けられたデータが、ExporterによってきれいなJSON形式で出力されました。もしJaegerにデータを送信したい場合は、ConsoleSpanExporterの代わりにJaegerExporterを設定するだけで済みます。

✨ まとめ

データ可観測性（Observability）パイプラインを構築する際、全体的なデータの流れを理解することは非常に重要です。

APIはデータを「生成」し、
Semantic Conventionsはデータに一貫した「意味」を与え、
Exporterは最終的にこのデータを目的の宛先に「送信」します。

これで、各コンポーネントがどのような役割を果たし、どのように調和して動作するのかが明確に理解できたでしょうか？皆さんのシステムに合ったExporterを選択し、散らばったデータを一箇所に集めて強力なインサイトを得てみてください！