OpenTelemetry（OTel）は、ベンダー非依存の分散トレーシング・メトリクス・ログ収集の標準仕様です。マイクロサービス時代の必須技術になりつつあり、主要オブザーバビリティツール（Datadog、New Relic等）が広く対応しています。本記事では、OpenTelemetryの基本を入門レベルで解説します。
OpenTelemetryとは
OpenTelemetryは、CNCF主導のオブザーバビリティ標準で、計装（instrumentation）・収集（collector）・送信（exporter）を統一的に扱えます。アプリにOTel SDKを組み込んでおけば、配信先のバックエンド（Datadog、Tempo、Honeycombなど）を後から自由に変更できます。
3つのシグナル
- Trace：処理の流れを時系列で記録（リクエストごとに分散トレース）
- Metric：数値の時系列データ（CPU、レイテンシ、エラー率など）
- Log：構造化ログ（traceIDと紐付けて分析可能）
主な構成要素
- SDK / Instrumentation：アプリ側に組み込むライブラリ
- Collector：エージェント/ゲートウェイとして受信・加工・転送
- Exporter：保存先（Datadog、Jaeger、Tempo、CloudWatchなど）へ送信
自動計装の例（Node.js）
npm i @opentelemetry/sdk-node @opentelemetry/auto-instrumentations-node
// instrumentation.js
const { NodeSDK } = require('@opentelemetry/sdk-node');
const { getNodeAutoInstrumentations } = require('@opentelemetry/auto-instrumentations-node');
new NodeSDK({
instrumentations: [getNodeAutoInstrumentations()],
}).start();# 起動時にロード
node --require ./instrumentation.js index.jsこれだけでExpress・PostgreSQL・Redisなど主要ライブラリのトレースが自動で取得できます。
Collectorの役割
Collectorはバックエンドへの直接接続を中継し、サンプリング・属性追加・複数送信先への分岐などを担います。これにより、アプリ側のコードを変えずに送信先を切り替えられます。
分散トレースの威力
マイクロサービスでは、1リクエストが複数サービスを跨ぐため「どこで遅延しているか」が見えにくくなりがちです。OTelでtraceIDを伝播させれば、フロント → API → 認証 → DB → 外部API…といった経路を1つのタイムラインで可視化できます。
対応バックエンド
- OSS：Jaeger、Tempo、Loki、Prometheus
- SaaS：Datadog、New Relic、Honeycomb、Lightstep
- クラウド：AWS X-Ray、Google Cloud Trace、Azure Monitor
導入のコツ
- まず自動計装で全体可視化、足りないところに手動Spanを追加
- サンプリングを適切に設定してコストを抑える
- traceID をログに含めて、ログとトレースを紐付ける
まとめ
OpenTelemetryは「オブザーバビリティのベンダーロックインを解消する」標準仕様です。SDK + Collector + Exporterの3要素を理解しておけば、将来送信先を切り替える際にも安心。マイクロサービス時代の運用に必須の技術として、まずは小さなアプリから自動計装を試してみてください。
