# bpftrace 2017 年に開発開始された eBPF トレーシング特化のスクリプト言語・ツール。カーネルとユーザ空間のコードを分離して書く必要がなく、ワンライナーや短いスクリプトでアドホックなトレーシングを実行できる。探索的なデバッグや観測に最適。 [[BCC]] がラピッドプロトタイピング用のフレームワークとして複数言語のフロントエンドを持つのに対し、bpftrace は「その場限りの計装」に特化した専用スクリプト言語として位置づけられる。本番実装には [[libbpf]] + CO-RE を用いる。 ## アプリケーション分析での使用例(詳解 システム・パフォーマンス 第2版 5章) `bpftrace -e` によるワンライナーで、次のようなアプリケーション分析ができる。 - **シグナルのトレーシング**: `syscalls:sys_enter_kill` トレースポイントで、送信元PID/プロセス名・宛先PID・シグナル番号を記録する。早期異常終了などの奇妙な問題のデバッグに役立つ。 - **I/Oのプロファイリング**: `recvfrom(2)` のバッファサイズや実行時間(開始・終了トレースポイントの差分)をヒストグラム(`hist()`)で可視化し、小規模I/Oの多発や大きなI/Oのレイテンシへの影響を調べる。 - **ロックのトレーシング**: `pmlock.bt`・`pmheld.bt` で pthread ミューテックスの獲得待ち時間・保持時間をスタックトレース付きで記録する。 - **アプリケーション内部の解析**: USDTプローブがあればそれを使い、なければ uprobe を使う。JITコンパイルされるソフトウェア(Javaなど)は uprobe で計装できないため動的USDTが必要になる場合がある。 (Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 5 アプリケーション]] §5.5.7〜§5.5.7.4) ## プログラミング言語としての bpftrace(詳解 システム・パフォーマンス 第2版 15章) 15章は bpftrace を「トレーシングの awk(1)」として位置づけ、言語構造を体系的に解説する。awk(1) が入力行を処理する部分的なプログラムを書くのに対し、bpftrace では入力イベントを処理する部分的なプログラムを書く。開発者は [[Alastair Robertson]] で、著者(Gregg)も主要なコントリビュータとして関与した。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 15 BPF]] §15.2) - **プログラム構造**: `probes /filter/ { actions }` という probe/filter/action の3要素からなる。フィルタが真のときのみアクションが実行され、awk(1) の `/pattern/ { actions }` に対応する。 - **プローブ書式**: `type:identifier1[:identifier2[...]]`。kprobe/kretprobe/uprobe/uretprobe/tracepoint/usdt/kfunc/kretfunc/software/hardware/watchpoint/profile/interval の12種と、識別子不要な特殊プローブ BEGIN/END がある。kfunc/kretfunc は eBPF トランポリンと BTF に基づく低オーバーヘッドの新インターフェイス。 - **変数の3種**: 組み込み(pid・tid・comm・nsecs 等、読み出し専用)・スクラッチ(` プレフィックス、代入されたアクションブロック内でのみ有効)・マップ(`@` プレフィックス、グローバルでアクション間のデータ受け渡しに使う BPF マップオブジェクト)。 - **マップ関数**: `count()`・`sum()`・`avg()`・`min()`・`max()`・`stats()`・`hist()`(2の累乗ヒストグラム)・`lhist()`(線形ヒストグラム)など。`print()`・`clear()`・`zero()` は非同期実行される。 - **オーバーヘッド管理**: ワイルドカードプローブの暴走を防ぐため `BPFTRACE_MAX_PROBES`(既定512)で上限を設定できる。1秒に10万回未満の kprobe/トレースポイントイベントを低頻度の目安とする。 (Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 15 BPF]] §15.2〜§15.2.5.5) ## エージェント利用での限界 LWN と LSFMM 2026 のスライドは、bpftrace の専用 DSL が人間の探索には有用でも、LLM には訓練データ不足、暗号的なエラー、型システム不足、表現力の制限、増分反復の不足という障壁を持つと指摘する。標準 Rust と構造化された verifier エラー、`bpftool`・[[drgn]] などを組み合わせる方向が対案として示される。(Source: [[@2026__LWN__BPF in the agentic era]], [[@2026__BPFConf2026__BPF in the Agentic Era (LSFMM 2026)]]) ## GPU ドライバ観測での使用例 eunomia.dev のチュートリアルは、bpftrace で DRM の `gpu_scheduler` トレースポイントに接続し、GPU ジョブの実行開始・完了・依存待ちを追跡する `drm_scheduler.bt` を示す。 同じ記事では NVIDIA proprietary driver の `nvidia.ko` 関数へ kprobe を設定する `nvidia_driver.bt` も扱うが、内部関数名に依存するため DRM の共通トレースより環境依存性が高い。(Source: [[@2025__eunomia.dev__eBPF Tutorial by Example - Monitoring GPU Driver Activity with Kernel Tracepoints]]) ## 関連 - ソース: [[@2021__yuuk.io__Linux eBPF Tracing Technology]] / [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 5 アプリケーション]] / [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 15 BPF]] / [[@2026__LWN__BPF in the agentic era]] / [[@2026__BPFConf2026__BPF in the Agentic Era (LSFMM 2026)]] / [[@2025__eunomia.dev__eBPF Tutorial by Example - Monitoring GPU Driver Activity with Kernel Tracepoints]] - エンティティ: [[BCC]] / [[libbpf]] / [[Alastair Robertson]] / [[Brendan Gregg]] - 概念: [[eBPF]] / [[GPUドライバトレーシング]] / [[動的計装|動的インストルメンテーション]] / [[システムコール]] / [[同期プリミティブ]]