# OpenTelemetry テレメトリデータ(トレース・メトリクス・ログ)の収集・処理・エクスポートを標準化するベンダー非依存のオープンソースフレームワーク。API・SDK・セマンティック規約・Collector の 4 層で構成され、Jaeger・Zipkin・[[Prometheus]] 等の多様なバックエンドと連携する。ゼロコード計装(zero-code instrumentation)により、ソースコード修正なしでアプリケーションからトレースを収集できる。(Source: [[@2025__ISSTA__Tracezip - Efficient Distributed Tracing via Trace Compression]]) - [[Tracezip]] は OpenTelemetry Collector のエクスポータ/レシーバとして約 3,000 行の Go コードで実装され、既存のトレーシング API と互換性を維持する。(Source: [[@2025__ISSTA__Tracezip - Efficient Distributed Tracing via Trace Compression]]) - セマンティック規約(`network.local.address`、`network.peer.port` 等)が属性キーの名前空間の階層的な構造的冗長性を生み、Tracezip のトークン分割による辞書圧縮の根拠となる。(Source: [[@2025__ISSTA__Tracezip - Efficient Distributed Tracing via Trace Compression]]) [[Retroactive Sampling]]のベンチマーク([[VictoriaMetrics-KubeCon-EU-2026-Sampling|@2026__VictoriaMetrics Blog__KubeCon EU 2026 Retroactive Sampling]])では[[OpenTelemetry Demo]]が負荷再生環境として用いられ、テールサンプリングは OpenTelemetry Collector を中央に挿入する構成で評価された。レトロアクティブサンプリングのプロトタイプは最終的に OpenTelemetry Collector の新プロセッサとして寄贈予定。 CNCF TAG Observability Whitepaper（2023）は OpenTelemetry を「計装・収集の業界標準」として位置づけ、以下の役割を記述する（Source: [[@2023__CNCF TAG Observability__Observability Whitepaper]]）: - **W3C Trace Context の標準採用**: コンテキスト伝播の国際標準として OpenTelemetry が採用。.NET 等の主要プラットフォームも同様。 - **OTLP（OpenTelemetry Protocol）**: メトリクス・ログ・トレースを単一プロトコルで転送するプッシュ型収集基盤。アプリケーションがターゲット情報を自己付与することで一貫したラベリングを実現。 - **Exemplar 対応**: OpenTelemetry SDK がメトリクスヒストグラムに Trace ID を埋め込む Exemplar をサポートし、集約メトリクスから個別トレースへのナビゲーションを可能にする。 - **今後の課題**: 計装・収集を標準化した OTel を「インスピレーション」として、クエリ層の標準化が次のエコシステムギャップとして指摘されている。 [[OTel-Arrow]] は OpenTelemetry のサブプロジェクト(SIG)として、[[Apache-Arrow|Apache Arrow]] のカラム型フォーマットをテレメトリ転送・パイプライン処理に応用する。Phase 1 では [[OTAP]] ワイヤプロトコルを定義し、Phase 2 では Arrow をパイプライン全体の内部表現として採用した Dataflow Engine(Rust 実装)を構築。単一コアで [[OpenTelemetry|OTLP]] 比 **20× スループット**(2.47M vs 121K logs/sec)を達成。(Source: [[@2026__OTelBlog__OTel-Arrow-Phase-2]]) [[OBI]]（OpenTelemetry eBPF Instrumentation）は Grafana Beyla の後継として CNCF に移管された[[ゼロコード計装]]ツールで、eBPF プローブにより 9 言語 × 8 プロトコル × 6 DB を対象にアプリケーションコード変更なしでトレース・メトリクスを収集する。GenAI プロバイダ（OpenAI・Anthropic・Gemini・Bedrock・Qwen）のゼロコード計装も提供し、v0.7.0 では HTTP ヘッダエンリッチメントでインシデント対応時のテナント特定を高速化した。（Source: [[@2026__OTelDocs__OBI - OpenTelemetry eBPF Instrumentation]]、[[@2026__OTelBlog__OBI HTTP Header Enrichment]]） GenAI セマンティック規約は `invoke_agent` → `chat` / `execute_tool` のスパン階層で LLM 呼び出しチェーンを可視化し、`gen_ai.client.operation.duration` と `gen_ai.client.token.usage` の 2 メトリクスでコスト推定とレイテンシ監視を可能にする。VS Code Copilot・OpenAI Codex・Claude Code が OTel 経由でテレメトリを送出する。（Source: [[@2026__OTelBlog__GenAI Observability with OpenTelemetry]]） Collector フォローアップ調査（2025）では、65% の組織が本番で 10 台超を運用（+10%）、VM デプロイが 51%（+18%）に急増しハイブリッド化が進行。46% がカスタム Collector をビルドし、設定管理（63%）と安定性（52%）が最優先改善領域。（Source: [[@2026__OTelBlog__OTel Collector Follow-up Survey]]） 日本コミュニティ調査では、61% が本番運用、NPS +49。トレースが 93% で最多シグナル（メトリクス首位の国際パターンと乖離）。Go はエバリュエーション 39% → プロダクション 76% と最大の採用コンバージョンを示した。（Source: [[@2026__OTelBlog__Japanese Community Survey]]） ログ重複排除プロセッサは、リソース属性・メッセージ本文・重大度等のハッシュで同一ログを集約し、`log_count` と時間範囲を保持しつつ冗長ストレージを排除する。サンプリングと異なりデータを破棄しない。（Source: [[@2026__OTelBlog__Log Deduplication Processor]]） `Observability Engineering`(2nd Edition)第4章は OTel を「共通言語で話せるユニバーサルトランスレータ」と位置づけ、関心の分離(計装 API と送信先バックエンドの分離)がベンダーロックイン解消の核心だと説明する。アプリケーションコードは OTel API でテレメトリを発行し、送信先は設定だけで切り替え・複製できる。ライブラリ作者が API を安全に呼べるのは、未設定時は no-op としてオーバーヘッドゼロで動作することが既定だからだとする。同章はまた、自動計装(フレームワーク・ライブラリの共通操作を横取りする広く浅いカバレッジ)とカスタム計装(ビジネスロジック固有の状態を捉える)の併用を推奨し、前者を「骨格」、後者を「筋肉」に例える。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 4 Getting Started with Instrumentation]]) `Observability Engineering`(2nd Edition)第2章は、OTel と LLM の組み合わせが初版執筆時からオートインストルメンテーション(自動計装)の体験を大きく変えたと述べる。OTel が OSS から得られる再利用可能で文書化されたパターンの蓄積を提供し、それらすべてに LLM が学習済みであるため、計装ありのコードを書く方が計装なしより容易になったと評価される。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 2 How Code Crosses Over - Validating Developer Intent in Production]]) `Observability Engineering`(2nd Edition)第5章は、OTel が「メトリクスイベント」を構造化イベントとほぼ同じ形(タイムスタンプ・型・名前・値・属性)でワイヤ上にモデル化していると指摘する(→ [[構造化イベント]])。また OpenTelemetry Go SDK ではトレースコンテキスト(トレースIDと現在のスパンID)を関数呼び出しの引数として明示的に受け渡す設計を採用しており、Ruby・Python(スレッドローカル変数)や Node.js(`AsyncLocalStorage`)のような暗黙的なコンテキスト伝播を行う言語 SDK とは対照的だと説明する。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 5 Structured Events Are the Building Blocks of Observability]]) `Observability Engineering`(2nd Edition)第7章は OTel を「trace-first(トレース優先)」設計と位置づけ、コンテキスト伝搬(プロセス間の W3C TraceContext・プロセス内のスコープ)がすべてのシグナルをひとつのリクエストへ結び付ける接着剤だと説明する。スパンを作るべきかは「interesting(パフォーマンスに意味のある影響を与えるか)」「aggregable(グループ化して有用な傾向を生むか)」の2条件で判定し、ストリーミング・非同期・サーバーレスなど request/response 型から外れるアーキテクチャではスパンリンクと相関 ID、メトリクスの exemplar を組み合わせて設計する。またメトリクス・スパン・ログを「レイヤードテレメトリ」として使い分ける考え方、テレメトリ規約をスキーマ化し OpenTelemetry Weaver で検証する「スキーマ駆動テレメトリ」、AI エージェント(Claude Code・Cursor・Gemini CLI 等)を計画モード/実行モードで使い分けて計装作業を効率化する手法を紹介する。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 7 Instrumenting Your Code with OpenTelemetry]]) `Observability Engineering`(2nd Edition)第6章は、OTel の Kubernetes セマンティック規約(`k8s.cluster.name`・`k8s.pod.name`等)を、コンテナオーケストレーション環境で構造化イベントへ載せるべき属性設計の参考例として引用する。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 6 Making Structured Events Arbitrarily Wide]]) `Observability Engineering`(2nd Edition)第15章は、複数サービスにまたがるトレーススパンのサンプリングロジック(固定レート・動的レート・ヘッド/テールベース・キー別ターゲットレート等)がオープンソース計装ライブラリの標準機能になりつつある例としてOTelを挙げる。同章はサンプリングの実装詳細を段階的に構築する疑似コード例を通じて、そうしたロジックを自前実装する代わりに[[dynsampler-go]]のような既存ライブラリに委ねられると述べる。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 15 Cheap and Accurate Enough Sampling]]) `Observability Engineering`(2nd Edition)第14章([[ClickHouse]] チーム寄稿)は、OpenTelemetry Collectorと[[ClickHouse]] exporterを使った取り込みパイプラインを解説する。集中型OTelゲートウェイがある場合は`batch`プロセッサでの少数回・大量バッチ挿入、無い場合(DaemonSet・サイドカー構成)は`async_insert=1`によるサーバサイド非同期バッチ化を推奨し、`wait_for_async_insert`で耐久性とレイテンシのトレードオフを選択できるとする。ClickHouse側のブロックハッシュ重複排除により、OTel Collectorからの挿入リトライも安全に行えると説明する。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 14 Efficient Data Storage with ClickHouse]] "The OpenTelemetry Collector and ClickHouse Exporter") `Observability Engineering`(2nd Edition)第16章(Bindplane創業者[[Mike Kelly]]による寄稿)は、OTel Collectorをテレメトリパイプラインの中核部品と位置づけ、Agent(ホスト・コンテナ・サイドカーに配置される軽量配置)・Gateway(集約・処理・削減・経路制御を担う集約ノード)という2つの役割で単一バイナリを運用する設計を説明する。プラガブルアーキテクチャはReceiver(HTTP・gRPC・Kafka・Syslog等、100超のレシーバ)・Processor(正規化・拡充・サンプリング・バッチ化)・Exporter(Prometheus・Elasticsearch・Datadog等)・Extension(zPages・ヘルスチェック・認証)の4種で構成される。フリート管理には[[OpAMP]](Open Agent Management Protocol)という標準プロトコルが用いられ、[[Bindplane]]のような商用コントロールプレーンがこの上にバージョン管理されたロールアウト等のエンタープライズ機能を構築する。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 16 Telemetry Management with Pipelines]]) `Observability Engineering`(2nd Edition)第21章([[Honeycomb.io]]の[[Phillip Carter]]による寄稿)は、LLMアプリケーション向けのGenAIセマンティック規約を、LLMクライアントライブラリが自動生成できる計装として紹介する。入出力トークン数・モデル名・サンプリングパラメータ・システムプロンプトをクライアントスパンへ記録する標準に従うことで、独自のLLMクライアントフレームワークを使う場合でもテレメトリの可搬性を最大化できると説明する。同章はコスト属性の標準キーが規約に存在しないため、クエリ時にモデル名とトークン量からコストを導出する設計を推奨する。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 21 Observability for Large Language Models]] → [[GenAI オブザーバビリティ]]) `Observability Engineering`(2nd Edition)第20章は、[[Kubernetes]]クラスタのコスト最適化においてOTel Collectorを各ノードでDaemonSetとして稼働させ、`kubeletstats`レシーバ(kubeletからPod/ノードのリソース統計を取得)と`k8sattributes`プロセッサ(Pod・Deployment等のメタデータをテレメトリへ付与)を組み合わせる構成を「クラスタの健全性・振る舞いを理解するためのパワーツール」と評する。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 20 Performance Engineering with Observability]] "Cost Optimizing Kubernetes") `Observability Engineering`(2nd Edition)第18章は、CI/CDパイプラインへのOTel統合を実装ガイダンスとして解説する。[[GitHub Actions]]はOTel Collector receiver(GitHub APIキーでデータ取得)またはGitHub Actions add-on(OTLP宛先へジョブテレメトリを直接送出)の2通りで統合でき、[[CircleCI]]のようなシステムはネイティブにOTelトレースをエクスポートしないため`buildevents`のような自前計装が使われてきた。個々のビルドステップの計装には`otel-cli exec --name "..." <command>`でラップする`otel-cli`が使え、トレース状態を環境変数(任意でディスクファイル)にシリアライズしてネストしたコマンドも入れ子でトレースできる。[[Docker]] BuildKitはOTelをネイティブにエクスポートでき(`DOCKER_CLI_OTEL_EXPORTER_OTLP_ENDPOINT`環境変数)、この場合`otel-cli`の併用は二重計装になるため避けるべきとされる。同章は「CIシステムに標準の自動計装がない粒度に限り手動計装へ進む」という優先順位づけを推奨する。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 18 Observability for CI-CD Pipelines]] "Applying These Lessons to Your Build System") → [[CI-CDオブザーバビリティ|CI/CDオブザーバビリティ]] `Observability Engineering`(2nd Edition)第29章は、OTelをbuild-versus-buy意思決定文脈における「ベンダーロックイン回避戦略の中核」として位置づける。ベンダー固有の計装エージェント・ライブラリは時間対価値を短縮する一方、別ツールへ移行するたびに計装のやり直しを強いる。OTelは多くのオブザーバビリティツールが対応するオープン標準を提供することでこの問題を解決し、アプリケーションはネイティブOTel機能をデフォルトで使い、ベンダー固有設定はdistroやexporterに閉じ込める戦略を推奨する。これにより計装を書き換えずにツールを差し替えられる。同章はまた、ベンダーがOTelを名目上サポートしつつ、営業時にOTelを貶め自社の独自インテグレーションを勧めてくる場合があると注意を促す。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 29 Build Versus Buy (Versus Open Source)]] "The Hidden Nonfinancial Costs of Commercial Software") → [[Build Versus Buy]] `Observability Engineering`(2nd Edition)第30章は、ベンダー評価プロセスにおける「OpenTelemetryの決断」として、OTelを計装層でまだ採用していないなら評価開始前に採用すべきだと述べる。ベンダーがOTel利用を思いとどまらせようとする(「使えなくはないが自社独自の統合の方が成熟している」等)なら、それはベンダーロックインを意図している兆候であり、ロックインは自社製品を改善する市場圧力を弱めるからだと警告する。また複数ベンダーのPOC(概念実証)では、OTelを用いてもエクスポータを複数用意する「デュアルライト」構成で新旧ベンダーを並行運用できると述べる。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 30 The Art and Science of Vendor Partnerships]] "The OpenTelemetry Decision") → [[ベンダーエンジニアリング]] `Observability Engineering`(2nd Edition)第31章([[Hazel Weakly]]・[[Austin Parker]]による寄稿)は、OTelの最も価値ある部分を「セマンティック規約」に見出し、属性・メトリクス・スパン・イベント名の語彙とドット区切り名前空間・成熟度/安定性レベルの文法からなる共有言語だと位置づける。「名前空間は左から右へ特定度順」「アクターはclient/server・producer/consumerで定義」の2ヒューリスティクスに大半が還元されるとする。テレメトリスキーマはAPI契約設計のベストプラクティスをテレメトリへ適用したもので、[[OTel Weaver]]がスキーマの定義・ライブチェック・コード生成を担う。ツール構築の指針として、OTel APIはラップせず拡張(デコレータ・再エクスポート)にとどめるべきこと、OpenTelemetry Collectorは設定だけに頼らずOpenTelemetry Collector Builder(OCB)でGoの小さなカスタム拡張を書いて独自ディストリビューションを構築する方が柔軟性・リソース効率・攻撃面の面で優れることを説く。高度にセキュアな規制環境では、[[OTel Weaver]]によるスキーマ制御がアプリケーション単位でなく環境単位でのオブザーバビリティ展開判断を左右しうる重要なケイパビリティになるとし、Google [[Dapper]] の初期普及(監視グラフへのリンク1本追加で利用倍増)を「舗装された道(paved path)」戦略の根拠として引用する。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 31 Instrumentation for Observability Teams]]) → [[プラットフォームエンジニアリング]] / [[Security Level Objectives]] [[@2026__WWW__TraceLLM - Evaluating and Exploring Large Language Models on Trace Analysis in Microservice-based Web Applications]](WWW 2026)は、OTel 仕様に従う span の木構造(caller-callee 関係を表すエッジ、traceId/spanId/parentSpanId 等の属性)をそのままトレース分析ベンチマーク TraceBench の入力データモデルとして採用し、Train-Ticket 上で Grafana Tempo をバックエンドに OTel でトレースを収集した。LLM がこの span 木構造を自然言語で説明・分析できるかを評価する研究であり、OTel の trace-first 設計([[@2026__OReilly__Observability Engineering 2E - Chapter 7 Instrumenting Your Code with OpenTelemetry]] が述べる「trace-first」思想)が LLM 向け入力表現の標準フォーマットとしても機能しうることを示す事例。(Source: [[@2026__WWW__TraceLLM - Evaluating and Exploring Large Language Models on Trace Analysis in Microservice-based Web Applications]]) [[StriaTrace]] は OpenTelemetry のような汎用テレメトリ標準とは異なり、vLLM の同期点・クリティカルパス・GPU カーネルへ特化した推論向けトレーシングを設計している。(Source: [[@2026__OSDI__StriaTrace - Efficient Tracing and Diagnosis for Online LLM Inference]]) [[Preferred Networks]]のKubernetesクラスタ向けPodネットワーク計測ツールは、eBPF Mapから読み出したPod・Service・クラスタ外のIngress/Egressバイト数をOpenTelemetryまたはPrometheus形式へ変換する。アプリケーションへSDKを組み込むのではなく、PodインターフェイスのTCで収集したカーネル内集約値を標準メトリクスへ接続する例である。(Source: [[@2024__Preferred Networks__eBPFを用いてPod ごとのインターネットトラフィック量を計測するツールの開発]]) ## 関連 - ソース: [[@2025__ISSTA__Tracezip - Efficient Distributed Tracing via Trace Compression]] / [[VictoriaMetrics-KubeCon-EU-2026-Sampling|@2026__VictoriaMetrics Blog__KubeCon EU 2026 Retroactive Sampling]] / [[@2023__CNCF TAG Observability__Observability Whitepaper]] / [[@2026__OTelBlog__OTel-Arrow-Phase-2]] / [[@2026__OTelDocs__OBI - OpenTelemetry eBPF Instrumentation]] / [[@2026__OTelBlog__OBI HTTP Header Enrichment]] / [[@2026__OTelBlog__GenAI Observability with OpenTelemetry]] / [[@2026__OTelBlog__OTel Collector Follow-up Survey]] / [[@2026__OTelBlog__Japanese Community Survey]] / [[@2026__OTelBlog__Log Deduplication Processor]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 4 Getting Started with Instrumentation]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 2 How Code Crosses Over - Validating Developer Intent in Production]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 5 Structured Events Are the Building Blocks of Observability]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 6 Making Structured Events Arbitrarily Wide]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 7 Instrumenting Your Code with OpenTelemetry]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 15 Cheap and Accurate Enough Sampling]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 14 Efficient Data Storage with ClickHouse]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 16 Telemetry Management with Pipelines]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 21 Observability for Large Language Models]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 18 Observability for CI-CD Pipelines]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 20 Performance Engineering with Observability]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 30 The Art and Science of Vendor Partnerships]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 31 Instrumentation for Observability Teams]] / [[@2026__WWW__TraceLLM - Evaluating and Exploring Large Language Models on Trace Analysis in Microservice-based Web Applications]] / [[@2026__ICPE__Benchmarking Change Detection Exactness and Overhead of Instrumentation and Sampling]] - 組織: [[CNCF]] / [[TAG Observability]] / [[Honeycomb.io]] / [[Nivenly Foundation]] - プロダクト: [[Tracezip]] / [[Prometheus]] / [[VictoriaTraces]] / [[OpenTelemetry Demo]] / [[OBI]] / [[dynsampler-go]] / [[ClickHouse]] / [[Bindplane]] / [[OpAMP]] / [[GitHub Actions]] / [[CircleCI]] / [[Docker]] / [[Kubernetes]] / [[OTel Weaver]] / [[Dapper]] - 概念: [[分散トレーシング]] / [[テレメトリ]] / [[オブザーバビリティ]] / [[Retroactive Sampling]] / [[トレースサンプリング]] / [[OTel-Arrow]] / [[OTAP]] / [[ゼロコード計装]] / [[GenAI オブザーバビリティ]] / [[ログ重複排除]] / [[構造化イベント]] / [[テレメトリパイプライン]] / [[LLM評価]] / [[CI-CDオブザーバビリティ|CI/CDオブザーバビリティ]] / [[ベンダーエンジニアリング]] / [[プラットフォームエンジニアリング]] / [[Security Level Objectives]]