OpenTelemetry おーぷんてれめとりー
OpenTelemetryOTELオブザーバビリティ計装テレメトリCNCF
OpenTelemetryについて教えて
簡単に言うとこんな感じ！
「メトリクス・ログ・トレースをどんな監視ツールにも送れる共通の標準」だよ。特定の監視ベンダーに縛られずに計装（データ収集の仕込み）ができるから、Datadog → Prometheusに乗り換えたくなっても計装のコードを書き直さなくていいんだ。
OpenTelemetryとは
OpenTelemetry（OTel）とは、アプリケーションのテレメトリデータ（メトリクス・ログ・トレース）を収集・変換・エクスポートするためのオープンソース標準です。CNCF（Cloud Native Computing Foundation）のプロジェクトとして管理されており、2019年にOpenTracingとOpenCensusが統合されて誕生しました。
これまで監視ツールごとに異なる計装ライブラリが必要でしたが、OpenTelemetryでは一度計装すれば、バックエンドの監視ツールを問わずデータを送信できます。DatadogにもPrometheusにも、CloudWatchにもJaegerにも対応しています。これをベンダーニュートラル（Vendor-neutral）と呼びます。
OpenTelemetryは主に4つのコンポーネントで構成されます。①API（計装の抽象インターフェース）、②SDK（言語別の実装ライブラリ）、③Collector（エージェント/サービスとして動作する収集・変換・転送パイプライン）、④OTLP（OpenTelemetry Line Protocol：データ転送プロトコル）です。
OpenTelemetryの構成要素
| コンポーネント | 役割 |
|---|---|
| OTel API | 計装コードを書くためのインターフェース。ベンダー非依存 |
| OTel SDK | APIの実装。Java・Python・Go・Node.js等の各言語向けに提供 |
| 自動計装 | コードを書かずにフレームワーク・ライブラリを自動で計装 |
| OTel Collector | 受信→処理→エクスポートのパイプライン。エージェントまたはサービスとして動作 |
| OTLP | OTel独自のデータ転送プロトコル（gRPC/HTTP） |
Collectorのパイプライン
Receiver（受信）→ Processor（変換・フィルタ）→ Exporter（転送）- Receiver：Jaeger・Zipkin・Prometheus・OTLPなど多様な形式で受信
- Processor：バッチ処理・サンプリング・データ加工
- Exporter：CloudWatch・Datadog・Jaeger・Prometheusなどに送信
歴史と背景
- 2016年：OpenTracing（CNCF）が分散トレーシングAPIを標準化
- 2018年：OpenCensus（Google）が計装ライブラリを提供。両者が競合
- 2019年5月：両プロジェクトが統合しOpenTelemetryとして誕生
- 2021年：トレースのSDKがGA（安定版）。Kubernetesに次いでCNCFで2番目の活発さ
- 2022年：メトリクスのSDKがGA
- 2023年：ログのSDKがGA。三本柱すべてが安定版に
対応言語とバックエンド
関連する規格・RFC
| 規格 | 内容 |
|---|---|
| W3C Trace Context | OpenTelemetryが採用するトレースコンテキスト伝播の標準 |
| OpenMetrics | Prometheusフォーマットの標準化。OTelのメトリクス形式と連携 |
| OTLP仕様 | OpenTelemetryが独自定義したデータ転送プロトコル |
関連用語
- 分散トレーシング — OpenTelemetryで収集するトレースの概念
- メトリクス・カスタムメトリクス — OpenTelemetryで収集するメトリクスの概念
- ログ集約・構造化ログ — OpenTelemetryで収集するログの概念
- CloudWatch・Azure Monitor・Cloud Monitoring — OTelデータの送信先バックエンド