# 動的計装 ## 定義 動的計装(dynamic instrumentation)とは、対象プログラムのソース改変・再コンパイル・再起動を伴わずに、実行中または実行直前にプローブを注入・除去して挙動を観測する技術である。DTrace は本番システムでのゼロ・プローブ効果と安全なプローブ実行を設計原則として確立し、Pivot Tracing はその動的性を分散システムの因果追跡へ拡張した。近年は eBPF の kprobe/uprobe/tracepoint、GPU への PTX 注入、NVBit による SASS 書き換え、LLVM パスによるコンパイル時計装まで対象が広がっている。(Source: [[@2004__USENIX-ATC__Dynamic Instrumentation of Production Systems]], [[@2015__SOSP__Pivot Tracing - Dynamic Causal Monitoring for Distributed Systems]], [[@2025__HCDS__eGPU - Extending eBPF Programmability and Observability to GPUs]]) [[zpoline]] はこの系譜をシステムコールの挙動変更へ広げる実装例である。 メモリ上の `syscall`/`sysenter` をバイナリ書き換えで置換し、観測だけでなくシステムコールエミュレーションやユーザー空間 OS サブシステムへの振り向けを可能にする。(Source: [[@2023__USENIX-ATC__zpoline - a system call hook mechanism based on binary rewriting]]) ### perf(1)の「プローブイベント」という統一呼称(13章) [[perf]](1) は [[kprobe]]・[[uprobe]]・USDT をまとめて「プローブイベント(probe event)」と呼ぶ。これらは「動的」であり、まず初期化しなければトレースできず、デフォルトでは `perf list` の出力に含まれない(一部の USDT プローブは自動的に初期化されるため例外的に表示される)。初期化後のプローブイベントは、実装(カーネル命令書き換え・ユーザー空間書き換え・静的メタデータ)の違いを問わず一様に "Tracepoint event" と表示される。たとえば kprobe ベースの `probe:do_nanosleep` も Tracepoint event と表示され、ツール利用者からは静的なトレースポイントと見分けがつかない。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 13 perf]] §13.3, §13.7) ## 横断的知見 - **perf(1) の「プローブイベント」という括りは、動的計装の異なる実装を単一の抽象化に押し込める具体例である**: 本ページはこれまで DTrace のゼロ・プローブ効果や Linux の安定/不安定 API 分離を「設計思想」のレベルで扱ってきたが、13章は perf(1) というツールの UI/UX レベルで同じ思想がどう具体化されるかを示す。kprobe(カーネル命令書き換え)・uprobe(ユーザ空間ブレークポイント)・USDT(静的メタデータ+uprobe)という実装の異なる3種類のプローブが、初期化前は「存在しない」、初期化後は同じ "Tracepoint event" 表示になるという perf(1) の挙動は、動的計装が利用者に対して「何が使われているか」より「今アクティブか」を優先的に見せる抽象化方針を採っていることを表す。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 13 perf]] §13.3, §13.7, [[@2004__USENIX-ATC__Dynamic Instrumentation of Production Systems]]) - **本番向け動的計装の核は、無効時ゼロ・プローブ効果と安全性である**: DTrace は、無効なプローブが実行時コストを生まず、誤ったプローブがシステム障害を起こさないことを本番導入の前提に置いた。この原則は、現代の [[eBPF]] verifier や kprobe/uprobe の動的アタッチにも継承される。(Source: [[@2004__USENIX-ATC__Dynamic Instrumentation of Production Systems]]) - **Pivot Tracing は「動的に何を測るか」と「分散境界を越えて因果を追う」を接続した**: DTrace や Fay が主に単一 OS インスタンス内の動的計装を扱ったのに対し、Pivot Tracing はバゲージ伝搬と happened-before join により、スレッド・プロセス・マシン境界を越える実行時クエリを実現した。動的計装が単なるプローブ挿入から、分散トレーシングの問い合わせ言語へ拡張された転換点である。(Source: [[@2015__SOSP__Pivot Tracing - Dynamic Causal Monitoring for Distributed Systems]]) - **計装を差し込む抽象度が、観測対象とオーバーヘッドを決める**: ホスト側 eBPF uprobe/tracepoint は推論ランタイム関数を低侵襲に捉えるが、GPU 内部のワープ実行や SM 利用率には届きにくい。PTX 注入(eGPU)、SASS 書き換え(NVBit)、LLVM コンパイル時計装は GPU 側に近づく代わりに、安全性・移植性・検証コストが重くなる。(Source: [[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]], [[@2025__HCDS__eGPU - Extending eBPF Programmability and Observability to GPUs]], [[@2024__TOPC__Low-Overhead Trace Collection and Profiling on GPU Compute Kernels]]) - **CUDA API 関数への uprobe は、動的計装の「ライブラリ境界」活用例を示す**: [[@2026__eunomia.dev__CUDA Events - eBPF-based CUDA API Tracing]] は `libcudart.so` の `cudaMalloc`/`cudaMemcpy`/`cudaLaunchKernel` などに enter/return プローブを動的にアタッチし、ソース改変なしで GPU 利用の入口をモニタリングする。ライブラリ境界の関数シグネチャに依存するため、CUDA ランタイムの ABI が変わらない限りアプリケーションレベルでの移植性は高いが、関数内部のメモリアクセスや分岐までは観測できない。(Source: [[@2026__eunomia.dev__CUDA Events - eBPF-based CUDA API Tracing]]) - **LLM 推論の観測では、タイムスタンプ収集から実行時意味の復元へ進んでいる**: ProfInfer は `ggml_tensor` 構造体を eBPF で辿り、演算子名・型・テンソル次元・活性化エキスパート ID を抽出する。動的計装は「いつ何が呼ばれたか」だけでなく、モデル実行の意味構造を復元する段階に入っている。(Source: [[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]]) - **観測性ツールは性能診断だけでなく正しさ検証にも使われる**: PICKER は GPU カーネルのメモリアクセスを動的に追跡し、起動引数からべき等性をマイクロ秒スケールで判定する。計装はプロファイリングの補助ではなく、チェックポイント対象を減らすための正しさ判定基盤にもなる。(Source: [[@2024__arXiv__Microsecond-scale Dynamic Validation of Idempotency for GPU Kernels]]) - **「安定APIか不安定APIか」という設計軸は、DTraceの安全性原則とLinuxカーネルの動的計装で異なる解決策をとる**: DTrace はゼロ・プローブ効果と安全性を本番導入の前提としたが([[@2004__USENIX-ATC__Dynamic Instrumentation of Production Systems]])、Linux カーネルは [[kprobe]](カーネル関数を直接書き換える不安定 API、5万種以上)と トレースポイント(安定 API だが数が限られる、約1,800種)を役割分担させることで安全性と網羅性を両立させている。『詳解 システム・パフォーマンス 第2版』4章は、この2つを「ロバストなツールにはトレースポイント、それがない箇所の掘り下げには kprobe」という明確な使い分けとして整理する。DTrace が単一の安全なプローブフレームワークで両立を図ったのに対し、Linux は安定/不安定の2層を明示的に分離するという異なる設計判断をとった。(Source: [[@2004__USENIX-ATC__Dynamic Instrumentation of Production Systems]], [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 4 可観測性ツール]]) - **動的計装の同じ実装技術が、観測と OS 機能の置換という異なる目的に使われる**: DTrace・eBPF・uprobe は主に実行状態の観測を目的とするのに対し、zpoline はシステムコールをユーザー空間実装へ振り向け、エミュレーションやネットワークスタックの置換を可能にする。ソース変更なしという導入条件が同じでも、観測精度だけでなく挙動の意味保存、隔離、セキュリティを別々に検証する必要がある。(Source: [[@2004__USENIX-ATC__Dynamic Instrumentation of Production Systems]], [[@2023__USENIX-ATC__zpoline - a system call hook mechanism based on binary rewriting]]) - **命令長と実行規約を利用した書き換えは、汎用的なプローブ API と異なる互換性の責任を負う**: uprobe は関数境界とシンボル・ABI の安定性に依存するが、zpoline は x86-64 の二バイト `syscall`/`sysenter`、`rax` の呼び出し規約、仮想アドレス 0 を前提にする。前者は関数単位の適用容易性、後者はシステムコール命令の網羅性を得る代わりに、アーキテクチャとメモリ保護の制約を引き受ける。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 14 Ftrace]], [[@2023__USENIX-ATC__zpoline - a system call hook mechanism based on binary rewriting]]) ## 未解決の問い - 稼働中 GPU カーネルへの PTX 注入や SASS 書き換えを、長期運用でどのように安全に検証するか。 - ランタイム関数シンボルに依存する eBPF 計装は、推論エンジン更新時にどこまで自動追従できるか。 - Pivot Tracing のバゲージ伝搬を、eBPF の非侵入計装だけでどこまで自動化できるか。 - 複数の動的プローブが同時に有効な場合の相互作用、オーバーヘッド、観測バイアスをどう評価するか。 - 安定API(トレースポイント)と不安定API(kprobe/uprobe)を分離する Linux の設計は、DTrace のような単一フレームワークによる安全性保証と比べて、ツール開発者の認知負荷・保守コストをどう変えるか。 - perf(1) が動的プローブを静的トレースポイントと同じ表示("Tracepoint event")で見せることは、利便性(統一的な操作性)と安全性(何が動的で不安定かを利用者が意識しにくくなる)のどちらに寄与するか。bpftrace や BCC のような高水準ツールはこの区別をどう扱っているか。 - 観測目的の動的計装と挙動変更目的のシステムコールフックを、共通の安全性・ロールバック・障害分離モデルで運用できるか。 - zpoline の二バイト置換を、JIT コード・共有ライブラリの遅延ロード・vDSO を含む現代アプリケーションへ拡張したとき、網羅性と保守性をどう保証するか。 ## 関連 - 概念: [[DTrace]] / [[eBPF]] / [[GPU観測性]] / [[プローブ効果]] / [[ハードウェアカウンタ]] / [[テレメトリ]] / [[分散トレーシング]] / [[LLM推論]] / [[kprobe]] / [[uprobe]] / [[システムコールフック]] / [[バイナリ書き換え]] - エンティティ: [[Pivot Tracing]] / [[BCC]] / [[libbpf]] / [[NVBit]] / [[CUPTI]] / [[PTX]] / [[Brendan Gregg]] / [[perf]] / [[zpoline]] - 関連 MOC: [[AI Infra Telemetry - MOC]] ## 出典 - [[@2004__USENIX-ATC__Dynamic Instrumentation of Production Systems]](DTrace の原理、ゼロ・プローブ効果、安全性、ユーザー/カーネル統合計装) - [[@2015__SOSP__Pivot Tracing - Dynamic Causal Monitoring for Distributed Systems]](バゲージ伝搬、happened-before join、分散動的計装) - [[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]](分散 LLM 推論の eBPF トレーシング) - [[@2025__HCDS__eGPU - Extending eBPF Programmability and Observability to GPUs]](GPU への PTX 注入型 eBPF) - [[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]](LLM 推論演算子とテンソル構造の実行時復元) - [[@2024__arXiv__Microsecond-scale Dynamic Validation of Idempotency for GPU Kernels]](GPU カーネルべき等性検証) - [[@2024__TOPC__Low-Overhead Trace Collection and Profiling on GPU Compute Kernels]](LLVM コンパイル時計装) - [[@2026__eunomia.dev__CUDA Events - eBPF-based CUDA API Tracing]](CUDA ランタイム API への uprobe 動的計装実装例) - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 4 可観測性ツール]](kprobe/uprobe/トレースポイントの安定性・オーバーヘッド実測値) - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 13 perf]](§13.3, §13.7 perf(1)の「プローブイベント」統一呼称) - [[@2023__USENIX-ATC__zpoline - a system call hook mechanism based on binary rewriting]](システムコール命令のバイナリ書き換えによる挙動変更)