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

# トレーシングオーバーヘッド ## 定義分散トレーシングエージェントが被監視アプリケーションの実行に追加する余分な実行時間。計装対象メソッド呼び出し 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]]) ## 未解決の問い - 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]] - 概念: [[分散トレーシング]] / [[継続的プロファイリング]] / [[ゼロコード計装]] / [[動的計装]] / [[本番接地型ベンチマーク]] / [[トレース品質]] - エンティティ: [[MooBench]] / [[Kieker]] / [[OpenTelemetry]] / [[David Georg Reichelt]] / [[Wilhelm Hasselbring]] - 関連 MOC: [[AIOps - Fault Localization - MOC]] ## 出典 - [[@2026__ICPE__Benchmarking the Overhead of Distributed Tracing Agents]](Table 2・Table 3・Section 5 根本原因分析・Section 6 改善提言・Section 7 妥当性の脅威)