トレーシングオーバーヘッド

# トレーシングオーバーヘッド ## 定義分散トレーシングエージェントが被監視アプリケーションの実行に追加する余分な実行時間。計装対象メソッド呼び出し 1 回あたりの追加レイテンシ(ns)で表現される。オーバーヘッドは主に(1) 計装コードの注入(バイトコード書き換え)、(2) プローブ実行(コールツリー情報取得・時刻計測・レコード生成)、(3) キューへの挿入(非同期処理のためのキューイング)、(4) データシンクへの書き込み(ネットワーク/ファイル)の 4 ステップから生じる(Source: [[@2026__ICPE__Benchmarking the Overhead of Distributed Tracing Agents]])。 ## エージェント別オーバーヘッド(MooBench ICPE 2026) x86_64(AMD Ryzen 7 5700G、OpenJDK 21.0.8)でのコールツリー深度スケーラビリティの線形回帰結果: | エージェント | 傾き $a$ (ns/depth) | 切片 $b$ (ns) | 機能完全性 | |---|---|---|---| | Kieker 2.0.3 | 133.92 | 197.35 | ○ | | OpenTelemetry 1.56.0 | 315.28 | 47.67 | ○ | | Elastic APM 9.2.1 | 384.66 | 247.92 | ○ | | SkyWalking 10.2.0 | 392.13 | 566.39 | ○ | | inspectIT Ocelot 2.7.0 | 656.79 | 308.50 | ○ | | Pinpoint 3.0.3 | 92.79 | **3348.40** | **✗(スパン損失)** | | Scouter 2.20.0 | 133.84 | **13063.42** | **✗(スパン損失)** | Pinpoint と Scouter は傾きが低く見えるが、これはスパンを意図せず破棄しているため。機能要件を満たさないとして比較対象外。 ## オーバーヘッドの根本原因分類(5 タスク) [[@2026__ICPE__Benchmarking the Overhead of Distributed Tracing Agents]] は async-profiler のフレームグラフとソースコード解析で 5 タスクに分類: | タスク | 主な所見 | |---|---| | **TIME** | SkyWalking が 6 回/メソッドと最多(2 回が最小)。絶対タイムスタンプ要件から各フレームワークが独自実装 | | **METADATA** | OpenTelemetry が最大消費。毎回 HashMap 変換・ClassNames キャッシュ参照・スレッド ID 設定・ランダム ID 生成 | | **CALL-TREE** | OpenTelemetry が ArrayBasedContext を毎回コピー(最大のボトルネック)。Kieker は eoi/ess 方式でコピー不要 | | **MEMORY** | Elastic APM のみオブジェクトプール採用。他はオンザフライ生成 | | **QUEUE** | Elastic APM の Disruptor が最効率。Kieker は書き込みスレッドへのロック待ちが発生 | ## 横断的知見 - **業界標準の OpenTelemetry は最速クラスでない**: OpenTelemetry(315.28 ns/depth)は Kieker(133.92 ns/depth)の 2.4 倍遅い。過度なメタデータ管理(HashMap のコピー・文字列連結・ランダム ID 生成)と ArrayBasedContext のスタックコピーが主因。「業界標準 = 軽量」ではないことを実測データが示す。(Source: [[@2026__ICPE__Benchmarking the Overhead of Distributed Tracing Agents]]) - **スパン損失はオーバーヘッド計測を無効化する**: Pinpoint と Scouter は傾きが小さく見えるが、これは 30〜70% のスパンを無音で破棄するためで、性能が良いのではなく計測対象が減っている。「傾きが低い = 良い」という単純な読み取りが機能バグを隠す。スパン破棄の検出には絶対値比較と共に受信レコード数の確認が必須。(Source: [[@2026__ICPE__Benchmarking the Overhead of Distributed Tracing Agents]]) - **x86_64 と ARMv8 でランキングは変わらない**: ARM(Raspberry Pi 5)では絶対値が 2〜4 倍増加するが、Kieker < OpenTelemetry < Elastic APM の相対ランキングは維持される。オーバーヘッドの差異はアーキテクチャ固有の問題でなくフレームワーク実装に起因する。(Source: [[@2026__ICPE__Benchmarking the Overhead of Distributed Tracing Agents]]) - **eoi/ess 方式によるコールツリー表現がオーバーヘッド最小化の鍵**: Kieker の「実行順序インデックス + スタックサイズ」をスレッドローカル変数で管理する方式は、スタックコピー・コンテキストオブジェクト生成を不要にする。OpenTelemetry が `ArrayBasedContext` をコピーし続けることとの対比で、コールツリー表現の設計選択がオーバーヘッドを 2 倍以上変える。(Source: [[@2026__ICPE__Benchmarking the Overhead of Distributed Tracing Agents]]) - **非分散マイクロベンチマークが分散シナリオのオーバーヘッドの下限を与える**: MooBench は非分散・単一ユーザ設定で計測するが、分散トレーシングでは追加のネットワーク転送・コンテキスト伝搬オーバーヘッドが加わるため、実際の分散シナリオではさらに大きいオーバーヘッドが生じる。非分散計測は比較基準の下限として有効。(Source: [[@2026__ICPE__Benchmarking the Overhead of Distributed Tracing Agents]]) - **計装層(カーネル/ソケット vs アプリ/バイトコード)が異なると、オーバーヘッドの計測単位自体が揃わない**: MooBench(Java エージェント)はコールツリー深度あたりの追加レイテンシ(ns/depth)で計測するのに対し、[[@2025__PhD__Scaling Telemetry Workloads in Cloud Applications - Chapter 3 Efficient TCP-UDP Socket-based Instrumentation in Kernel for Continuous Construction of Network Call Graphs]](博士論文 Ch.3)のカーネル内フロー束ねは Collector プロセスの CPU 使用率(%)とラウンドトリップあたりの eBPF 実行時間(µs)で計測する。前者はメソッド呼び出し単位、後者はソケット I/O イベント単位の粒度であり、計装対象の抽象度が違うため単位変換なしに直接比較できない。ただし定性的には、Java エージェント最速の Kieker が 133.92 ns/depth であるのに対し、カーネル内フロー束ねは 1,000 サービス規模までの高負荷条件下でも CPU 使用率 2.2% 未満・eBPF 実行時間最大 6µs/RTT に収まっており、両者とも「オーバーヘッドを最上流(カーネルまたは計装コード自体)で切り詰める」という同じ設計圧力の異なる実装解であることがわかる。これは本頁の未解決の問い「eBPF ベースの非侵入トレーシングは Java エージェントと比較してどの程度のオーバーヘッドになるか」に、単位変換抜きの定性的な参照点を与える。(Source: [[@2025__PhD__Scaling Telemetry Workloads in Cloud Applications - Chapter 3 Efficient TCP-UDP Socket-based Instrumentation in Kernel for Continuous Construction of Network Call Graphs]], [[@2026__ICPE__Benchmarking the Overhead of Distributed Tracing Agents]]) - **「事象頻度に比例するオーバーヘッド」という1991年の原理的モデルが、35年後のns/depth実測ベンチマークの背後にある同じ現象を先取りしていた**: [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 7 Monitors]] §7.3は、ソフトウェアモニタ(事象駆動型)のオーバーヘッドは活性化1回あたりの命令数×入力速度(事象頻度)に比例するとし、具体例として「100命令/事象、1MIPSマシンでオーバーヘッド1%に抑えるには入力速度100事象/秒未満」という数値を導く。MooBench(ICPE 2026)の傾き $a$(ns/depth)はまさにこの「1事象(呼び出し1回)あたりの追加コスト」を実測した値であり、コールツリーが深い(呼び出しが頻繁な)ほど累積オーバーヘッドが線形に増える現象は、1991年モデルの「入力速度に比例するオーバーヘッド」をそのまま体現している。異なる点は、1991年モデルが命令数から理論値を導出する演繹的アプローチだったのに対し、MooBenchはasync-profilerによる帰納的な実測(根本原因を5タスクに分類)である点である(Source: [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 7 Monitors]] §7.3, [[@2026__ICPE__Benchmarking the Overhead of Distributed Tracing Agents]])。 - **「事象駆動対サンプリング型」という1991年の起動機構分類が、現代の「全数トレーシング対サンプリング(トレースサンプリング)」という設計選択と同型である**: 第7章§7.2は、事象駆動モニタは事象が頻繁だとオーバーヘッドが過大になる一方、サンプリング型(timer-driven)はオーバーヘッドが事象頻度に依存しないため頻繁な事象の観測に向くと述べる。MooBenchが計測する分散トレーシングエージェント(OpenTelemetry・Kieker等)はいずれも「呼び出しごとに計装コードを実行する」事象駆動型であり、その傾き(ns/depth)がゼロにならない限り、呼び出し頻度が高いワークロードでは1991年モデルが予言するとおりオーバーヘッドが問題化する。この構造的な限界が、[[トレースサンプリング]]のような「サンプリング型」設計(全呼び出しではなく一部のみトレースする)が実務で採用される理論的根拠になっていると読める(Source: [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 7 Monitors]] §7.2, [[@2026__ICPE__Benchmarking the Overhead of Distributed Tracing Agents]])。 - **トレーシングオーバーヘッドの削減は、計装点の少数化・計測粒度の選択・保存条件の三段階で行える**: Java エージェントの MooBench はメソッド呼出しごとの追加コストを測定するのに対し、StriaTrace は vLLM の数万関数呼出しを数十の同期点・semantic spanへ縮約し、さらに GPU 詳細データを異常時だけ保存する。計装そのもののコストを測る ICPE 2026 の知見と、生成後の保存量を約 1.6%へ削減する StriaTrace の設計を並べると、オーバーヘッドは「一イベントあたりのコスト」と「全イベントをどこまで残すか」という分離可能な二つの制御対象になる。(Source: [[@2026__ICPE__Benchmarking the Overhead of Distributed Tracing Agents]], [[@2026__OSDI__StriaTrace - Efficient Tracing and Diagnosis for Online LLM Inference]]) - [エージェント別オーバーヘッド] 計装(バイトコード計装によるトレーシング)のオーバーヘッドはメソッド呼び出し当たり約 0.5 μs(0.3〜0.7 μs、コールツリー深さに線形)である一方、サンプリング(async-profiler)のオーバーヘッドは Pure 実行との差が統計的有意性をもって識別できないほど小さい(Source: [[@2026__ICPE__Benchmarking Change Detection Exactness and Overhead of Instrumentation and Sampling]]) ## 未解決の問い - **高頻度イベントの計測では、イベントを捨てる場所がオーバーヘッドを大きく左右する**: Java エージェントや全数のスケジューラトレースはイベントごとに記録・輸送・後処理が発生するのに対し、[[@2017__brendangregg.com__Off-CPU Analysis]] の eBPF 方式はスタックと待機時間をカーネル内で集約する。記事の実験では全量出力の perf より eBPF の計測・後処理の影響が小さく、既存の「計装点の少数化・保存条件の選択」という知見に「集約場所の選択」を加えられる。(Source: [[@2017__brendangregg.com__Off-CPU Analysis]], [[@2026__ICPE__Benchmarking the Overhead of Distributed Tracing Agents]], [[@2026__OSDI__StriaTrace - Efficient Tracing and Diagnosis for Online LLM Inference]]) - 同期点計装と異常時保存を他の LLM 推論エンジンへ移植したとき、トレーシングオーバーヘッドの支配項は計装・GPU収集・データ輸送のどこへ移るか。 - inspectIT は YAML 設定ベースの動的クラス置換(javassist)が追加オーバーヘッドを生む。この間接層をコンパイル時生成に変えることでどの程度削減できるか。 - OpenTelemetry の改善提言(ハッシュマップコピー除去・スタックコピー除去)を実装した場合、どれほどオーバーヘッドが削減されるか。Kieker 水準に近づけるか。 - マイクロサービスアーキテクチャ(非同期 I/O・HTTP リクエスト処理・DB クエリ)では MooBench の結果がどう変わるか。セッション ID ハンドリング・他リクエストとの関係付けは追加リソースを消費する。 - eBPF ベースの非侵入トレーシング([[BPF]]・[[eBPF]])は Java エージェントと比較してどの程度のオーバーヘッドになるか。ChainScope([[@2026__CoNEXT__ChainScope - Balancing Accuracy and Overhead in Non-intrusive Distributed Tracing of Microservices]])の CPU 2〜3%(1% サンプリング時)との比較が興味深い。 - GPU/LLM 訓練クラスターのトレーシング([[@2026__arXiv__ARGUS - Production-Scale Tracing and Performance Diagnosis for over 10,000-GPU Clusters]])における「< 2% オーバーヘッド」の制約は Java エージェントと異なる手法で達成されているが、両者の計装コスト構造はどう異なるか。 - GraalVM native-image や Eclipse OpenJ9 では JIT コンパイルの挙動が異なり、バイトコード書き換えの特性が変わる。Kieker のオーバーヘッド優位性は維持されるか。 ## 関連 - ソース: [[@2026__ICPE__Benchmarking the Overhead of Distributed Tracing Agents]] / [[@2025__PhD__Scaling Telemetry Workloads in Cloud Applications - Chapter 3 Efficient TCP-UDP Socket-based Instrumentation in Kernel for Continuous Construction of Network Call Graphs]] / [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 7 Monitors]] / [[@2026__ICPE__Benchmarking Change Detection Exactness and Overhead of Instrumentation and Sampling]] - 概念: [[分散トレーシング]] / [[継続的プロファイリング]] / [[ゼロコード計装]] / [[動的計装]] / [[本番接地型ベンチマーク]] / [[トレース品質]] / [[eBPF]] / [[モニタの分類と設計トレードオフ]] / [[トレースサンプリング]] / [[性能変化検知の正確性]] - エンティティ: [[MooBench]] / [[Kieker]] / [[OpenTelemetry]] / [[David Georg Reichelt]] / [[Wilhelm Hasselbring]] / [[go-conntracer-bpf]] - 関連 MOC: [[AIOps - Fault Localization - MOC]] ## 出典 - [[@2026__ICPE__Benchmarking the Overhead of Distributed Tracing Agents]](Table 2・Table 3・Section 5 根本原因分析・Section 6 改善提言・Section 7 妥当性の脅威) - [[@2025__PhD__Scaling Telemetry Workloads in Cloud Applications - Chapter 3 Efficient TCP-UDP Socket-based Instrumentation in Kernel for Continuous Construction of Network Call Graphs]](§3.4 CPU使用率(%)・eBPF実行時間(µs/RTT)によるオーバーヘッド計測) - [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 7 Monitors]](§7.2 モニタの起動機構分類、§7.3 ソフトウェアモニタのオーバーヘッド設計指針)