# OpenTracing 分散トレーシング([[分散トレーシング]])のベンダー中立 API/抽象標準。trace の構造を「span tree」「semantic conventions」「annotation」で規定する。OpenTracing Specification Council が GitHub の opentracing/specification リポジトリで管理した。Bento+ 2021 が指摘するとおり、2019 年時点で [[OpenCensus]] と統合し [[OpenTelemetry]] に発展的に合流している。 ## 中核モデル - **span**: 作業単位。操作名・開始時刻・期間・annotation を持つ。例として RPC や HTTP コール。 - **span tree**: trace ID を共通項に、span ID と parent span ID で親子関係を表現。本来は tree だが OpenTracing は generality 目的で full directed acyclic graphs に拡張された([[@2021__J Grid Computing__Automated Analysis of Distributed Tracing - Challenges and Research Directions]] §2.1)。 - **dynamic, fixed-width metadata によるコンテキスト伝搬**: span 間の因果連鎖を維持。 - **semantic conventions**: span 内容/annotation の意味的規約(opentracing/specification 内の semantic_conventions.md)。 ## Bento+ 2021 が指摘する仕様の限界 [[@2021__J Grid Computing__Automated Analysis of Distributed Tracing - Challenges and Research Directions]] §1・§5 は、OpenTracing 仕様が自動分析を妨げる構造的問題を 5 点指摘する。 - **dependency graph / span tree の生成/分析ツールを欠く**。Zipkin は span tree を扱うが構造化エクスポートしない。 - **タイムスタンプに単位ラベルがない**。同じデータセットの span 群に ms と μs が混在する事例があった。 - **annotation が任意 key-value で式を爆発させる**。エラーコード・関数戻り値・URL 等が span 間で異なる表現になる。 - **量的テスタビリティ(testability)が無い**。仕様が緩いので「適合か」を計算的に判定できる強い意味の compliance テストが書けない。 - **トレース品質が広く ばらつく**。OpenTelemetry 等の後続フレームワークでも、developer に品質メトリクスを提供できるテスタビリティ機能を備えるべきだと提言する。 ## 関連 - ソース: [[@2021__J Grid Computing__Automated Analysis of Distributed Tracing - Challenges and Research Directions]] / [[@2022__IEEE ACCESS__A Survey on Observability of Distributed Edge & Container-Based Microservices]] - 後継: [[OpenTelemetry]] - 関連プロダクト: [[Jaeger]] / [[Zipkin]] - 関連概念: [[分散トレーシング]] / [[トレース品質]] ## 出典 - [[@2021__J Grid Computing__Automated Analysis of Distributed Tracing - Challenges and Research Directions]] §1・§2.1・§5 - OpenTracing Specification Council. The OpenTracing Specification repository. https://github.com/opentracing/specification(2019)