OpenTelemetryはアプリケーションのトレース、メトリクス、ログを標準化された方法で収集・転送するためのオープンソース仕様および実装群である。2019年5月、CNCFの後援のもとOpenTracingとOpenCensusという二つの先行プロジェクトが統合される形で誕生し、現在ではCNCF内でKubernetesに次ぐ規模のアクティビティを持つ。本稿ではOpenTelemetryの構造、合流の経緯、典型導入、DatadogやNew Relicとの関係を解説する。
この記事の目次
- Signal/SDK/Collectorの3層
- 二つの先行規格を統合した経緯
- 現場での導入パターン
- 商用Observabilityとの関係
- まとめ
Signal/SDK/Collectorの3層
OpenTelemetryの世界観は3つのSignal（Traces、Metrics、Logs）を統一的なデータモデルで扱う点に集約される。Traceは分散リクエストをSpanの木構造で表し、各SpanにはService、Operation、Status、Attributesなどが付与される。MetricはCounter、Gauge、Histogramといった型を持ち、ResourceとAttributeの組合せで多次元に分析できる。Logは2023年に仕様がStableとなり、TraceIDとの紐付けが標準化された。
アプリケーションには各言語のSDK（Go、Java、Python、JavaScript、.NET、Ruby、PHP等）を組み込み、自動計装（Auto-Instrumentation）ライブラリを使えば、フレームワーク経由のリクエストを自動的にSpanへ変換できる。送出されたデータはOpenTelemetry Collectorという中継エージェントを通り、Filter、Sampling、Batchなどの加工を経て、Datadog、Jaeger、Tempo、Prometheusなど任意のバックエンドへ転送される。
二つの先行規格を統合した経緯
観測の標準化は2016年、Ben Sigelmanら主導のOpenTracingがCNCFに採択された段階から本格化した。Sigelmanは元GoogleでDapper論文の著者の一人で、後にLightStepを創業している。同時期にGoogleはOpenCensusを公開し、トレースとメトリクスの両方を扱う野心的な仕様で対抗した。
二つの規格は機能的に重なる部分が多く、ユーザは「どちらを採るか」という不毛な選択を迫られていた。2019年5月、KubeCon EUの会場で両者が合流しOpenTelemetryとなる構想が公式発表された。Morgan McLean（Google）、Sarah Novotny、Bogdan Drutu、Ted Youngらが議論を牽引し、2021年2月にTracingの仕様がStableに、2023年にはLogsもStableへ到達。CNCFインキュベーションを経て、観測の世界標準としての地位を確立した。
現場での導入パターン
最短経路はAuto Instrumentationの導入で、JavaならJavaAgentを起動オプションで読み込ませるだけでSpring、JDBC、Kafkaなどの計装が自動で入る。Node.jsやPythonでもrequireやimport一行で広範囲がカバーされる。アプリ側の改修負担を最小にできるため、PoCから始めて段階的に手動計装を増やすのがよくある進め方だ。
Collectorは「Agent」と「Gateway」の2層構成が定石で、サイドカーまたはDaemonSetでアプリ近傍のAgentを置き、リージョン単位のGatewayへ集約してから外部に送る。Tail-based Samplingを使えばエラーや遅延の発生したTraceを優先的に保存できる。Resource属性にservice.name、deployment.environment、k8s.namespace.nameを揃えると、Trace/Log/Metricsの相関が綺麗に取れMTTRが大きく改善する。
商用Observabilityとの関係
OpenTelemetryは「観測データの収集と転送」を標準化する仕様であって、保存・可視化・アラートまでは含まない。そこは依然としてDatadog、New Relic、Splunk Observability、Grafana Cloud、Honeycombなどの商用サービスが担う。多くのベンダはOTLP（OpenTelemetry Protocol）受信に対応済みで、計装は標準・バックエンドは商用、というハイブリッドが現代的な選択肢だ。
この方針の利点はベンダロックインを軽減できる点で、Datadogが高いと感じたら同じ計装のままGrafana Tempoへ移行する、といった選択が現実的になる。一方で、ベンダ独自の魔法（AIによる異常検知、関連付け、UIの作り込み）を最大化するには専用SDKを使う選択もあり、組織のフェーズで判断が分かれる。OpenTelemetryをまず標準として置きつつ、機能差を見極めて補強するのが堅実だ。
まとめ
OpenTelemetryは観測の世界に共通言語を持ち込み、組織がベンダ選定の自由度を保ちながら計装に投資できる土台となった。Trace、Metric、Logの三本柱を統合的に扱える点、Collectorによる柔軟な転送が魅力だ。商用バックエンドと組み合わせ、長期的に持続可能な観測戦略を組み立てることが今後の鍵となる。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント