# 分散トレーシング ## 定義 分散トレーシング/ネットワークコールグラフ構築は、クラウドアプリケーションのコンポーネント間の通信(network call)を自動で捕捉し、サービスを頂点・フローを辺とする有向グラフ(call graph)として可視化する取り組み。path-oriented なテレメトリ([[テレメトリ]])の中核で、障害伝播の予防・診断を支える。call は client→server の有向辺と定義し、固定ポートで listen する側を server とする。([[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]]) 計装の位置で **application-intrusive**(アプリコードを改変、詳細だが手間がかかる)と **application-non-intrusive**(proxy・カーネルのネットワークスタック・ネットワークスイッチで透過的に捕捉)に分かれ、後者の socket-based 手法はカーネルの socket 操作をプローブしてユーザー空間コードの改変を不要にする。([[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]]) ## 横断的知見 - **「接続の有無」から「転送バイト数」への拡張が配置最適化を実現する**: Weave Scope は eBPF で TCP 接続の開閉のみ追跡(オーバーヘッド 1%)するが、これはトラフィック量ゼロのエッジを持つ非重み付きグラフであり、コンテナ配置最適化([[コンテナ配置最適化]])には不十分。Neves ら(SAC 2020)はカーネル内集約(KernelAgg)で sock 単位のバイトカウンタを保持し、閾値超過時のみ転送することで 9% オーバーヘッドの**重み付き**通信グラフを実現した。同じ socket-based の流儀でも「何を計測するか(接続 vs バイト数)」と「いつ転送するか(毎イベント vs 周期的)」の選択が用途と実用性を分ける。 (Source: [[@2020__SAC__Black-box inter-application traffic monitoring for adaptive container placement]]) - **socket-based tracing は転送オーバーヘッドの抑え方で 4 系統に分岐する**: snapshot polling(procfs を定期取得、短命接続・UDP を取りこぼす)/ streaming(kprobe で全イベントを即転送、メッセージ率に対し線形に劣化)/ in-kernel flow aggregating(フロー単位でカーネル内集約、短命 TCP が多いとフロー数の増加で破綻)/ **in-kernel flow bundling**(同一宛先への複数フローを 1 フローに束ね転送量を最小化、[[go-conntracer-bpf]])。bundling は CPU < 2.2% を維持するが、ネットワークサービス数が 10,000 規模で bundling rate が 0 に近づくと aggregating と差が消える。([[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]]) - **path-oriented データの収集を扱う唯一の wiki ソース**: 既存の AIOps/RCA 群([[Fault Localization]]・[[根本原因分析]])はメトリクス(time-oriented)中心で、call graph/trace を入力に使う手法は二次的にしか現れない。本概念は call graph を「どう低コストに作るか」という計装側の論点を持ち込み、将来 trace-based RCA を ingest する際の接続点になる。(Source: [[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]]) - **「非侵襲・低オーバーヘッドでイベントを関連付ける」骨格が AIOps から GPU/LLM インフラ層へ伸びる**: マイクロサービスの socket-based トレーシングと同じ「アプリを直さずカーネル/低層でイベントを捕捉し因果連鎖を再構成する」発想が、LLM インフラでも現れる。[[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]] は CPU・アクセラレータ・プロセス・ノードをまたぐイベントを一意に関連付けてリクエスト単位の実行タイムラインを構築し([[LLM推論]])、[[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]] は[[集合通信]]をフロー単位・チャンク単位でトレースして遅延の伝播を辿る。socket-based が「サービス間 call の有向グラフ」を作るのに対し、これらは「リクエスト/通信オペレーションの実行依存グラフ」を作る——粒度と対象層は違うが、非侵襲計装で分散イベントを縫合する点は同型。(Source: [[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]], [[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]]) - **転送オーバーヘッドの抑え方が GPU 訓練トレースでも反復する**: socket-based トレーシングの 4 系統(snapshot/streaming/aggregating/bundling)が転送量をいかに減らすかで分岐したのと同様、Mycroft は全イベントを記録せず短時間ウィンドウ(例 100ms)で各コンポーネント処理量を集約し、固定サイズ環形バッファ + 非同期送信でオーバーヘッドを最小化する。「細粒度トレースは取りすぎると害」という制約が、AIOps の call graph 収集でも GPU 訓練の通信トレースでも共通の設計圧力になる([[テレメトリ]])。(Source: [[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]], [[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]]) - **「全データ生成 + 遅延的収集」が、ヘッドサンプリングとテイルサンプリングの二項対立を回避する**: ヘッドサンプリング(Jaeger 既定 0.1%)はエッジケースを見逃し、テイルサンプリングは全スパンの取り込みでスループットを最大 42% 低下させる。[[Hindsight]] の遡及的サンプリング(retroactive sampling)は、全リクエストのトレースデータをローカルメモリに生成(tracepoint 約 8 ns)するが、バックエンドへの取り込みは症状トリガー発火後にのみ行う。93 サービスで 99–100% のエッジケースを −3.5% 以内のスループット影響で捕捉した。これは博士論文の「文脈が最も豊富な層(計装/分析の両端)でデータを削減せよ」という指針を、サンプリング決定に適用したものと読める——生成は計装側で全数行い、削減はトリガー(分析側の文脈)で行う。(Source: [[@2023__NSDI__Hindsight - Tracing Edge-Cases in Distributed Systems]], [[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]]) - **データプレーン/コントロールプレーン分離の設計パターンが、socket-based トレーシングの 4 系統と同じ「転送量を減らす」課題を別経路で解く**: socket-based 手法は in-kernel aggregating/bundling でカーネル内で集約し転送量を削減した。Hindsight はデータプレーン(共有メモリバッファプールへの memcpy)とコントロールプレーン(メタデータのみのキュー)を分離し、大半のリクエストのトレースデータはネットワークに一切触れない。いずれも「生成は安価・転送が高価」という同一の制約下で、フロー集約(マイクロサービスのコールグラフ構築)と遅延的収集(エッジケーストレーシング)という異なる解を与える。(Source: [[@2023__NSDI__Hindsight - Tracing Edge-Cases in Distributed Systems]], [[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]]) - **ラテラルトレースがクロストレース分析(時間的プロベナンス)を開く**: 既存のテイルサンプラーは traceId ベースのシャーディングで個別トレースを独立処理するため、共有キューの詰まりのように複数リクエストにまたがる因果を追えない。Hindsight の TriggerSet はトリガー発火時に直近 N 件のラテラルトレース ID を含めることで、HDFS NameNode キューの詰まり原因を遡及的に再構成した。これは本 wiki の[[根本原因分析]]が扱う「障害伝播の因果連鎖」をトレースレベルで捉える手段であり、メトリクスベース RCA との接続点になる。(Source: [[@2023__NSDI__Hindsight - Tracing Edge-Cases in Distributed Systems]]) - **「トレースの収集コスト削減」と「下流分析の品質」はトレードオフでなく連動する**: 博士論文が計装層の低オーバーヘッドを追求し、Hindsight がヘッド/テールサンプリングの二項対立を回避したのと同じ「取りすぎると害」の制約の先に、サンプリングが下流分析の精度を直接支配するという知見が TraStrainer で定量化された。多様性のみに基づくサンプラーでは、VAE ベース RCA（TraceAnomaly）が正常パターンを学習できず A@1 が 30% 未満に留まるのに対し、システムランタイム状態（メトリクスの異常度）をトレースの多様性と組み合わせると 54.84% に到達する。これは「サンプリングは単なるコスト削減でなく、分析品質を支配する上流プロセスである」ことを示し、計装→サンプリング→分析の 3 層すべてで「何を残すか」の設計が連鎖する。Hindsight の遡及的サンプリングが「いつ収集するか」を最適化するのに対し、TraStrainer は「何を優先して残すか」をシステム状態で最適化する——両者は同じサンプリング問題の異なる軸を攻めている。(Source: [[@2024__FSE__TraStrainer - Adaptive Sampling for Distributed Traces with System Runtime State]], [[@2023__NSDI__Hindsight - Tracing Edge-Cases in Distributed Systems]], [[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]]) - **カーネルイベントとフレームワークイベントを相関させ、トレースを統計的異常検知に接続する**: [[@2025__IWQoS__eACGM - Non-instrumented Performance Tracing and Anomaly Detection towards Machine Learning Systems]] はカーネルイベントと高レベルフレームワークイベントを相関させ、層をまたぐボトルネックを非侵入で捉える。クラウドのマイクロサービス分散トレーシング(Dapper/OpenTelemetry 系)が依存関係グラフを前提とするのに対し、均質ワークロードの分散訓練ではトレースを GMM の統計的異常検知に接続する。(Source: [[@2025__IWQoS__eACGM - Non-instrumented Performance Tracing and Anomaly Detection towards Machine Learning Systems]], [[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]]) - **「1 or 0」サンプリングの二項対立を「共通性 + 可変性」分解で超える**: Hindsight が「いつ収集するか」、TraStrainer が「何を優先して残すか」でサンプリング問題を攻めたのに対し、[[Mint]] はそもそもサンプリングの二項(全保持 vs 全破棄)を解体する。トレースを共通パターン(トポロジ + スパン属性)と可変パラメータに分解し、パターンは全トレースについて保持(Bloom Filter でメタデータ格納)しつつ、パラメータはサンプリングされたトレースのみ送信する。Alibaba 本番(日量 18.6〜20.5 PB)でストレージオーバーヘッドを 2.7% に削減しつつクエリミス率を 0% にし、下流 RCA の top-1 精度を同一データ量で 25%→50% に向上させた。「サンプリングは分析品質を支配する」(TraStrainer)という知見を受けて、Mint は「サンプリングされないトレースでも近似的に分析可能」にすることで、コスト削減と分析品質を対立でなく連動させている。(Source: [[@2025__ASPLOS__Mint - Cost-Efficient Tracing with All Requests Collection via Commonality and Variability Analysis]], [[@2024__FSE__TraStrainer - Adaptive Sampling for Distributed Traces with System Runtime State]], [[@2023__NSDI__Hindsight - Tracing Edge-Cases in Distributed Systems]]) - **トレース圧縮はトポロジ構造の活用がログ圧縮手法を大幅に上回る**: 汎用ログ圧縮手法(LogZip/LogReducer/CLP)を分散トレースに適用しても圧縮率は平均 10.7〜14.9 にとどまるのに対し、Mint はトレース固有のトポロジ構造(スパン間の親子関係・サービス間の呼び出し順序)を活用することで平均 34.6 の圧縮率を達成する。ログはフラットなテキスト行であるのに対し、トレースは木構造を持つため、構造を活用した圧縮が本質的に有効であることが示された。(Source: [[@2025__ASPLOS__Mint - Cost-Efficient Tracing with All Requests Collection via Commonality and Variability Analysis]]) - **「何をサンプリングするか」の粒度がリクエスト単位からスパン単位へ深化する**: リクエストベースサンプリング(ヘッド/テール)はリクエスト全体の取捨を決めるが、サンプリングされたトレース内でも 85-90% のスパンは性能変動の説明に不要(Alibaba トレース分析で 90%、[[DeathStarBench]] 3 アプリケーションで 15% のスパンが分散の 80% 以上を占有)。[[Astraea]] はリクエストベースサンプリングの上にスパンレベルの確率的サンプリングを重ねることで、計装の 20-35% で 92% の Top-5 精度を達成する。TraStrainer がリクエスト単位で「何を優先して残すか」をシステム状態で最適化するのに対し、Astraea はトレース内の個々のスパンの重要度をベイズ信念で学習する——サンプリング問題の粒度が一段細かい。(Source: [[@2024__IEEE CLOUD__Astraea - Unleashing Performance Insights with Online Probabilistic Tracing]], [[@2024__FSE__TraStrainer - Adaptive Sampling for Distributed Traces with System Runtime State]]) - **オフラインプロファイリング vs オンライン学習のトレードオフが計装自動化で顕在化する**: [[VAIF]] はオフラインで全実行パスを事前記憶し二値判定(スパンの有効/無効)で計装を制御するが、高並行アプリケーションでは最頻パスに集中して低頻度パスの問題を見逃す。[[Astraea]] はベイズ信念+マルチアームドバンディット(MAB)の確率マッチングで探索と活用をオンラインで統計的にバランスさせ、事前プロファイリングを不要にした。同じ「探索 vs 活用」のフレームは Hindsight の「いつ収集するか」、TraStrainer の「何を優先するか」とも対比でき、分散トレーシングの計装・収集・サンプリング各層に共通の設計判断として現れる。(Source: [[@2024__IEEE CLOUD__Astraea - Unleashing Performance Insights with Online Probabilistic Tracing]], [[@2023__NSDI__Hindsight - Tracing Edge-Cases in Distributed Systems]], [[@2024__FSE__TraStrainer - Adaptive Sampling for Distributed Traces with System Runtime State]]) - **「サンプリングで量を減らす」と「圧縮でサイズを減らす」は直交する 2 軸**: 既存の横断的知見は、ヘッド/テールサンプリング(Hindsight・TraStrainer・Astraea)がトレースの**本数や計装点**を減らす方向を、Mint が共通性/可変性分解で**全トレースの近似保持**を整理してきた。[[@2025__ISSTA__Tracezip - Efficient Distributed Tracing via Trace Compression|Tracezip]] はこれらと直交し、各スパンの**バイトサイズ**をオンライン圧縮で減らす。スパン間のキー・バリューペアの約 70% が反復するという冗長性を Span Retrieval Tree (SRT) で大域的に抽出し、汎用圧縮(gzip/bzip2/lzma)と併用して 10〜45% の追加圧縮改善を得る。サンプリングとの組み合わせが可能であり、ヘッドベースサンプリングのカバレッジ低下やテールベースサンプリングの収集オーバーヘッドを回避しつつ、より多くのリクエストをトレースできる。博士論文の「文脈最良の両端で削減せよ」の計装側適用としても読める——SRT はスパン生成の直後(計装側の文脈が最も豊かな時点)で冗長性を除去する。Mint の「トポロジ構造を活用した圧縮率 34.6」に対し Tracezip は「キー・バリューの大域冗長性を活用した圧縮率 4〜6(+汎用併用で 13〜45)」であり、構造 vs 内容の冗長性という異なる層を攻めている。(Source: [[@2025__ISSTA__Tracezip - Efficient Distributed Tracing via Trace Compression]], [[@2025__ASPLOS__Mint - Cost-Efficient Tracing with All Requests Collection via Commonality and Variability Analysis]], [[@2023__NSDI__Hindsight - Tracing Edge-Cases in Distributed Systems]]) - **「明示的コンテキスト伝搬 + カーネル内サンプリング」が非侵襲トレーシングの精度・オーバーヘッドの二律背反を打破する**: DeepFlow は暗黙コンテキスト伝搬(TCP シーケンス解析)でペイロード検査を不要にしたが、サンプリング機構を持てないため高負荷時に CPU が飽和し(100〜200%)、精度も 21% にとどまる。一方 Beyla は明示的なアプリ層ヘッダー注入で高精度を狙うが、uprobe と高頻度文字列操作で同様に CPU 飽和し、非同期・gRPC シナリオで 100% 損失率に達する。ChainScope は IP レベルパケットタギング(TCP/IP スタック下層で HTTP ヘッダーに依存しない)と eBPF カーネル内ヘッドサンプリングを組み合わせることで、1% サンプリング時に CPU 2〜3%・性能低下 4% 未満を達成しながら精度 100% を維持する。DeepFlow・Beyla との対比から「明示伝搬 + カーネルサンプリング」の組み合わせが設計空間の空白を埋める解であることが示された。(Source: [[@2026__CoNEXT__ChainScope - Balancing Accuracy and Overhead in Non-intrusive Distributed Tracing of Microservices]], [[@2023__SIGCOMM__Network-Centric Distributed Tracing with DeepFlow]]) - **epoll の非同期依存関係モデリングが非侵襲トレースの精度の鍵になる**: 単純な FIFO / run-to-completion 仮定は nginx・envoy などの広く使われるミドルウェアで崩れる。ChainScope は `ep_insert` フックでダウンストリームとアップストリームのソケットを紐付ける Epoll 強化 FIFO 機構を実装し、実際の非同期動作を精度 100% でモデル化した。DeepFlow が TCP シーケンス合体問題で gRPC トレースを失い、Beyla が高並行で 100% 損失に達するのと対照的で、「どのカーネルイベントを追跡するか」の選択が非同期アプリケーションの精度を左右することを示す。(Source: [[@2026__CoNEXT__ChainScope - Balancing Accuracy and Overhead in Non-intrusive Distributed Tracing of Microservices]]) - **「ゼロエフォートの観測ベースライン」が intrusive ツールの範囲を限定する**: ChainScope は非侵襲で全サービスをカバーするベースラインとして機能し、希少なボトルネックイベント(ロングテール上位 2%)を特定した上で、高コストな手動計装の対象を絞り込む。Hotel Reservation の根本原因分析では Jaeger(侵襲型)が memcached のカバレッジ欠如で誤報告し、DeepFlow が親子関係欠落で誤判定するのに対し、ChainScope だけが geo と memcached-rate の両方を正確に特定した。非侵襲システムが「完全トレース + 根本原因特定」まで担えることを実験的に示した。(Source: [[@2026__CoNEXT__ChainScope - Balancing Accuracy and Overhead in Non-intrusive Distributed Tracing of Microservices]]) - **ネットワーク層のカバレッジが「どこが遅いか」から「なぜネットワークで遅いか」へ診断を高度化する**: 博士論文や Hindsight 等の先行研究が計装・サンプリング・圧縮という「どうトレースを取るか」を中心に扱ってきたのに対し、[[DeepFlow]](SIGCOMM 2023)は「何をトレースするか」の軸を変換する。顧客調査で性能問題の 47.3% がネットワークインフラ起因であることを示しながらも、既存ツールはアプリ層のみ記録する。DeepFlow の eBPF ベースのネットワーク中心計装は、物理 NIC・仮想スイッチ・コンテナ・ゲートウェイを含むエンドツーエンドのパスを 1 トレースに収め、Jaeger/Zipkin の 4〜6 スパン/トレースに対し 18〜38 スパン/トレースを生成する。「広くカバーするから冗長」ではなく、「盲点がなくなることで障害箇所を特定するための情報密度が増す」という設計の逆転が興味深い。(Source: [[@2023__SIGCOMM__Network-Centric Distributed Tracing with DeepFlow]]) - **ネットワーク固有の不変量を活用した非侵入トレースが「明示的コンテキスト挿入」を不要にする**: 従来の非侵入型フレームワーク(libc プリロード・RPC ライブラリ計装)はユーザー空間の分離境界により盲点を生じさせた。DeepFlow は TCP シーケンスがネットワーク転送(L2/3/4)で不変であることを利用し、パケットを変更せずにコンポーネント間の因果を確立する([[暗黙のコンテキスト伝搬]])。これは博士論文の socket-based tracing が「ネットワークスタックで捕捉」することで侵入を不要にした発想と同型だが、DeepFlow はさらにスレッド ID・時刻・X-Request-ID・OpenTelemetry トレース ID の 4 層を反復的に統合することで、マルチレイヤー・マルチスレッドの複雑な因果連鎖を再構成する。(Source: [[@2023__SIGCOMM__Network-Centric Distributed Tracing with DeepFlow]], [[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]]) - **トレースの冗長性の度合いはアーキテクチャの複雑度で変わる**: Tracezip の評価で、マイクロサービスベンチマーク([[Train-Ticket]]、41 サービス)のトレースは汎用圧縮の短い窓長(gzip: 32KB)では捉えきれない大域的冗長性を持ち、SRT の改善幅が最大(33%)になる一方、単一コンポーネント(Redis 等)では接続情報が静的で汎用圧縮だけでも高い圧縮率を達成する。Kafka はメッセージ内容がスパンに混入するため冗長性が低い(改善 7%)。つまりトレース圧縮の効果は「どの層のどのサービスを計装するか」に依存し、計装設計とデータ削減設計が連動する。(Source: [[@2025__ISSTA__Tracezip - Efficient Distributed Tracing via Trace Compression]]) - **分散トレーシングの起源は Dapper/X-Trace であり、イベントサンプリングで実用化されたことが現在のサンプリング論争の出発点**: Usman ら 2022 のサーベイ([[@2022__IEEE ACCESS__A Survey on Observability of Distributed Edge & Container-Based Microservices]])は、分散トレーシングを Microsoft の Magpie（OSDI 2004）と X-Trace による概念定立、Google の Dapper による「イベントサンプリングでオーバーヘッドを削減し実用化」という系譜で整理し、Jaeger がその OpenTracing 実装として普及したと記述する。この文脈は本 wiki の既存知見（Hindsight が指摘する「Jaeger 既定 0.1% サンプリングはエッジケースを見逃す」問題）の起源でもある——Dapper がサンプリングを「実用化の鍵」として導入した設計判断が、数十年後の「何をサンプリングするか」論争（Hindsight/TraStrainer/Astraea/Mint）を生んだ。(Source: [[@2022__IEEE ACCESS__A Survey on Observability of Distributed Edge & Container-Based Microservices]]) - **「サンプリング/圧縮で量を減らす」議論の手前に「トレース品質が分析の天井」という診断がある**: 本 wiki がこれまで蓄積してきた知見は「どう取るか(計装)」「いつ収集するか(Hindsight)」「何を優先するか(TraStrainer/Astraea)」「どう近似保持するか(Mint)」「どう圧縮するか(Tracezip)」と、いずれもトレースの**量**を制御する側面に集中してきた。これに対し [[@2021__J Grid Computing__Automated Analysis of Distributed Tracing - Challenges and Research Directions]] は、Huawei OpenStack 本番トレース 2 日分 (190K–240K spans/日) で OpenTracing 準拠データに Isolation Forest を適用した実証から、「ゲートウェイ計装の欠落(endpoint 未記録)で work-flow 深掘りができず、分析の天井はアルゴリズムではなくトレース品質([[トレース品質]])にあった」と診断した。後の DeepFlow/ChainScope が非侵入計装で同型の盲点(memcached カバレッジ・親子関係欠落)を解決しようとする方向は、Bento+ が指摘した「data sufficiency」課題への 5 年後の応答として読める。「量の最適化」と「品質の確保」は同じ「下流分析の精度を支配する上流プロセス」という認識で連続している。(Source: [[@2021__J Grid Computing__Automated Analysis of Distributed Tracing - Challenges and Research Directions]], [[@2026__CoNEXT__ChainScope - Balancing Accuracy and Overhead in Non-intrusive Distributed Tracing of Microservices]]) - **ログベース非侵入トレーシングの起源は lprof(OSDI 2014)**: Dapper/X-Trace が「計装ベース」の実用化を進める一方、lprof はランタイムログと Java バイトコード静的解析のみでリクエストフローを再構築する最初の系統を確立した。ログ形式文字列の解析・リクエスト識別子のデータフロー追跡・DAGによる部分順序制約・スレッド間通信ペアの検出という4段階の静的解析で、200ノード・8200万件のログから平均88.2%の帰属精度を達成した。計装コストを払わずに済む代わりに「ログを出力しない処理は不可視」という原理的限界がある。後の ChainScope/DeepFlow(eBPF・ネットワーク層観測)が同じ「非侵入」目標に向かうが、観測シグナルの層が異なる——lprof がアプリ層ログを使い ChainScope がネットワークパケットを使う。(Source: [[@2014__OSDI__lprof - A Non-intrusive Request Flow Profiler for Distributed Systems]], [[@2026__CoNEXT__ChainScope - Balancing Accuracy and Overhead in Non-intrusive Distributed Tracing of Microservices]]) - **Pinpoint(DSN 2002)は分散トレーシングを「障害箇所特定の入力」として使った最初の系統であり、トレースの利用目的を性能分析から診断へ拡げた**: X-Trace・Magpie が「リクエストの経路をどう追跡するか」(計装と因果連鎖)を問うたのに対し、[[@2002__DSN__Pinpoint - Problem Determination in Large, Dynamic Internet Services]] は J2EE ミドルウェア計装で得たリクエスト単位のコンポーネントアクセスパターンを決定木・χ²検定の入力とし、「どのコンポーネントが障害と統計的に相関するか」を自動特定した。トレースを**統計的障害診断の入力**として使う系譜は、後の MetricSifter・BARO・CloudRanger 等のメトリクス/グラフベース RCA へ分岐する一方、Pivot Tracing は「トレースそのものを動的に定義する」方向へ進化し、Canopy は「トレースを性能分析パイプラインへ接続する」方向へ進化した——Pinpoint が開いた「何のためにトレースするか」の分岐点が 2002 年にある。(Source: [[@2002__DSN__Pinpoint - Problem Determination in Large, Dynamic Internet Services]], [[@2007__NSDI__X-Trace - A Pervasive Network Tracing Framework]]) - **非集計(dis-aggregated)トレースを RCA の一次信号として活用することは、集計ベース手法が見逃す部分的・断続的障害の障害箇所特定精度を改善する**: Pinpoint が「トレースを統計的障害診断の入力として使う」系譜を 2002 年に確立したのに対し、[[@2021__JSEP__TraceRank - Abnormal service localization with dis-aggregated end-to-end tracing data in cloud native systems|TraceRank]]([[@2021__JSEP__TraceRank - Abnormal service localization with dis-aggregated end-to-end tracing data in cloud native systems]], JSEP 2021)はトレースの使い方を「集計平均→個別リクエスト単位」に深化させる。集計済みトレース(サービスごとの 1 分平均レイテンシ)では部分的障害(一部のリクエストのみ影響)や断続的障害で正常と異常が平均されて根本原因が隠蔽される問題を、個別リクエストを「テストケース」と見立てた SBFL スペクトル解析で解消する。ef(障害トレース中で通過したリクエスト数)/ep/nf/np の 4 統計量を全トレースから集計する設計は、分散トレーシング基盤(Dapper/Jaeger)が生成する全リクエストトレースを計算効率良く分析する後処理パイプラインとして機能する。AIOps Challenge 2020(China Mobile 本番)での検証で Precision 90%・Recall 86% を達成し、「dis-aggregated トレースを RCA の細粒度信号として活用する」実務的実現可能性を実証した。この路線は Canopy が「トレースを性能分析パイプラインへ接続する」方向へ進化したのと対比し、「トレースを統計的 RCA へ接続する」という第三の進化方向として Pinpoint の次の段として位置づけられる。(Source: [[@2021__JSEP__TraceRank - Abnormal service localization with dis-aggregated end-to-end tracing data in cloud native systems]], §2, §3.2) - **Pivot Tracing(SOSP 2015)の happened-before 結合は「何を計測するか」を実行時に定義する初の汎用フレームワークを確立した**: Dapper/X-Trace/Magpie が計装時に計測点を固定するのに対し、[[@2015__SOSP__Pivot Tracing - Dynamic Causal Monitoring for Distributed Systems]] はバイトコード書き換えで実行中にトレースポイントを挿入し、happened-before 関係に沿って因果結合を行う。これにより「問題が起きてから計測項目を定義し、再デプロイなしに診断する」運用が可能になった。後の eBPF ベースの動的計装(eInfer/ChainScope)が「非侵入 + 動的」を実現する系譜の、アプリ層での先行事例。(Source: [[@2015__SOSP__Pivot Tracing - Dynamic Causal Monitoring for Distributed Systems]], [[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]]) - **Canopy(SOSP 2017)は数十億リクエスト/日の本番規模で「トレース → 特徴量抽出 → 分析パイプライン」の全系路を初めて報告した**: Dapper が計装とサンプリングの設計を、Hindsight が収集の最適化を、TraStrainer がサンプリングと RCA 精度の連動を論じたのに対し、Canopy は Facebook 本番でトレースモデル → 特徴量抽出 DSL → パフォーマンスデータセット → Scuba 統合という完全なパイプラインを構築し、「トレースを取った後にどう分析するか」の工学を体系的に報告した。コールパス 80% 打ち切りという妥協は、後の Mint のトポロジ圧縮が「構造を保持して圧縮する」設計と対照的であり、規模と情報完全性のトレードオフの最初の定量的事例である。(Source: [[@2017__SOSP__Canopy - An End-to-End Performance Tracing And Analysis System]], [[@2025__ASPLOS__Mint - Cost-Efficient Tracing with All Requests Collection via Commonality and Variability Analysis]]) - **「計装ベース vs 非侵入ベース」の二項対立は「何を非侵入とするか」の定義で変わる**: Dapper(Google)やX-Trace はアプリコードへの計装を前提とし、lprof はソースコード改変なし(但しバイトコード読み取りは行う)、ChainScope/DeepFlow はプロセス内計装なし(ネットワーク/カーネル観測のみ)と、「非侵入」の範囲が3段階に分かれる。OpenTelemetry Java エージェント等の自動計装が普及した現代では、lprof 系の「ソースコード改変なし」手法の差異が縮まっており、lprof の価値はレガシーシステムや Java エージェントを導入できない環境に移行している可能性がある。(Source: [[@2014__OSDI__lprof - A Non-intrusive Request Flow Profiler for Distributed Systems]]) - **スパンツリー上の動的因果推論が「教師なし・リアルタイム」で障害箇所特定に使えることを実証した**: Pinpoint(2002)が「リクエストトレース × 統計クラスタリング」でコンポーネント障害箇所特定を確立したのに対し、[[@2022__IEEE CLOUD__Localizing and Explaining Faults in Microservices Using Distributed Tracing|FSF]](Faulty Service Finder、[[@2022__IEEE CLOUD__Localizing and Explaining Faults in Microservices Using Distributed Tracing]]、IEEE CLOUD 2022)はその系譜をさらに洗練させる。各リクエストのスパンツリーをその場で解析し「エラーのある子スパンを持つスパンは根本原因候補から除外する」という動的因果推論により、Train-Ticket 41 サービスへの 68 件の障害注入実験で **loss=0** を達成する。Pinpoint が「どのコンポーネントが失敗リクエストと統計的に相関するか」を集約統計で当てるのに対し、FSF は「各リクエストのスパンツリーをリアルタイムに解析して動的に因果モデルを抽出する」——静的依存グラフを一切使わず教師なし学習も不要。コンテキスト対応ログマイニング(特定障害スパンの時間窓内ログのみ抽出)を組み合わせることで、「トレースが『どこ』を特定し、ログが『なぜ』を補完する」異種テレメトリ融合の実用的な設計パターンを示した。(Source: [[@2022__IEEE CLOUD__Localizing and Explaining Faults in Microservices Using Distributed Tracing]]、[[@2002__DSN__Pinpoint - Problem Determination in Large, Dynamic Internet Services]]) - **OpenTracing 仕様の緩さが LLM 時代以前から自動分析を阻害してきた**: [[@2021__J Grid Computing__Automated Analysis of Distributed Tracing - Challenges and Research Directions]] §1・§5 は、OpenTracing 仕様の (a) タイムスタンプ単位の非明示(ms と μs が同データセット内で混在)、(b) annotation の任意 key-value 性、(c) testability の欠如、(d) dependency graph / span tree の生成・分析ツール欠如、を分析阻害要因として体系化した。これは Usman+ 2022 サーベイの「Dapper のイベントサンプリングで実用化された」観察と表裏一体——サンプリングで量を最適化しても、量を支える表現規約が緩いままなら自動分析は脆い。後継 [[OpenTelemetry]] は OpenTracing と OpenCensus の merge で進行中だが、Bento+ は「testability driver で再設計する立場が薄い」と批判し、品質メトリクスの量的規定を提言する。これは本 wiki が記録する OpenTelemetry 系の研究(Hindsight・TraStrainer・Mint)が「サンプリング/収集」を扱う一方で「規約側の testability」を扱わない非対称を示す。(Source: [[@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]]) - **LLM 時代以前のトレーシングベース異常検知は「派生メトリクスへの古典外れ値検知」が主流だった**: 既存の横断的知見は LLM 時代(2023–2026)のサンプリング・圧縮・カバレッジ最適化を中心に整理してきたが、より早い時代(2021)の [[OpenTracing Processor]] + Isolation Forest 構成は、トレースを「サービスメトリクス(in/out 呼数・平均応答時間)・dependency graph・work-flow」という派生表現に落とし、無ラベル教師なし外れ値検知を当てる解釈可能な系譜にあった。深層学習で trace を直接エンコードし二値分類する [[@2025__IWQoS__eACGM - Non-instrumented Performance Tracing and Anomaly Detection towards Machine Learning Systems|系譜]] や、LLM をメタ層に置く現代の系譜と並べると、「派生表現 → 古典 ML 外れ値検知」「raw トレース → DL 二値分類」「派生表現 → LLM/TSFM」という 3 段階の進化が見える。Bento+ は解釈性のため固定特徴セット + Isolation Forest を選んだが、それが結果として「異常な時間枠とサービスを示せても Why は work-flow 計装欠落で深追いできない」という品質律速に当たったことが、後の AIOps が品質確保(コードカバレッジ・semantic conventions・計装テスト)へ向かう動機の原点になっている。(Source: [[@2021__J Grid Computing__Automated Analysis of Distributed Tracing - Challenges and Research Directions]]) - **DeathStarBench(2019)の自作 trace は 0.1% overhead で Zipkin に倣った設計、OpenTelemetry 時代の参照点となる**: [[@2019__ASPLOS__An Open-Source Benchmark Suite for Cloud and IoT Microservices]] は Thrift timing interface で RPC 入出に timestamp を打ち、Zipkin Collector に倣った Trace Collector で Cassandra に格納する自作分散トレーシングを構築した。overhead は end-to-end latency の 0.1% 未満で、これは現在の OpenTelemetry agent + Jaeger backend([[@2026__SANER-C__TrainTicketTrace - A Multi-Fault Distributed Dataset for Microservice Fault Detection and Localization]])に置換可能な「最小要件」を初期に示した点で、Bento+ 2021 の OpenTracing 課題分析や Hindsight/TraStrainer の進化の比較基準として位置づけられる。同論文の応用が後続の [[Astraea]] による span-level sampling(DeathStarBench の Social Network 36 サービス・Media 38 サービス・Train Ticket 41 サービスで実証)に直接接続している。(Source: [[@2019__ASPLOS__An Open-Source Benchmark Suite for Cloud and IoT Microservices]], [[@2024__IEEE CLOUD__Astraea - Unleashing Performance Insights with Online Probabilistic Tracing]]) - **分散トレーシングの因果関係をアラートルーティングに応用する実務的実装**: [[@2019__SREcon19 EMEA__Are We All on the Same Page - Lets Fix That|Mineiro SREcon19 EMEA]] の [[Adaptive Paging]] は、OpenTracing セマンティック規約（`error`・`peer.service`・`span.kind`・`component`）を活用し、SLO 違反トレースのスパンツリーを `error=true` パスで再帰的に走査して根本原因サービスを特定、そのチームへ通知する。これは本 wiki が整理してきた分散トレーシングの「どう取るか（計装）」「どう減らすか（サンプリング/圧縮）」「どう分析するか（RCA）」に加え、「トレースをリアルタイムのオペレーション判断に接続する」実務的応用である。FSF（IEEE CLOUD 2022）が「エラーのある子スパンを持つスパンは根本原因候補から除外する」動的因果推論を形式化する 3 年前に、Zalando が同型のアルゴリズムを実運用のアラートハンドラに組み込んだ。計装欠落時に `peer.service` + `span.kind=client` で依存先を推定するフォールバックは、Bento+ 2021 が指摘した「トレース品質が分析の天井」という課題の実務的回避策でもある。(Source: [[@2019__SREcon19 EMEA__Are We All on the Same Page - Lets Fix That]], [[@2022__IEEE CLOUD__Localizing and Explaining Faults in Microservices Using Distributed Tracing]], [[@2021__J Grid Computing__Automated Analysis of Distributed Tracing - Challenges and Research Directions]]) - **TrainTicketTrace は「fault-injected trace」を OpenTelemetry/Jaeger フォーマットで公開する初の大規模 dataset**: [[@2026__SANER-C__TrainTicketTrace - A Multi-Fault Distributed Dataset for Microservice Fault Detection and Localization]] は 1 fault branch あたり約 440,000 traces を 10 branches 分(計 4.4M traces 規模)、Prometheus metric・Logback application log と共に Zenodo で公開。既存の trace-based anomaly detection 系研究([[@2025__IWQoS__eACGM - Non-instrumented Performance Tracing and Anomaly Detection towards Machine Learning Systems]]・DeepTraLog・TraceAnomaly・TracePicker など)が個別の閉じた dataset で評価していたのを、**共通フォーマット(Jaeger)・共通 system(TrainTicket 42 services)・共通 fault taxonomy(Gregor+ ICST 2025)** で並べる基盤を提供する。trace data quality(Bento+ 2021)の「analyzability の天井」問題にも、生成された trace 自身が test 起源で network/protocol 層の盲点を持つことを著者が明示するため、品質評価のメタ評価としても使える。(Source: [[@2026__SANER-C__TrainTicketTrace - A Multi-Fault Distributed Dataset for Microservice Fault Detection and Localization]], [[@2021__J Grid Computing__Automated Analysis of Distributed Tracing - Challenges and Research Directions]]) - **エージェントの選択がオーバーヘッドを 5 倍変える——業界標準の OpenTelemetry が最速でない**: [[@2026__ICPE__Benchmarking the Overhead of Distributed Tracing Agents]] は MooBench で 7 種の Java エージェントを統一比較し、コールツリー深度あたりのオーバーヘッドが Kieker(133.92 ns/depth)から inspectIT(656.79 ns/depth)まで約 5 倍の開きがあることを示した。業界標準の OpenTelemetry は 315.28 ns/depth と中間に位置し、Kieker の 2.4 倍。過度なメタデータ管理(HashMap の毎回コピー・リフレクション経由のメタデータ取得・ArrayBasedContext のスタックコピー)が主因と特定された。「標準化 = 軽量化」ではなく、標準仕様が要求する豊富なメタデータが実装コストを押し上げる。既存知見が「サンプリング・圧縮で量を減らす」を論じてきた一方、本研究は「計装自体のコストが実装選択で大きく変わる」という上流の問いを定量化した。(Source: [[@2026__ICPE__Benchmarking the Overhead of Distributed Tracing Agents]]) - **スパン損失は傾きの低さとして偽装される**: Pinpoint と Scouter はコールツリー深度スケーラビリティの傾きが小さいが(92.79・133.84 ns/depth)、これは性能が良いのではなく 30〜70% のスパンを無音で破棄するため。トレーシングの機能要件は「全スパンを転送すること」であり、スパン損失を見落とすと性能ランキングを誤解する。本 wiki の[[トレース品質]]が「品質が分析の天井」と指摘するのに対し、さらに上流の問題として「エージェントがそもそもスパンを落とす」バグが存在する。(Source: [[@2026__ICPE__Benchmarking the Overhead of Distributed Tracing Agents]]) ## 未解決の問い - socket-based 手法は packet forwarding(NAT)越しの依存を辿れないという共通の限界を持つ。forwarding history との突き合わせ以外に、relay 越しの call graph を完全化する手法はあるか。 - 構築した call graph を入力とする障害箇所特定 / RCA(異常伝播系、因果探索)は、メトリクスベースとどう統合されるか。path-oriented と time-oriented の分析を結ぶ一次ソースを ingest する([[テレメトリ]] の問いと共通)。 - eBPF ベースのトレーシングの社会実装([[go-conntracer-bpf]])は採用が初期段階。実運用での call graph 自動構築の事例・運用知見を持つ後続ソースを探す。 - アプリ層のサービス call graph(socket-based)と、LLM インフラ層のリクエスト/通信実行依存グラフ([[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]]・[[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]])は、同じ「分散トレーシング」として統合的に扱えるか。粒度(サービス/リクエスト/チャンク)をまたいだ trace の連結は可能か。 - 非侵入トレース(eBPF)とインバンドの計装トレース(Torch Profiler)は、どの粒度で層横断の根本原因特定に必要か。([[@2025__IWQoS__eACGM - Non-instrumented Performance Tracing and Anomaly Detection towards Machine Learning Systems]]) - Hindsight のイベントホライズン(既定 1 GB で約 1 分)は、LLM 推論/訓練のような長時間リクエストやバッチジョブに十分か。GPU クラスタの分散訓練では 1 ステップが数十秒に及ぶことがあり、トリガー遅延がイベントホライズンを超える可能性がある。([[@2023__NSDI__Hindsight - Tracing Edge-Cases in Distributed Systems]]) - 遡及的サンプリングのラテラルトレース(TriggerSet)は、[[マルチモーダル障害診断]] が求めるログ・メトリクス・トレースの統合をどう補完するか。トレース単体の時間的プロベナンスとメトリクスベースの RCA を結合する手法はあるか。 - TraStrainer がトレース情報とシステムメトリクスのマルチモーダル結合でサンプリング品質を向上させたが、サンプラーと下流 RCA を共同最適化（エンドツーエンド学習）する研究はあるか。現状はサンプリングと分析が独立したパイプラインである。([[@2024__FSE__TraStrainer - Adaptive Sampling for Distributed Traces with System Runtime State]]) - Astraea のスパンレベルサンプリングは MAB のオンライン学習で探索と活用をバランスさせるが、確率マッチング戦略が最適に収束するまでの初期(cold start)段階で見逃す性能変動はどの程度か。特に、デプロイ直後の急激な変動源の切り替わりで epsilon 探索(既定 5%)は十分か。([[@2024__IEEE CLOUD__Astraea - Unleashing Performance Insights with Online Probabilistic Tracing]]) - Astraea はリクエストベースサンプリングの上にスパンレベルを重ねるが、Hindsight の遡及的サンプリングや TraStrainer のシステム状態ベースサンプリングとの組み合わせは可能か。リクエスト/スパン/タイミングの 3 軸サンプリングを統合するフレームワークは存在するか。 - Mint の近似トレース(パターン + Bloom Filter)は非サンプリングトレースの約 80% のエクスプローラ機能を維持するが、残り 20%(具体的なパラメータ値に依存する分析)が欠落する。近似トレースだけで根本原因分析が成立する条件と、完全トレースが必要な条件の境界はどこか。([[@2025__ASPLOS__Mint - Cost-Efficient Tracing with All Requests Collection via Commonality and Variability Analysis]]) - Mint の Bloom Filter はメタデータ格納に偽陽性率 0.01 を設定するが、パターン数が増大するとノード間の上流下流検証コストが増加する。大規模(10 万マイクロサービス規模)でのスケーラビリティ限界はどこか。([[@2025__ASPLOS__Mint - Cost-Efficient Tracing with All Requests Collection via Commonality and Variability Analysis]]) - Tracezip の SRT はサービス単位で管理されるため、マイクロサービス数が極大(Alibaba の 20,000 超)になると SRT インスタンスの総数とバックエンドとの差分同期のオーバーヘッドが課題になる。Mint のトポロジベース圧縮と Tracezip のキー・バリューベース圧縮を組み合わせた場合、圧縮率の加法性はどの程度か。([[@2025__ISSTA__Tracezip - Efficient Distributed Tracing via Trace Compression]], [[@2025__ASPLOS__Mint - Cost-Efficient Tracing with All Requests Collection via Commonality and Variability Analysis]]) - DeepFlow のネットワーク中心アプローチは 47.3% のネットワーク起因性能問題を捕捉するが、残り 52.7%(アプリ/コンテナ/外部トラフィック)をネットワーク層の情報だけで切り分けられるのか。メトリクスベース [[Fault Localization]] との統合設計はどうあるべきか。([[@2023__SIGCOMM__Network-Centric Distributed Tracing with DeepFlow]]) - DeepFlow の暗黙のコンテキスト伝搬は TCP シーケンスの不変性に依存するため、QUIC(UDP ベース)や暗号化パケットでは TCP シーケンスが利用できない。QUIC 普及後の代替アプローチは何か。([[@2023__SIGCOMM__Network-Centric Distributed Tracing with DeepFlow]]) - ChainScope の IP レベルタギングはデータセンター内のネットワークポリシーが設定可能な環境に最適だが、ファイアウォールや WAN オプティマイザが IP/TCP カスタムオプションを除去する外部環境ではどう対処するか。([[@2026__CoNEXT__ChainScope - Balancing Accuracy and Overhead in Non-intrusive Distributed Tracing of Microservices]]) - **非集計トレースを RCA に使う場合、全リクエストのトレースをバックエンドへ保持するコストをどう削減するか**: TraceRank は全トレースを収集してスライディングウィンドウ内で分析する設計だが、Alibaba 規模(日量 18.6〜20.5 PB)ではサンプリングなしの全収集は現実的でない。Mint の「共通性+可変性分解で近似保持」や Tracezip の「KV ペア冗長性圧縮」と TraceRank の「全トレースからの ef/ep/nf/np 集計」の組み合わせは成立するか——近似トレースでスペクトル統計を計算した場合、Ochiai スコアの誤差はどの程度か。([[@2021__JSEP__TraceRank - Abnormal service localization with dis-aggregated end-to-end tracing data in cloud native systems]], [[@2025__ASPLOS__Mint - Cost-Efficient Tracing with All Requests Collection via Commonality and Variability Analysis]]) - **トレース品質の改善が下流分析の精度をどれだけ押し上げるかの定量実験はあるか**: Bento+ 2021 は work-flow 深掘りができなかった事例で「精緻なアルゴリズムより品質改善が先」と結論したが、「コードカバレッジ + temporal coverage」を改善した時の RCA/障害箇所特定の精度向上を関数形で示した後続研究はあるか。サンプリングと分析品質の連動(TraStrainer の知見)は本数次元での関数形を示すが、品質次元での同型は未解明。([[@2021__J Grid Computing__Automated Analysis of Distributed Tracing - Challenges and Research Directions]], [[@2024__FSE__TraStrainer - Adaptive Sampling for Distributed Traces with System Runtime State]]) - **lprof の「リクエストDB + SQL」パターンが LLM エージェントの tool call パターンの前身か**: lprof はリクエスト情報を MongoDB テーブルに格納し、診断者が仮説を変えるたびに異なる SQL クエリで探索的に分析する設計を採用した。これは後の [[Fault Localization]] で LLM エージェントが tool call でテレメトリを探索的に消費するパターン([[TSGuard]]・[[RCAgent]]等)と構造的に同型——人間の仮説主導の探索 vs エージェントの探索という違いはあるが、「構造化されたリクエストデータへのクエリで診断を進める」設計原則は共通する。(Source: [[@2014__OSDI__lprof - A Non-intrusive Request Flow Profiler for Distributed Systems]]) - **OpenTelemetry の testability driver 化はどう進んだか**: Bento+ 2021 が「OpenTelemetry は merge 努力が主で testability を driver にしていない」と批判した 2021 年以降、OpenTelemetry Semantic Conventions・Specification SIG はトレース品質の量的メトリクスを規定したか。トレース contract testing/lint を CI/CD に組み込む実装は本番でどこまで普及したか。([[@2021__J Grid Computing__Automated Analysis of Distributed Tracing - Challenges and Research Directions]]) - **OpenTelemetry の計装オーバーヘッドは改善の余地があるが、誰が改善を担うか**: [[@2026__ICPE__Benchmarking the Overhead of Distributed Tracing Agents]] は OpenTelemetry の HashMap コピー除去・スタックコピー除去・リフレクション回避で大幅なオーバーヘッド削減が可能と示した。標準仕様を保ちながら実装最適化を進める OSS コントリビューションが鍵になるが、OpenTelemetry の多言語・多機能スコープで誰がこれを担うかは未解決。 - **eBPF 非侵入トレーシングと Java エージェントの計装コストはどこで逆転するか**: ChainScope([[@2026__CoNEXT__ChainScope - Balancing Accuracy and Overhead in Non-intrusive Distributed Tracing of Microservices]])は CPU 2〜3%(1% サンプリング時)だが per-call 値でなく全体 CPU 消費率。Java エージェントの 133〜657 ns/call との直接比較には単位変換が必要。コールレートが高い(10M/sec 超)ほど per-call コストが支配的になり、eBPF ベースのサンプリングが有利になる閾値を定量化した研究はあるか。 ## 関連 - ソース: [[@2002__DSN__Pinpoint - Problem Determination in Large, Dynamic Internet Services]] / [[@2003__HotOS__Magpie - Online Modelling and Performance-aware Systems]] / [[@2014__OSDI__lprof - A Non-intrusive Request Flow Profiler for Distributed Systems]] / [[@2015__SOSP__Pivot Tracing - Dynamic Causal Monitoring for Distributed Systems]] / [[@2017__SOSP__Canopy - An End-to-End Performance Tracing And Analysis System]] / [[@2022__IEEE CLOUD__Localizing and Explaining Faults in Microservices Using Distributed Tracing]] / [[@2020__SAC__Black-box inter-application traffic monitoring for adaptive container placement]] / [[@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]] / [[@2023__NSDI__Hindsight - Tracing Edge-Cases in Distributed Systems]] / [[@2023__SIGCOMM__Network-Centric Distributed Tracing with DeepFlow]] / [[@2024__FSE__TraStrainer - Adaptive Sampling for Distributed Traces with System Runtime State]] / [[@2024__IEEE CLOUD__Astraea - Unleashing Performance Insights with Online Probabilistic Tracing]] / [[@2025__ASPLOS__Mint - Cost-Efficient Tracing with All Requests Collection via Commonality and Variability Analysis]] / [[@2025__ISSTA__Tracezip - Efficient Distributed Tracing via Trace Compression]] / [[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]] / [[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]] / [[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]] / [[@2025__IWQoS__eACGM - Non-instrumented Performance Tracing and Anomaly Detection towards Machine Learning Systems]] / [[@2026__CoNEXT__ChainScope - Balancing Accuracy and Overhead in Non-intrusive Distributed Tracing of Microservices]] - 概念: [[テレメトリ]] / [[トレースサンプリング]] / [[トレース品質]] / [[Fault Localization]] / [[根本原因分析]] / [[AIOps]] / [[eBPF]] / [[コンテナ配置最適化]] / [[GPU観測性]] / [[集合通信]] / [[LLM推論]] / [[マルチモーダル障害診断]] / [[暗黙のコンテキスト伝搬]] / [[Adaptive Paging]] - エンティティ: [[Pinpoint]] / [[Magpie]] / [[lprof]] / [[Pivot Tracing]] / [[Canopy]] / [[Dapper]] / [[go-conntracer-bpf]] / [[Hindsight]] / [[TraStrainer]] / [[Astraea]] / [[VAIF]] / [[Mint]] / [[Tracezip]] / [[OpenTracing]] / [[OpenTelemetry]] / [[OpenTracing Processor]] / [[Jonathan Mace]] / [[DeathStarBench]] / [[DeepFlow]] / [[@2022__IEEE CLOUD__Localizing and Explaining Faults in Microservices Using Distributed Tracing|FSF]] - 関連 MOC: [[SRE - MOC]] / [[異常検知 - MOC]] / [[AI Infra Telemetry - MOC]] ## 出典 - [[@2023__NSDI__Hindsight - Tracing Edge-Cases in Distributed Systems]](§3 遡及的サンプリングの抽象化、§4 データプレーン/コントロールプレーン分離・一貫性ハッシュ・トリガー機構、§6 93 サービス評価・UC1–UC3 ユースケース、§7 イベントホライズン・ラテラルトレース) - [[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]](§3.1–3.6 in-kernel flow bundling、socket-based 手法の分類・eBPF 実装・CPU/RTT 評価・限界) - [[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]](リクエスト単位のエンドツーエンド分散トレーシング) - [[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]](集合通信のフロー/チャンク単位トレース・依存追跡) - [[@2024__FSE__TraStrainer - Adaptive Sampling for Distributed Traces with System Runtime State]](§4 システムランタイム状態を考慮したバイアスサンプリング、§5 サンプリング品質と下流 RCA 精度の連動を実証) - [[@2024__IEEE CLOUD__Astraea - Unleashing Performance Insights with Online Probabilistic Tracing]](§III ベイズ学習+MAB によるスパンレベルサンプリング、§IV 92% Top-5 精度・計装 20-35% で VAIF/Log2 を上回る、§V 8 件のケーススタディ) - [[@2025__ASPLOS__Mint - Cost-Efficient Tracing with All Requests Collection via Commonality and Variability Analysis]](§2.2 Alibaba トレースの経験的研究・3 知見、§3 commonality + variability パラダイム・2 段階パース、§4 Bloom Filter メタデータ格納・2 種サンプラ、§5 ストレージ 2.7%・ネットワーク 4.2%・RCA top-1 精度 25%→50%) - [[@2025__ISSTA__Tracezip - Efficient Distributed Tracing via Trace Compression]](§2.2 トレースの冗長性分析(KV ペアの約 70% が反復)、§3 Span Retrieval Tree (SRT) の設計・Algorithm 1・リストラクチャリング・辞書圧縮、§4 ハッシュ加速・差分同期、§5 Train Ticket で gzip 併用 33% 改善・Alibaba 本番で lzma 併用 CR 13.69・スループット約 8 倍・空間 2.56MB) - [[@2021__J Grid Computing__Automated Analysis of Distributed Tracing - Challenges and Research Directions]](§1 OpenTracing 仕様の限界・§3 OTP アーキテクチャ・§4.1 Isolation Forest 異常検知・§4.2 temporal coverage・§5 trace 品質類型(data sufficiency / ontological / tools)) - [[@2022__IEEE CLOUD__Localizing and Explaining Faults in Microservices Using Distributed Tracing]](§III Algorithm 1 スパンツリー動的因果推論・§IV Train-Ticket 68 件 loss=0・§V ログのみ手法との比較・§VI 実践経験) - [[@2002__DSN__Pinpoint - Problem Determination in Large, Dynamic Internet Services]](§3 統計的コンポーネント障害特定・決定木/χ²検定・J2EE ミドルウェア計装・§4 PetStore/Auction 評価) - [[@2003__HotOS__Magpie - Online Modelling and Performance-aware Systems]](§2 スキーマ駆動イベントパーサ・リクエスト単位資源消費モデル・§3 ワークロードモデル応用) - [[@2015__SOSP__Pivot Tracing - Dynamic Causal Monitoring for Distributed Systems]](§3 happened-before join 演算子・バゲージ伝搬・§5 HDFS/HBase/MR/YARN 評価・§6 ケーススタディ) - [[@2017__SOSP__Canopy - An End-to-End Performance Tracing And Analysis System]](§2 トレースモデル・§3 特徴量抽出 DSL・§4 パフォーマンスデータセット・§5 Scuba 統合・コールパス 80% 打ち切り)