OpenTelemetry が『可観測性の業界標準』として地位確立
従来の可観測性（Observability）は、Datadog・New Relic等の各ベンダー独自SDKを使い、ベンダーロックインが課題でした。OpenTelemetry（OTel）はCNCFがホストする業界標準で、分散トレーシング・メトリクス・ログを統一形式で計装し、後続のバックエンド（Datadog・Honeycomb・自社Jaeger等）を自由に選べます。Microsoft・Google・AWS等が公式サポート、2025〜2026年で実質的に業界標準として定着しました。
採用すべき5つのシグナル
- Datadog等の特定ベンダー依存を解消したい
- マイクロサービス間の分散トレーシング
- ログ・メトリクス・トレースを統一管理
- OSS バックエンド（Jaeger・Tempo等）を活用
- 新規プロジェクトで標準準拠
主要コンポーネント
- SDK: 各言語のクライアントSDK
- Collector: テレメトリデータ収集・変換
- Traces: 分散トレーシング標準
- Metrics: メトリクス収集標準
- Logs: ログ統合（ベータ）
- Semantic Conventions: タグ・属性の標準
従来Datadog SDK/OTel比較
従来Datadog SDK: ベンダー固有・連携豊富・ロックイン。
OpenTelemetry: 業界標準・自由なバックエンド・ロックインなし。
Migration: OTelをDatadog Backendに送ることも可能。
使い分け: 新規プロジェクトはOTel・既存は段階移行。
実装パターン
(1) SDK統合: 言語別Auto-instrumentation
(2) Collector配置: サーバサイド or Sidecar
(3) Exporter設定: Datadog/Jaeger/Tempo等への送信
(4) Custom Spans: 業務ロジックの計装
(5) Sampling: 大量データの間引き戦略
本番採用の判断基準
- 本番実績: Microsoft・Google・AWS・ほぼ全業界
- パフォーマンス: 適切なサンプリングで影響最小
- 多言語対応: 主要言語すべてサポート
- バックエンド: Datadog/Honeycomb/Jaeger/自社
- 移行コスト: 既存ベンダーSDKからの段階移行
採用しない方が良いケース
- シングルサービス・分散システムでない
- 既存可観測性運用が完全に機能している
- 運用エンジニア少ない・学習コスト避けたい
- OTel未対応の特殊環境
実装で詰まる3つの落とし穴
- サンプリング設計: コストと網羅性のバランス
- Collector運用: スケーリング・障害対応
- Semantic Conventions: 属性命名の一貫性
30日学習プラン
- 1週目: OpenTelemetry概念・SDK統合
- 2週目: Auto-instrumentation・Custom Spans
- 3週目: Collector設定・Exporter選定
- 4週目: 本番運用・サンプリング・コスト最適化
関連リンク
分散トレーシングは 分散トレーシング実践、Sentryは Sentry深掘り、Observability全般は Observability実践 を参照してください。
