先に要点
- OpenTelemetry(OTel) は、「 トレース」 「 メトリクス」 「 ログ」 の 3 シグナルを統一して扱う 観測性(Observability)の業界標準。CNCF(Cloud Native Computing Foundation)のプロジェクトで、Datadog / New Relic / Grafana / Jaeger / X-Ray など主要観測ツールがほぼ全て対応。
- 基本構造は SDK(アプリに計装)→ Collector(集約・変換・送信)→ Backend(可視化)。ベンダーロックインを避けて、後から観測ツールを切り替えやすい のが最大の価値。「計装は OTel 標準、可視化は好きなツール」 が成立する。
- 3 シグナルの役割: トレース = リクエストが複数サービスを跨ぐ経路」 「 メトリクス = 時系列の数値(CPU / メモリ / レイテンシ / エラー率)」 「 ログ = 個別のイベントテキスト。「全部繋いで因果を追える」 のが現代観測性の核心。
- 自動計装(Auto-Instrumentation)が成熟していて、Node.js / Java / Python / .NET / Go」 などは数行のセットアップで `主要ライブラリの呼び出しが全部トレースされる。「手書きで span を作る」 のは特殊なロジックだけで十分。
- 判断軸: 新規プロジェクトはほぼ常に OpenTelemetry」 「 既存システムは段階的に移行」 「 既存の独自エージェント(Datadog Agent など)から OTel への乗り換えはバックエンドが OTLP 対応していれば容易。「計装を OTel 標準にしておくと将来の移行コストが大きく下がる」 のが最大の戦略的価値。
「サービスが遅い」 「 エラーが多発」 のような問題が起きたとき、「どこで詰まっているか」 を素早く特定できるかは、観測性(Observability)の質で決まります。「Datadog 入れたから安心」 「 New Relic 使ってるから OK」 で終わると、「ベンダーを変える時に全部やり直し」 という落とし穴に当たります。
OpenTelemetry(OTel) は、計装を業界標準で書いておけば、バックエンドはあとから何にでも切り替えられる という考え方の標準仕様です。CNCF のプロジェクトとして主要ベンダー全てが対応しており、「現代の観測性のデファクトスタンダード」 と言える存在になっています。
この記事では、OTel の 3 シグナル・基本構造・自動計装・主要バックエンドとの連携 を、「これから観測性を入れる人」 向けに整理します。「なぜ OTel を選ぶか」 の戦略的視点も含めて理解できる構成にしています。
まず Observability(観測性)とは
OpenTelemetry を理解するには、まず 観測性」 の言葉を押さえると話が早い。
Monitoring と Observability の違い
「 Monitoring = 事前に決めた指標を監視する」(CPU、メモリ、エラー率など)、「 Observability = 内部の動作を外部から推測できる」 状態を作る。Observability があれば、「事前に想定していなかった問題でも分析できる」。マイクロサービス時代に重要性が増した概念。
3 つのシグナル
観測性を支える 3 つのデータ: Trace」 「 Metric」 「 Log。それぞれ違う粒度と役割を持ち、「組み合わせて使う」 ことで初めて 「問題の原因まで辿れる」。OTel はこの 3 つを 統一仕様で扱う。
マイクロサービス時代の課題
「 1 リクエストが 10 個のマイクロサービスを経由」 「 サービス間で言語もバラバラ」 「 各サービスが別の観測ツールを使っている」 → 端から端まで追えない。OTel は 「言語横断 + サービス横断 + ツール横断」 で観測性を統一する仕組み。
ベンダーロックインの問題
「 Datadog エージェントを全アプリに入れた → 移行コストが莫大」 のような事態。OTel で計装しておけば、「Collector の送信先を変えるだけ」 で別ベンダーへ切り替えできる。
OpenTelemetry の 3 シグナル
OTel の中心は Trace / Metric / Log の 3 種類のデータ(シグナル)。それぞれの役割を整理します。
| シグナル | 表すもの | 典型用途 | 例 |
|---|---|---|---|
| Trace | 「 リクエストが複数サービスを経由する経路 」 を span(個別の処理単位)の連なりとして表現 | 「 どこで時間がかかったか 」 を可視化、「分散システムの因果関係 」 を追う | API リクエスト → 認証 → DB クエリ → 外部 API → レスポンス の流れ |
| Metric | 「 時系列で集計された数値 」(カウンタ、ゲージ、ヒストグラム) | 「 全体傾向の監視」 「 アラート 」 | HTTP 5xx レート、レイテンシ p95、メモリ使用量、キャッシュヒット率 |
| Log | 「 個別のイベントテキスト 」(構造化ログ推奨) | 「 個別事案の詳細調査」 「 デバッグ 」 | 「 ユーザー X が支払いに失敗、エラーコード Y 」 のような個別イベント |
3 つを Trace ID で繋ぐ のが OTel の強み。「このリクエストの Trace を見る → 該当 span に紐づく Log を表示 → 関連 Metric も同時に見る」 が 1 つの画面で完結する設計。
OpenTelemetry の基本構造
OTel は SDK」 「 Collector」 「 Backend の 3 階層で動きます。
SDK(計装)
各言語(Node.js / Java / Python / .NET / Go / Ruby / PHP / Rust)で OTel SDK をアプリに組み込み、「span / metric / log」 を生成する。Auto-Instrumentation を使えば、主要ライブラリ(HTTP / DB / メッセージキュー)の呼び出しが 自動で計装される。
OTLP(プロトコル)
SDK から Collector / Backend にデータを送る OTel 公式プロトコル。「gRPC / HTTP/protobuf / HTTP/JSON」 の 3 形式に対応。ベンダー横断の共通プロトコル として機能する。
「SDK → Collector → Backend」 という 3 階層を分離することで、バックエンド変更の影響が Collector の設定だけで済む のが OTel の戦略的価値です。
Auto-Instrumentation で 5 分で始める
「 手書きで span を作るのが大変そう」 と思うかもしれませんが、現代の OTel は 自動計装 が成熟しており、多くの言語で 数行のセットアップで主要ライブラリの呼び出しが全部トレースされる。
「計装は最初に少し設定するだけで、あとは可視化ツールで好きなように分析」 という体験が現代の標準です。
主要バックエンドとの連携パターン
OTel のデータを送る先(バックエンド)は、用途で選び分けます。
| バックエンド | 特徴 | 典型用途 |
|---|---|---|
| Datadog | 商用 SaaS、UI が最も洗練、Trace / Metric / Log / RUM / Synthetics 統合 | エンタープライズ、「お金を払って全部任せたい」 |
| New Relic | 商用 SaaS、データ量課金、AI による異常検知が強い | 大規模プロダクション |
| Grafana スタック(Tempo / Loki / Mimir / Prometheus) | OSS、自前ホスト、UI は Grafana で統一 | コスト最適化、データを自社で持ちたい組織 |
| Jaeger(Trace 専用) | OSS、Trace に特化、軽量 | 「 Trace だけ見たい」 シンプルな構成 |
| AWS X-Ray | AWS マネージド、Lambda / ECS / API Gateway とのネイティブ連携 | AWS 中心のスタック |
| Honeycomb / Lightstep | 高カーディナリティに強く、「深い分析」 が得意 | 複雑なマイクロサービス環境 |
「Collector が間にいる」 ので、「 複数バックエンドに同時送信」 や 「本番は Datadog、開発は Jaeger」 のような使い分け が容易です。
サンプリング ── 全部送ると破綻する
本番環境で全 Trace をバックエンドに送ると、データ量で料金が破綻 」 「 ネットワーク帯域を圧迫 します。サンプリングが必須。
Head-based Sampling
` リクエストの先頭で 「この Trace を残すか」 を決める」。「常に 1% だけ残す」 「 重要度 high のリクエストは 100% 残す」 のような確率ベース。実装はシンプルだが、「重要なエラー Trace を捨てる」 リスク。
Tail-based Sampling
「 リクエスト完了後に、内容を見て残すか決める」。「エラーが起きた Trace は 100% 残す」 「 レイテンシが p95 を超えたものは残す」 など。重要な Trace を逃さないが、Collector で全 Trace を一時保持する必要があり、メモリ消費が大きい。
推奨パターン
「 Tail-based + エラー / 高レイテンシ優先」 が現代的。OTel Collector の 「tail_sampling processor」 で設定できる。「サンプリング率は通常 1〜10% 、エラーは 100% 」 が典型値。
コスト試算
「 Trace 1 件あたり 1〜10KB × リクエスト数 × 残す割合 = データ量」。Datadog などの商用 SaaS は GB 単位の課金なので、「サンプリング率を 1% 落とすだけで月数十万のコスト差」 になることも。
OTel が今、必須に近い理由
「観測性ツールはまだ Datadog Agent でいいのでは?」 という疑問への答え。
ベンダーの戦略的選択
Datadog / New Relic / Grafana など 主要ベンダーが OTel をネイティブ対応している。「独自エージェントは段階的に OTel SDK に置き換え」 の流れ。「OTel で書いておけば未来も安泰」 という安心感。
マルチクラウド時代
「 AWS と GCP と Azure を併用」 「 マネージドサービスと自前運用が混在」 する現代では、「単一ベンダーで全部監視」 が難しい。OTel の標準化が、マルチクラウド観測性の現実解。
OSS の充実
「 Grafana / Jaeger / Prometheus / Loki 」 などの OSS スタックが成熟し、「自前ホストでも商用 SaaS に近い体験」 が可能に。「コスト最適化」 で OSS を選ぶ組織が増えている。
OpenTelemetry に関するよくある質問
Q. Datadog Agent を使っているけど、OTel に移行する価値はありますか?
A. 中長期で見れば価値が大きい。短期的には Agent で十分動いていますが、ベンダー変更時 」 「 マルチクラウド対応」 「 OSS 観測スタックの併用 のような将来課題で OTel の標準化が効きます。新規サービスから OTel SDK で書き、既存は段階的に置き換え が現実的なルート。Datadog は OTel SDK もネイティブ受信できます。
Q. Auto-Instrumentation だけで十分?
A. 70〜80% のユースケースで十分。HTTP リクエスト / DB クエリ / 外部 API 呼び出しなど主要ライブラリの計装は自動で入る。ビジネスロジック固有の処理 」 「 重要なドメインイベント だけ手書き span で追加すれば、「労力対効果が高い計装」 になります。
Q. Collector って絶対必要?
A. 推奨だが必須ではない。SDK から直接バックエンドに送る構成も可能。ただし バックエンド切り替え」 「 サンプリング」 「 機密情報のマスキング」 「 障害時のバッファリング など、Collector があると 運用上のメリットが大きい。最初は SDK 直送で始めて、必要に応じて Collector を挟む構成も OK。
Q. ログも OpenTelemetry で扱うべき?
A. 既存のロガーから段階的に。Log シグナルは Trace / Metric より 仕様策定が遅れて成熟途上。「既存のロガー(winston / pino / log4j / logback)を OTel ログハンドラに繋ぐ」 形が現実的。Trace ID をログに自動付与できるのが OTel ログの価値。
Q. AWS Lambda で使えますか?
A. 使えます。AWS が公式に AWS Lambda OpenTelemetry Layer を提供。「Layer を Lambda に追加 + 環境変数で送信先指定」 で、「Lambda の自動計装 + X-Ray / Datadog などへの送信」 が可能。Cold Start 影響を考慮して 「軽量設定で開始」 がコツ。
Q. パフォーマンス影響はどれくらい?
A. 通常は無視できる程度(数 ms / リクエスト)。Auto-Instrumentation でも 「1 リクエストあたり 1〜5 ms 程度のオーバーヘッド」 が典型値。「 重い処理を sync で送る」 と影響が出るので、SDK は バックグラウンド送信 + バッファ」 のデフォルト設定を使う。Tail-based サンプリングは Collector のメモリを食うので注意。
Q. ローカル開発で OTel を試すには?
A. Jaeger を Docker で立てる のが最も手軽。「docker run -p 4317:4317 -p 16686:16686 jaegertracing/all-in-one」 で起動し、ブラウザで 「http://localhost:16686」 を開けば UI が見える。「本番は Datadog、開発は Jaeger」 のような構成が、「コストをかけずに開発で観測性を試す」 現実的なパターン。
まとめ
OpenTelemetry は 観測性のためのデファクトスタンダード として、現代の Web/API 開発で必須に近い技術になっています。「SDK で計装 → Collector で集約 → 任意のバックエンドで可視化」 という分離構造が、ベンダー変更や OSS 移行の自由度 を生むのが本質的価値です。
「新規プロジェクトはほぼ常に OTel」 「 既存システムも段階的に移行」 「 Auto-Instrumentation で素早く開始 → 必要に応じて手書き span 追加」 の流れで進めれば、「観測性が業務を救うフェーズ」 で困らないインフラを整えられます。「今は Datadog で十分」 という組織でも、計装を OTel 標準にしておくだけで、将来の選択肢が大きく広がります。
参考リンク
- OpenTelemetry: OpenTelemetry 公式
- OpenTelemetry Docs: Concepts
- CNCF: OpenTelemetry Project
- AWS Docs: OpenTelemetry on AWS
- Datadog: OpenTelemetry support