# eBPF ## 定義 eBPF(extended Berkeley Packet Filter)は、Linux カーネル(およびユーザ空間ランタイム)で**サンドボックス化された小さなプログラムをカーネル再コンパイル・モジュール追加なしに安全に実行**する仕組み。verifier が事前にプログラムの安全性(終了性・メモリアクセス)を検査し、kprobe/uprobe・tracepoint・XDP/TC・LSM・sched_ext などのフックに接続して、カーネルの可視化(テレメトリ)とカーネル挙動の拡張(ネットワーク・セキュリティ・スケジューリング)を行う。([[@2026__eunomia.dev__eBPF × AI-LLMs - The Convergence of System Observability and AI]]) 本 vault では [[go-conntracer-bpf]](カーネル内フローバンドリング)がその社会実装の 1 つ。([[Scaling Telemetry Workloads in Cloud Applications]]) 現在の理解は次のように整理される。カーネル内で情報を絞り込む設計(集約・条件分岐・フィルタリング)は、トレーシング・ロギング・コンテナ監視など複数の応用で反復して有効性を示す設計指針である。GPU・LLM 推論・ML フレームワークへの適用は、ホスト側 uprobe から GPU 内部への PTX 注入まで計装点を多層化しつつ広がっている。sched_ext・cache_ext・struct_ops の系譜は eBPF の重心を観測から方針そのものの置換へ移しており、verifier は単体レベルの安全性を保証する一方、カーネルバージョン間の互換性や共存デプロイのライフサイクル管理は別の運用層に委ねられている。実務上は、eBPF を非侵襲トレーシングの主役技術と見る学術系譜と、既存計装のアクセラレータ/補完手段として位置づける実務書の評価のあいだに温度差が残る。 ## 子概念 - [[BPF]] - [[BPF arena memory]] - [[BPF verifier]] - [[CUDA]] - [[CUDA API トレース]] - [[Container Network Interface (CNI)]] - [[GPU観測性]] - [[IPCメトリクス]] - [[PTX 注入]] - [[Rust-BPF]] - [[XDP]] - [[agentic SRE]] - [[eBPFマップ]] - [[eGPU]] - [[uprobe]] - [[カーネル内VM]] - [[コンテキストスイッチ]] - [[サービストポロジ]] - [[システムコール]] - [[ゼロコード計装]] - [[パケットフィルタリング]] ## BPF から eBPF への系譜 [[BPF]](BSD Packet Filter)は 1993 年に [[Steven McCanne]] と [[Van Jacobson]] が [[Lawrence Berkeley National Laboratory]] で設計したカーネル内パケットフィルタリングアーキテクチャで、eBPF の直接的な先祖である([[@1993__USENIX__The BSD Packet Filter A New Architecture for User-level Packet Capture]])。BPF が確立した「レジスタベース VM + verifier + ユーザ空間コンパイル/カーネル内実行の分離」という設計原則は eBPF にそのまま引き継がれ、フックポイントと命令セットの大幅な拡張により汎用カーネル拡張機構へと発展した。詳細は [[BPF]] と [[カーネル内VM]] を参照。 XDP(eXpress Data Path)論文([[@2018__CoNEXT__The eXpress Data Path - Fast Programmable Packet Processing in the Operating System Kernel]])は、この拡張を具体的な数値で記録している。元のBPF仮想機械が32ビットレジスタ2個・22命令だったのに対し、eBPFはレジスタを11個・64ビット幅へ拡張し、64ビットアーキテクチャのハードウェアレジスタと1対1対応させることで効率的なJITコンパイルを可能にした。さらに、算術・論理命令の拡張とC言語同等の呼び出し規約を持つ関数呼び出し命令の追加により、LLVMコンパイラ基盤による(制限付き)C言語からのコンパイルが可能になった。(Source: [[@2018__CoNEXT__The eXpress Data Path - Fast Programmable Packet Processing in the Operating System Kernel]] §3.2) ## eBPF トレーシングの基礎技術(2021 時点) [[Yuuki Tsubouchi]] の技術解説([[@2021__yuuk.io__Linux eBPF Tracing Technology]])が体系化した基礎知識。eBPF×AI 研究群の実装的背景をなす。 **イベントソースの 2 系統**: - *動的計装*: Kprobe(カーネル関数、2004)・Uprobe(ユーザ空間関数、2012) - *静的計装*: tracepoints(カーネルイベント)・USDT(アプリ定義、アプリ対応が必要) **開発ツールチェーン(探索→プロトタイプ→本番)**: - **[[bpftrace]]** — アドホックトレーシング特化スクリプト言語(探索・デバッグ段階) - **[[BCC]]** — ラピッドプロトタイピング向けフレームワーク、70+ ツール内包 - **[[libbpf]] + CO-RE** — 本番実装。CO-RE(Compile Once - Run Everywhere)は BTF とランタイム再配置でカーネルバージョン横断のポータビリティを実現 これが [[go-conntracer-bpf]](カーネル内フローバンドリング、[[libbpf]] 実装)の技術的基盤であり、2024 年以降の [[eInfer]]・[[ProfInfer]]・[[eACGM]] における eBPF 計装の共通実装知識でもある。 - **eBPF のイベントソース(kprobe・tracepoint・USDT・perf_event)は、OS の割り込み/システムコールモデルの上に成立する。** - 根拠: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 3 オペレーティングシステム]] §3.2.3, §3.2.4, §3.4.4 — BPF プログラムがソケットイベント・トレースポイント・USDT・kprobe・uprobe・perf_event などのイベント発生時に実行されることを、システムコール(§3.2.3)・割り込み(§3.2.4)という OS の基本メカニズムの説明のあとに位置づける。システムコールがモードスイッチ・コンテキストスイッチを起こす、割り込みが同期/非同期に分かれるという基盤事実は、eBPF のイベントソースが偶然の実装詳細ではなく OS カーネルの構造そのものに由来することを裏づける - 根拠: [[@2021__yuuk.io__Linux eBPF Tracing Technology]] — 動的計装(kprobe/uprobe)・静的計装(tracepoints/USDT)の2系統として整理 ## カーネル内での情報削減という設計原則 - **本 wiki のアプリケーション層(AIOps/SRE)が観測した「テレメトリを取りすぎると害」という課題は、eBPF の世界ではカーネル内の高性能な検知/事前フィルタ層に徹するという設計指針として反復する。** - 根拠: [[@2026__eunomia.dev__eBPF × AI-LLMs - The Convergence of System Observability and AI]] — 重い ML/LLM 推論をユーザ空間へオフロードし eBPF はカーネル内の検知/事前フィルタ層に徹する設計(XDP/TC によるトラフィック事前選別、eBPF^ML の事前検証済みモデル)。データ削減を最上流(計装=カーネル)で行う発想 - 根拠: [[Scaling Telemetry Workloads in Cloud Applications]] — 計装層と分析層の両端で文脈を使って絞るという博士論文の設計指針と連続する - **eBPF の価値は「フックできること」自体でなく「高頻度イベントをカーネル内のどこで要約するか」にある。** - 根拠: [[@2017__brendangregg.com__Off-CPU Analysis]] — スケジューラのコンテキストスイッチを kprobe し、スタックと待機時間を eBPF map 内で集約してからユーザー空間へ渡す off-CPU 分析 - 根拠: [[@2020__SAC__Black-box inter-application traffic monitoring for adaptive container placement]] — `sock_sendmsg`/`sock_recvmsg` kprobe でカーネル内バイトカウンタを持たせ閾値超過時のみユーザー空間へ転送する KernelAgg 方式で 9% 未満のオーバーヘッド - 根拠: [[@2023__ICSE__LogReducer - Identify and Reduce Log Hotspots in Kernel on the Fly]] — `sys_write()` をインターセプトしログホットスポットをカーネル空間でドロップ、ログメッセージあたり最大 2,000 ns・CPU 0.008% で WeChat(60 万台)のストレージを 39.08% 削減 - 根拠: [[@2024__Preferred Networks__eBPFを用いてPod ごとのインターネットトラフィック量を計測するツールの開発]] — Chained CNI Plugin で TC へ eBPF をアタッチし Pod・Service・クラスタ外の 3 分類を per-CPU 配列へ集約、Node NAT 後には失われるテナント帰属を保ったまま外部帯域を集計 - 根拠: [[@2026__CoNEXT__ChainScope - Balancing Accuracy and Overhead in Non-intrusive Distributed Tracing of Microservices]] — `tcp_recvmsg`・`tcp_sendmsg` への単純なフック + IP レベルタギング + カーネル内フィルタリングに徹し、DeepFlow や Beyla の `bpf_probe_read_user` 多用に比べシステム全体の CPU を 2〜3% に抑える(1% サンプリング時のオーバーヘッドはサンプリング率に応じて低下、Figure 13a) - 留保: 重い処理(gRPC 内部データ構造のトラバース等)をカーネル内で行う DeepFlow・Beyla はこの原則の反例で、この差は高負荷・高並行環境でのみ明確に分離して現れる([[@2026__CoNEXT__ChainScope - Balancing Accuracy and Overhead in Non-intrusive Distributed Tracing of Microservices]]) - **カーネル内集約の設計は「フロー数」でなく「サービス数」を不変量にすることで、短命接続の増大に対する耐性を得る。** - 根拠: [[@2022__IPSJ JIP__Low Overhead TCP-UDP Socket-based Tracing for Discovering Network Services Dependencies]](Tsubouchi+, JIP 2022) — ハッシュテーブルのキーからエフェメラルポートを除外し(`{saddr, daddr, lport, direction, proto}` のみ)、同一宛先ネットワークサービスへの複数コネクションを 1 フローに束ねる [[go-conntracer-bpf]]。CPU オーバーヘッド 2.2% 以下(100 万 RTT/s でストリーミング手法は同条件で ~1,000% 超)で、[[ネットワーク依存性発見]] の CPU オーバーヘッド問題への直接回答になる - 反証: 先行する KernelAgg(Neves+2020)は「コネクション数」に比例してオーバーヘッドが増加する設計だった([[@2020__SAC__Black-box inter-application traffic monitoring for adaptive container placement]]) - **eBPF マップ自体の性能特性(メモリフットプリント・キャッシュホット性)が、情報を最上流で絞る設計指針の実装レベルの根拠を与える。** - 根拠: [[@2024__eBPF'24__Understanding Performance of eBPF Maps]] — array・hash・per-cpu 変種・ring/perf buffer・queue/stack を網羅的にベンチマークし、(a) メモリフットプリント(値サイズ・キーサイズ)とキャッシュホット性がオーバーヘッドの2大要因であること、(b) per-cpu hash マップは新規キー挿入時に全 CPU 分の値領域をゼロ初期化するためオーバーヘッドが増幅されること、(c) eBPF プログラムに「volume discount」特性(フック数が多いほど償却実行時間コストが下がる)があることを示した - **戻り値による条件分岐フィルタリングは、情報削減パターンを「常時絞る」から「イベントの性質(成功/失敗)で絞る」へ一般化する。** - 根拠: [[@2026__NAIC__RDMATracer - A scalable eBPF-based framework for tracing RDMA syscalls]](RDMATracer) — 「詳細トレースは失敗時にのみ有用」という経験的観察に基づき、`fentry`/`fexit` プローブが syscall の戻り値が非ゼロのときのみリングバッファへ emit する設計。per-CPU カウンタ配列(常時集計・ロスレス)とリングバッファ(失敗時のみ・オーバーフロー時は無音で欠落)という二重マップの組み合わせで、観測されるイベント率(約 3 失敗/秒/ホスト)に対し基盤の呼び出しレートが 10^3〜10^4 倍高い非対称性下でも成立する - 留保: ftrace では戻り値による事前フィルタが不可能なため、この非対称性下ではユーザ空間へ一度転送してから捨てる必要があり、スケールしないことが明らかになった([[@2026__NAIC__RDMATracer - A scalable eBPF-based framework for tracing RDMA syscalls]]) ## AI/MLワークロード可観測性とeBPFの相互応用 - **eBPF と AI の関係は双方向の共生ループとして整理される: eBPF for AI(カーネル層の高忠実度テレメトリで AI/ML ワークロードを観測・最適化)と AI for eBPF(LLM がカーネル拡張を生成・検証)。** - 根拠: [[@2026__eunomia.dev__eBPF × AI-LLMs - The Convergence of System Observability and AI]] — [[AgentSight]] の <3% オーバーヘッドのエージェント追跡・GPU の uprobe トレース・eGPU の GPU オフロードを eBPF for AI の例に、[[Kgent]]/[[GPTtrace]]・SimpleBPF・DiffSpec・LLM スケジューラ合成を AI for eBPF の例に挙げる - 留保: 本 wiki が一次で扱う AIOps/SRE 群はアプリケーション層の話であり、eBPF はその下のカーネル層で同じ「観測→診断/制御」を行う別レイヤーとして接続する([[@2026__eunomia.dev__eBPF × AI-LLMs - The Convergence of System Observability and AI]]) - **AI for eBPF では、LLM による生成を形式/意味検査で囲んだ閉ループにすることが信頼性確保の定石になる。** - 根拠: [[Kgent]] — LLM 生成 + Z3 記号検査 + テストで約 80% の精度([[@2026__eunomia.dev__eBPF × AI-LLMs - The Convergence of System Observability and AI]]) - 根拠: SimpleBPF — LLM 生成 + 意味検査 + LLM 最適化([[@2026__eunomia.dev__eBPF × AI-LLMs - The Convergence of System Observability and AI]]) - 根拠: DiffSpec — NL 仕様から差分テスト([[@2026__eunomia.dev__eBPF × AI-LLMs - The Convergence of System Observability and AI]]) - **awesome list が列挙していた「eBPF for AI」の方向性は、分散 LLM 推論・オンデバイス推論・GPU 内部トレースの一次研究群として実体化している。** - 根拠: [[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]] — 分散 LLM 推論のリクエスト単位トレース - 根拠: [[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]] — オンデバイス推論の演算子レベルプロファイリング - 根拠: [[@2025__HCDS__eGPU - Extending eBPF Programmability and Observability to GPUs]] — PTX 注入で eBPF を GPU 内へ拡張 - 根拠: [[@2025__eunomia.dev__The GPU Observability Gap - Why We Need eBPF on GPU devices]] — 既存 GPU ツールを「境界トレース/ベンダープロファイラ/研究ツール」の 3 類型に分類し、eBPF on GPU の位置づけを一般向けに整理 - 留保: これらの共通の主張(ソース改変なしの非侵襲・低オーバーヘッド計装が CUPTI/NVBit/Nsight のロックインと高オーバーヘッドを回避する)を支える著者陣には [[Yusheng Zheng]]・[[Yiwei Yang]] という [[eunomia-bpf]] 系の人脈の重なりがあり、awesome list の編者と研究実装の担い手が連続している - **eBPF の実行基盤がカーネル・ユーザ空間ランタイム・GPU へ多層化し、「どこで計装するか」が実行基盤の階層として再定義される。** - 根拠: [[bpftime]] — ユーザ空間 eBPF ランタイムとして uprobe 実行をユーザ空間に移しカーネルトラップを排除、uprobe/uretprobe を 1 桁以上高速化 - 根拠: [[@2025__OSDI__Extending Applications Safely and Efficiently]] — bpftime を拡張の安全性と相互接続性を細粒度に指定する Extension Interface Model(EIM)の実装基盤として定式化。これにより「検証付きサンドボックス実行」という設計パターンが、カーネル拡張だけでなくアプリケーション拡張(Nginx プラグイン、Redis 耐久性調整、FUSE キャッシングなど)へも適用される - 根拠: [[@2025__HCDS__eGPU - Extending eBPF Programmability and Observability to GPUs]] — bpftime を基盤に eBPF バイトコードを PTX に JIT して GPU カーネルへ注入。ホスト側 uprobe(eInfer/ProfInfer)は GPU 内部(SM 利用率)に届かない一方、PTX 注入はデバイス内に踏み込むが稼働中書き換えの安全性が課題 - 留保: [[テレメトリ]] の「計装をどこで行うか」の問いを GPU/デバイス層まで広げるが、これは実行基盤の階層(カーネル/ユーザ空間/GPU)の再定義であり、観測対象の階層の再定義ではない - **eBPF はカーネルネットワーク監視だけでなく、AI/ML フレームワーク層(CUDA/Python/PyTorch/NCCL)のユーザ空間関数トレースにも適用される。** - 根拠: [[@2025__IWQoS__eACGM - Non-instrumented Performance Tracing and Anomaly Detection towards Machine Learning Systems]] — 汎用 eBPF ツール(bcc・bpftrace)が捉えないフレームワークイベント・分散通信メトリクスを取得する(PyTorch ランタイム関数の特定にリバースエンジニアリングを要する) - **eBPF uprobe による CUDA API トレースは、ソース改変なしで GPU 利用のマクロ視図(メモリ割当・データ転送方向・カーネル起動・同期イベント)を提供する一方、GPU カーネル内部のスレッド動作までは届かない。** - 根拠: [[@2026__eunomia.dev__CUDA Events - eBPF-based CUDA API Tracing]] — `libcudart.so` の `cudaMalloc`・`cudaMemcpy`・`cudaLaunchKernel` などに uprobe/uretprobe をアタッチし、メモリ割当・データ転送方向・カーネル起動・同期イベントを ring buffer で収集。CUDA API 呼び出しあたり約 2 µs のオーバーヘッド - 留保: この「CPU 側入口の可視化」と「GPU 内部の可視化(eGPU/bpftime)」の 2 層構造は、[[GPU観測性]] が整理するホスト側 eBPF と PTX 注入の関係と対応する - **eBPF の共通フックとベンダー依存フックの境界は、GPU ドライバのトレースで明確に現れる。** - 根拠: [[@2025__eunomia.dev__eBPF Tutorial by Example - Monitoring GPU Driver Activity with Kernel Tracepoints]] — DRM の `gpu_scheduler` トレースポイントを Intel・AMD・Nouveau 共通の入口として使う一方、i915・AMDGPU の詳細イベントや NVIDIA proprietary driver の kprobe は個別実装に依存する。eBPF 自体のプログラム可搬性と、観測対象ドライバのイベント ABI 可搬性は別の問題である ## eBPFによる方針制御への拡張とverifierの保証範囲 - **eBPF の役割は観測(テレメトリ)からカーネル方針そのものの置換(制御)へ拡張し、sched_ext から cache_ext への連鎖がその重心移動を示す。** - 根拠: [[cache_ext]]([[@2026__TOCS__cache_ext - Customizing and Tracing the Page Cache with eBPF]]) — Linux ページキャッシュの退避・受け入れ方針そのものを `struct_ops`/kfunc で eBPF 実装に置き換える。[[sched_ext]](既に Linux にアップストリームされた eBPF スケジューラフレームワーク)を直接のモデルとし、「PID による識別子」「誤動作ポリシーを強制排除するウォッチドッグ」「特権ローダによる root 権限運用」というパターンをほぼそのまま踏襲しつつ、folio には PID 相当の一意識別子が無いという差異のためポインタベースの "valid folios registry" を新設した - 留保: [[Linuxカーネルインタフェース]] が整理した「拡張容易性」軸(struct_ops・kfunc)の実例でもある - **struct_ops は観測フックではなくカーネル方針そのものの置換点であり、ネットワーク(輻輳制御)とページキャッシュという異なるドメインで同じ拡張面が使われている。** - 根拠: [[@2024__SIGCOMM__NetEdit - An Orchestration Platform for eBPF Network Functions at Scale]] — BPF DCTCP / D2TCP / BET は Struct_ops(+Sockops)で輻輳制御を eBPF 実装し、カーネルロールアウトを待たずに CCA を反復する - 根拠: [[@2026__TOCS__cache_ext - Customizing and Tracing the Page Cache with eBPF]] — sched_ext の struct_ops/kfunc パターンで退避方針を置換する系譜と、ドメインは違うが同一のカーネル拡張面 - 反証: NetEdit は同一フック点での他プログラム実行阻止や再帰 struct_ops の未初期化レジスタといった、verifier 通過後に出るカーネル-eBPF 相互作用バグを本番で踏んだ([[@2024__SIGCOMM__NetEdit - An Orchestration Platform for eBPF Network Functions at Scale]]) - **「情報を絞る」設計指針は、観測データの削減だけでなく方針の意思決定そのものをカーネル内に留めることでも反復する。** - 根拠: [[@2026__TOCS__cache_ext - Customizing and Tracing the Page Cache with eBPF]] — ユーザ空間へ退避決定をオフロードする構成の「最善ケース」オーバーヘッド(既存トレースポイント + ロックレスリングバッファのみで実処理なし)を実測し、YCSB A/C/一様分布でそれぞれ -16.6%/-17.8%/-20.6% のスループット低下を確認。高頻度イベント(ページキャッシュは秒間数百万 IOPS)は、観測だけでなく意思決定そのものもカーネル内に置かないと成立しない - **eBPF は観測・方針置換だけでなく、高速パケット生成の送信データプレーンにも使える。** - 根拠: [[XDPerf]]([[@2026__KubeCon Japan Community Day__XDPerf - A High-Performance Traffic Generator Built with WASM and eBPF]]) — XDP の `BPF_PROG_TEST_RUN` live frames mode と `XDP_TX` を利用し、Wasm で起動時に定義したパケットテンプレートを eBPF マップから per-CPU に読み出して送信。eBPF の柔軟性を毎パケットの処理へ持ち込まず、検証器の制約を受けるカーネル側には差分適用とチェックサム処理だけを残す - **verifier が保証するのは単体レベルの安全性であり、百万台規模の共存配備にはカーネル既定の寿命管理・順序付けを上書きするオーケストレーション層が別途要る。** - 根拠: [[@2024__SIGCOMM__NetEdit - An Orchestration Platform for eBPF Network Functions at Scale]] — DataDog・bpfd・l3af・Cilium・PolyCube がインターフェース切り離しは持つ一方、BPF-to-BPF 切り離しとサービスライフサイクル連動の動的着脱を欠くと示す。NetEdit は pinning で参照カウント GC を外し、bpf-iter で既存コネクションへ遡及適用し、グローバル優先順位配列でフック点ごとの順序保証のばらつきを潰す - 留保: RDMATracer が「社内オーケストレーション経由でデプロイ」と述べる基盤がこの層である([[@2026__NAIC__RDMATracer - A scalable eBPF-based framework for tracing RDMA syscalls]]) - **verifier が保証しない「プログラム所有メモリのデータ競合」は、スピンロック・アトミック命令・per-CPU マップの 3 層防御で開発者が個別に埋める必要がある。** - 根拠: [[@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, §3.3.2) — verifier は「カーネル状態へのヘルパー関数経由アクセス」は検査する一方、eBPF マップのエントリ・値というプログラム所有メモリへの競合は検査対象外であることを明示。[[go-conntracer-bpf]] はこの隙間を、(1) マップ挿入時の `bpf_map_update_elem()` が内部で使うバケット単位のスピンロック、(2) 統計値更新のロックフリーなアトミック命令(`__sync_fetch_and_add()`)、(3) マルチコア競合を緩和する per-CPU マップ(`BPF_MAP_TYPE_PERCPU_HASH`)という 3 層で埋める - **verifier の安全性はカーネルバージョン横断の動作互換性を保証しない。** - 根拠: [[XDPerf]]([[@2026__KubeCon Japan Community Day__XDPerf - A High-Performance Traffic Generator Built with WASM and eBPF]]) — Linux 6.1 の可変オフセット追跡や 7.2 の BPF stack-arguments 変更に対応するため、bounds check、`__noinline`、ビルド修正を行い、6.1〜7.2 の multi-kernel CI を実行する - 根拠: NetEdit が経験した verifier 通過後のカーネル-eBPF 相互作用バグ([[@2024__SIGCOMM__NetEdit - An Orchestration Platform for eBPF Network Functions at Scale]])と合わせると、eBPF の検証は単体安全性と、カーネル・ドライバ・ライブラリの組み合わせ互換性を分けて扱う必要がある - **eBPF によるカーネル計装の目的軸は、性能診断・仕様準拠性検証に続き「稀少な相関バグの本番診断」へ広がっている。** - 根拠: [[@2026__NAIC__RDMATracer - A scalable eBPF-based framework for tracing RDMA syscalls]](RDMATracer) — 「5〜20%の AI 訓練ジョブ失敗が NIC ドライバのカーネルバグに起因するが、これを診断する既存の可観測性ツールがない」という不可視性に対処し、ホストカーネル側の verbs 層・ドライバ層のソースコードが公開されている領域に計装する - 留保: [[RDMA]] concept が集約する RNIC 研究(Collie・Husky・Lumina)は商用 RNIC を外部からブラックボックスとして扱い、RNIC 自体のマイクロアーキテクチャが見えないことに起因する問題を扱う。RDMATracer が対処するのはカーネル・ドライバコードは見えるが本番運用でその実行パスを追跡する仕組みがないという別種の不可視性であり、「見えない」の意味が異なる 2 つの障害モードとして区別できる - **エージェント時代の eBPF 拡張は、安全性を緩めるのではなく安全性を説明可能な開発経路へ写像する方向へ進む。** - 根拠: [[@2026__LWN__BPF in the agentic era]] — verifier をカーネル内の安全境界として維持しつつ、Rust の構造化診断、実行時検査、User Mode Linux、`bpftool`・`drgn`・`veristat` を組み合わせる提案を示す - 根拠: [[@2026__BPFConf2026__BPF in the Agentic Era (LSFMM 2026)]] — 既存の eBPF が提供してきた「未信頼コードの安全なカーネル内実行」に、エージェントが修正可能なフィードバック形式という新しい要件が加わった - **[[Rust-BPF]] の提案は、eBPF の表現力拡張をカーネル観測のための API 拡張としてではなく、Rust のメモリモデル・制御フロー・エラー処理をカーネル内へ写像する問題として扱う。** - 根拠: [[@2026__BPFConf2026__BPF in the Agentic Era (LSFMM 2026)]] — arena、`PTR_TO_FUNC`、widening、拡張呼び出し規約、`panic=unwind` を一つの設計として扱う - 根拠: [[@2026__LWN__BPF in the agentic era]] — eBPF が「小さなプローブを安全に動かす機構」から、検証可能な高水準プログラム実行基盤へ拡張する設計課題を示す - **eBPF verifier のレジスタ範囲追跡アルゴリズムは、2018 年の XDP 原論文の時点で既に確立していた。** - 根拠: [[@2018__CoNEXT__The eXpress Data Path - Fast Programmable Packet Processing in the Operating System Kernel]] §3.4 — 制御フローの DAG 構築 → 深さ優先探索によるループ検出 → 全経路を辿るレジスタ・スタック変数の状態(型・ポインタオフセット・値範囲)追跡という 2 パス構成、および「一分岐で R1 の最大値を 10、他方で最小値を 11 に設定する」といった条件分岐での範囲更新の具体例を示す。この 2 パス DAG 検証というアルゴリズムの骨格は、その後の verifier 拡張(bounded loops 対応、関数呼び出しサポート等、[[XDPerf]] が触れる 7.2 の BPF stack-arguments 変更等)の土台になっている ## 非侵襲トレーシング手段としての実務採用と評価の温度差 - **OBI は、eBPF ベースのゼロコード計装を従来のネットワーク/カーネル層からアプリケーション API 層・GenAI プロバイダまで拡張する。** - 根拠: [[OBI]](OpenTelemetry eBPF Instrumentation、[[@2026__OTelDocs__OBI - OpenTelemetry eBPF Instrumentation]]) — Grafana Beyla の後継として、eBPF プローブによるアプリケーション透過のトレース・メトリクス収集を 9 言語 × 8 プロトコル × 6 DB へ標準化した。Go・Rust 等のコンパイル言語でも、ソースへのトレースポイント追加を不要にする - 根拠: GenAI プロバイダ(OpenAI・Anthropic・Gemini・Bedrock・Qwen)のゼロコード計装も提供する([[@2026__OTelDocs__OBI - OpenTelemetry eBPF Instrumentation]]) - 根拠: HTTP ヘッダエンリッチメント(v0.7.0)ではスパンにテナント ID を付与し、インシデント対応時の影響範囲特定を高速化する(Source: [[@2026__OTelDocs__OBI - OpenTelemetry eBPF Instrumentation]]、[[@2026__OTelBlog__OBI HTTP Header Enrichment]]) - **実務書は eBPF 計装を非侵襲トレーシングの主役技術ではなく、既存計装の「アクセラレータ/ギャップフィラー」として位置づける。** - 根拠: [[@2026__OReilly__Observability Engineering 2E - Chapter 7 Instrumenting Your Code with OpenTelemetry]] — eBPF([[OBI]])を「アプリコードを変更できない/変更が困難な組織向けの補完手段」と位置づけ、既存の計装努力を置き換えるのではなく強化・ギャップ埋めするものと明言する。カーネル内で動くためプロセス外の追加ランタイムオーバーヘッドがなく、再起動・再コンパイルなしで有効化・無効化できる点を利点として挙げる一方、他の eBPF プログラムとの潜在的競合や、root 権限なしで動かす場合の権限設定といった運用上の懸念にも言及する - 留保: DeepFlow・ChainScope が示す高精度・低オーバーヘッドの実証結果は、eBPF を非侵襲トレーシングの主役級技術として扱う学術系譜を支えており、実務書の慎重な位置づけとの間に評価の温度差が残る - **サーバーレス環境で計装のステートフルな部分をランタイム制約の強い関数プロセスの外(拡張レイヤー)へ追い出す設計は、eBPF がアプリケーションプロセスの外(カーネル)で観測ロジックを実行する設計と同型である。** - 根拠: [[@2026__OReilly__Observability Engineering 2E - Chapter 7 Instrumenting Your Code with OpenTelemetry]] — AWS Lambda 向け statelessLambda tracing 戦略は、関数側をステートレスな SDK(生イベント送出のみ)に留め、拡張レイヤー内のステートフルな SDK と OpenTelemetry Collector 側でスパンを組み立てる - 留保: 両者とも「制約の強い実行環境からロジックを外出しする」という共通の設計パターンだが、代償としてどちらも外出し先(Collector・拡張レイヤー)の実装が複雑化するトレードオフを負う - **eBPF は AIOps・LLM 推論観測に限らず、サービス依存マップ構築という用途でも本番採用されている。** - 根拠: [[Netflix]] の Service Topology([[@2026__Netflix TechBlog__From Silos to Service Topology - Why Netflix Built a Real-Time Service Map]]) — eBPF でカーネルレベルのネットワークフローをキャプチャし、計装の有無を問わず全サービス間の実トラフィックを把握する。IPC メトリクス(計装済みサービスのエンドポイント詳細)・分散トレース(リクエスト経路)との 3 層融合で、カバレッジと精度を補完し合う設計を採る - **eBPF ベースの CNI(Cilium)が intra-host で iptables/Netfilter 処理を完全に迂回する点は、eBPF の制御パス(datapath)としての優位性の最も直接的な定量根拠になる。** - 根拠: [[@2021__TNSM__Assessing Container Network Interface Plugins - Functionality, Performance, and Scalability]] — veth にアタッチした eBPF プログラム(XDP・TC ingress/egress フック、`bpf_lxc`・`bpf_netdev`)がパケット転送とフィルタリングを一体化する Cilium の datapath を、CPU サイクル/パケット(CPP)で定量化した。intra-host では Cilium の eBPF オーバーヘッドは約 189 CPP で、他 CNI の Netfilter オーバーヘッド(約 245〜324 CPP)より低く、iptables チェーン数も 0(他 CNI は 3 チェーン/5 ルール) - 留保: inter-host では overlay 処理用の追加フックポイントにより eBPF オーバーヘッドが 236 CPP に増加し、「eBPF は常に最速」ではなく通過するフック数に依存することも示された([[@2021__TNSM__Assessing Container Network Interface Plugins - Functionality, Performance, and Scalability]]) ## 未解決の問い - PodごとにTCプログラムとIngress/Egressのper-CPU Mapを配置する方式は、Pod数・CPU数・Podの churn が大きいクラスタでもMap管理とメトリクス系列数を許容範囲に保てるか。PinningされたMapの回収とPrometheusの系列チャーンを含む運用評価が必要である。([[@2024__Preferred Networks__eBPFを用いてPod ごとのインターネットトラフィック量を計測するツールの開発]]) - RDMATracerの4ヒューリスティック(読み取り専用除外・汎用カーネル内部処理除外・クリーンアップパス除外・重要RDMAオブジェクト操作へ焦点化)は、他のカーネルサブシステム(ブロックI/O・ファイルシステム・スケジューラ)の稀少バグ診断へ一般化できるか。「名前空間ゲート+トークン正規表現」という機械的符号化パターンが、RDMA以外のサブシステムでも同程度の精度(recall=1.000, F1=0.765)を再現するかは未検証。([[@2026__NAIC__RDMATracer - A scalable eBPF-based framework for tracing RDMA syscalls]]) - RDMATracerが除外する「クリーンアップパス由来の失敗」(∼21%のGPU時間浪費に相当)はカーネルパニックとして表面化するため戻り値ゲート型トレーシングでは原理的に捕捉できない。パニック発生前の前兆シグナルをeBPFで捕捉する別の計装点(例: watchdogタイマー、panic直前のスタックトレース)と組み合わせれば、このカバレッジギャップを埋められるか。([[@2026__NAIC__RDMATracer - A scalable eBPF-based framework for tracing RDMA syscalls]]) - [[AgentSight]] はコーディングエージェント(claude code 等)をカーネル層で観測する。この**エージェント可観測性**を [[agentic SRE]] の安全制御([[SRE AI Autonomy Levels]]・[[Actus]])に接続し、「エージェントの行動をカーネルで監視・遮断する」一次研究は本 wiki にまだ無い。eBPF+LSM による AI エージェントのアクチュエーション制御を ingest して横断を厚くする。 - [[XDPerf]] の live frames mode は Linux 5.18 以降、XDP native/generic mode、NIC ドライバ、IOMMU、veth のキュー構成に依存する。eBPF プログラムの verifier が通ることと、パケット生成の実効性能が環境横断で再現することの間にある差を、どのような適合性試験で定義すべきか。(Source: [[@2026__KubeCon Japan Community Day__XDPerf - A High-Performance Traffic Generator Built with WASM and eBPF]]) - 本ソースは awesome list(二次情報)であり、各プロジェクトのオーバーヘッド/精度の主張は原典未確認。[[AgentSight]](arXiv:2508.02736)・[[Kgent]](eBPF'24)など中核論文を一次で取り込み、数値主張を裏取りする価値がある。 - eBPF を GPU(eGPU/gpu_ext)やユーザ空間([[bpftime]])へ広げる動きは、[[テレメトリ]] の「計装をどこで行うか」を再定義する。GPU クラスタ運用([[GPUクラスタ運用]]・[[LLM学習モニタリング]])のカーネル/デバイス層計装と、本 wiki の machine-level 箇所特定([[Pulse]]・[[Minder]])はどう接続するか。 - ホスト側 eBPF 傍受(eInfer/ProfInfer)は GPU 内部(SM 利用率・ワープ実行)に届かず[[ハードウェアカウンタ]]に依存が残る。PTX 注入([[@2025__HCDS__eGPU - Extending eBPF Programmability and Observability to GPUs]])がこの死角を埋めるとして、稼働中 GPU カーネル書き換えの長期安定性・安全性をどう担保するか([[GPU観測性]]・[[動的計装]] の問いと共通)。 - ランタイム関数シンボルに依存する eBPF 計装(eInfer)は推論エンジンのバージョン更新で保守コストが生じる。CO-RE 的可搬性を GPU/LLM ランタイムへどこまで持ち込めるか。 - eBPF uprobe による高頻度 AI/ML 関数トレースのオーバーヘッドは、数百〜数千 GPU 規模でどこまで「低オーバーヘッド」を保つか(eACGM の評価は 2 ノード止まり)。([[@2025__IWQoS__eACGM - Non-instrumented Performance Tracing and Anomaly Detection towards Machine Learning Systems]]) - bpftime のようなユーザ空間 eBPF ランタイムは、カーネル eBPF との機能差(例: syscall tracepoint は eBPF の方が速い)を考慮すると、どの観測シナリオで優位に働くか。カーネル内集約とユーザ空間実行の使い分け基準を整理する必要がある。 - [[cache_ext]] は eBPF に浮動小数点演算・成熟したカスタムデータ構造(赤黒木等)が無いため LHD の確率計算を整数近似する等の妥協を強いられた。eBPF の「検証器が許す表現力」がカーネル拡張の設計選択をどこまで制約しているか、他の eBPF ベース制御系(sched_ext・cache_ext・huge page 配置等)を横断して整理する価値がある。 - eBPF による「観測」から「方針の直接置換(制御)」への重心移動(sched_ext → cache_ext、huge page 配置・OOM killer への eBPF 拡張提案)は、[[agentic SRE]] が扱う「エージェントによる自動修復・自動アクチュエーション」とどう接続するか。カーネル層の eBPF 制御とアプリ層のエージェント制御が同じ設計原則(検証付きサンドボックス実行、フォールバック、ウォッチドッグ)を共有しているかを検証する余地がある。 - [[eBPFマップ]] の性能特性(メモリフットプリント・キャッシュホット性依存)は、本 wiki のトレーシング系論文(DeepFlow・ChainScope・eACGM 等)が採用するマップ利用パターン(値サイズ・マップサイズの選択)の設計判断をどこまで説明できるか。個別論文のマップ利用実装を [[@2024__eBPF'24__Understanding Performance of eBPF Maps]] の知見と突き合わせて検証する価値がある。 - **学術系譜の「eBPF は非侵襲トレーシングの主役技術たりうるか」と実務書の「あくまで補完的アクセラレータ」という評価の温度差は、どの条件で解消・逆転するか**: DeepFlow・ChainScope が示す高精度・低オーバーヘッドの実証結果は、`Observability Engineering` の慎重な位置づけを覆すだけの本番運用実績を積んでいるか。OBI のようなプロダクション指向ツールの普及率(Collector Follow-up Survey 等)が今後この評価をどう変えるか、継続的に追う価値がある。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 7 Instrumenting Your Code with OpenTelemetry]]) - NetEdit が挙げる「eBPF-カーネル経路のファジング」と「tuningFeature 組み合わせの相互作用解析」は、RDMATracer の戻り値ゲート型常時計装と同一ホストで共存するとき、フック点順序の固定配列が観測プローブの実行を阻害しないかを検証する必要がある。([[@2024__SIGCOMM__NetEdit - An Orchestration Platform for eBPF Network Functions at Scale]], [[@2026__NAIC__RDMATracer - A scalable eBPF-based framework for tracing RDMA syscalls]]) ## 未編纂の観察 > [!note]- 編纂前の観察 2026-09 > - **eBPF×AI は双方向の共生ループで整理される(eBPF for AI / AI for eBPF)**: [[@2026__eunomia.dev__eBPF × AI-LLMs - The Convergence of System Observability and AI]] は eBPF と AI の関係を 2 方向に分ける。(a)**eBPF for AI** — カーネル層の高忠実度テレメトリで AI/ML ワークロードを観測・最適化([[AgentSight]] の <3% オーバーヘッドのエージェント追跡、GPU の uprobe トレース、eGPU の GPU オフロード)。(b)**AI for eBPF** — LLM がカーネル拡張を生成・検証([[Kgent]]/[[GPTtrace]]、SimpleBPF、DiffSpec、LLM スケジューラ合成)。本 wiki が一次で扱ってきた AIOps/SRE 群が**アプリケーション層**の話だったのに対し、eBPF はその下の**カーネル層**で同じ「観測 → 診断/制御」を行う別レイヤーとして接続する。(Source: [[@2026__eunomia.dev__eBPF × AI-LLMs - The Convergence of System Observability and AI]]) > - **「情報を絞る」課題がカーネル層でも反復する**: 本 wiki の AIOps 群が観測した「テレメトリを取りすぎると害」([[agentic SRE]]・[[テレメトリ]]・[[特徴量削減]])は、eBPF の世界では「重い ML/LLM 推論はユーザ空間へオフロードし、eBPF はカーネル内の高性能な**検知/事前フィルタ層**に徹する」という設計指針(XDP/TC によるトラフィック事前選別、eBPF^ML の事前検証済みモデル)として現れる。データ削減を**最上流(計装=カーネル)**で行う発想は [[テレメトリ]] の博士論文の設計指針(計装層と分析層の両端で文脈を使って絞る)と連続する。(Source: [[@2026__eunomia.dev__eBPF × AI-LLMs - The Convergence of System Observability and AI]], [[Scaling Telemetry Workloads in Cloud Applications]]) > - **生成系を検証器で囲むのが AI for eBPF の定石**: [[Kgent]](LLM 生成 + Z3 記号検査 + テスト、約 80%)・SimpleBPF(LLM 生成 + 意味検査 + LLM 最適化)・DiffSpec(NL 仕様から差分テスト)は、いずれも LLM の生成を**形式/意味検査で囲んだ閉ループ**にして信頼性を担保する。これは [[agentic SRE]] の緩和で「安全に巻き戻せる反復」([[Transactional No-Regression]])が性能の源泉だったのと同型で、出力が実行時/カーネルにしか効かない領域では「検証付き反復」が共通の信頼性パターンになる。(Source: [[@2026__eunomia.dev__eBPF × AI-LLMs - The Convergence of System Observability and AI]]) > - **「eBPF for AI」が awesome list の例示から具体的な一次研究群へ実体化した**: 二次情報([[@2026__eunomia.dev__eBPF × AI-LLMs - The Convergence of System Observability and AI]])が eGPU・GPU uprobe トレースとして列挙していた方向が、いまや一次論文で裏付く——[[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]](分散 LLM 推論のリクエスト単位トレース)・[[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]](オンデバイス推論の演算子レベルプロファイリング)・[[@2025__HCDS__eGPU - Extending eBPF Programmability and Observability to GPUs]](PTX 注入で eBPF を GPU 内へ拡張)。共通の主張は「eBPF はソース改変なしの非侵襲・低オーバーヘッド計装で、ベンダー専用ツール(CUPTI/NVBit/Nsight)のロックインと高オーバーヘッドを回避する」点([[GPU観測性]]・[[動的計装]]に詳述)。eInfer/eGPU の著者には [[Yusheng Zheng]]・[[Yiwei Yang]] という [[eunomia-bpf]] 系の人脈が重なり、awesome list の編者と研究実装の担い手が連続している。さらに [[@2025__eunomia.dev__The GPU Observability Gap - Why We Need eBPF on GPU devices]] は、これら一次研究の技術的動機を一般向けブログとして整理し、既存 GPU ツールを「境界トレース/ベンダープロファイラ/研究ツール」の 3 類型に分類して eBPF on 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]], [[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]], [[@2025__eunomia.dev__The GPU Observability Gap - Why We Need eBPF on GPU devices]]) > - **eBPF の適用先がカーネルからユーザ空間ランタイム・GPU へ拡張し、「どこで計装するか」が再定義される**: [[bpftime]](ユーザ空間 eBPF ランタイム)を基盤に、[[@2025__HCDS__eGPU - Extending eBPF Programmability and Observability to GPUs]] は eBPF バイトコードを PTX に JIT して GPU カーネルへ注入する。ホスト側 uprobe(eInfer/ProfInfer)は GPU 内部(SM 利用率)に届かない一方、PTX 注入はデバイス内に踏み込むが稼働中書き換えの安全性が課題。eBPF の「フックをどの層に置くか」がカーネル/ユーザ空間/GPU と多層化し、[[テレメトリ]] の「計装をどこで行うか」の問いを GPU/デバイス層まで広げた。(Source: [[@2025__HCDS__eGPU - Extending eBPF Programmability and Observability to GPUs]], [[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]]) > - **「最小限の eBPF プローブ + カーネル内サンプリング」がマイクロサービス非侵襲トレーシングの設計上の勝因になる**: DeepFlow が重い `bpf_probe_read_user` ヘルパーで gRPC 内部データ構造をトラバースし CPU を飽和させ、Beyla が uprobe と文字列操作で同様に飽和するのに対し、ChainScope は `tcp_recvmsg`・`tcp_sendmsg` への単純なフック + IP レベルタギング + カーネル内フィルタリングに徹する。1% サンプリング時の eBPF オーバーヘッドはサンプリング率に応じて低下し(Figure 13a)、システム全体の CPU は 2〜3% にとどまる。eBPF の「最小フックで最大効果」という設計判断が、高負荷・高並行環境でのみ明確に分離して現れることを実験的に示した。(Source: [[@2026__CoNEXT__ChainScope - Balancing Accuracy and Overhead in Non-intrusive Distributed Tracing of Microservices]]) > - **eBPF を AI/ML フレームワーク層のユーザ空間関数トレースへ適用する**: [[@2025__IWQoS__eACGM - Non-instrumented Performance Tracing and Anomaly Detection towards Machine Learning Systems]] は eBPF をカーネルネットワーク監視ではなく AI/ML フレームワーク層(CUDA/Python/PyTorch/NCCL)のユーザ空間関数トレースへ適用し、汎用 eBPF ツール(bcc・bpftrace)が捉えないフレームワークイベント・分散通信メトリクスを取得する(PyTorch ランタイム関数の特定にリバースエンジニアリングを要する)。(Source: [[@2025__IWQoS__eACGM - Non-instrumented Performance Tracing and Anomaly Detection towards Machine Learning Systems]], [[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]]) > - **eBPF カーネル内集約はコンテナ間トラフィック監視の現実的なオーバーヘッド限界点を定めた**: Neves ら(SAC 2020)は `sock_sendmsg`/`sock_recvmsg` kprobe にカーネル内バイトカウンタを持たせ、閾値超過時のみユーザ空間へ転送する KernelAgg 方式で 9% 未満のオーバーヘッドを実現した。per-operation イベント送信(UserAgg)は 68% のオーバーヘッド、接続開閉のみ(Scope 方式)はオーバーヘッド 1% だがトラフィック量計測不能。「カーネル内で集約してから転送」という設計判断——kprobe/kretprobe 間で `<pid, sock>` マップを使って戻り値とソケットを突き合わせる実装——は、本 wiki の eBPF 系論文が繰り返し採用する「情報を最上流(カーネル)で絞る」パターンの初期の定量的根拠になる。構築した重み付き通信グラフ(Kafka + Neo4j)はコンテナ配置最適化([[コンテナ配置最適化]])に接続される。(Source: [[@2020__SAC__Black-box inter-application traffic monitoring for adaptive container placement]]) > - **eBPF はログの「書き込み自体を抑止する」最上流フィルタとしても機能する**: [[@2023__ICSE__LogReducer - Identify and Reduce Log Hotspots in Kernel on the Fly]] は eBPF で `sys_write()` をインターセプトし、ログホットスポット（少数テンプレートがストレージの大半を占有）をカーネル空間でドロップする。ログメッセージあたり最大 2,000 ns・CPU 0.008% の極低オーバーヘッドで、WeChat（60 万台）のストレージを 39.08% 削減した。これは本 wiki が積み上げてきた「計装層で情報を絞る」設計指針——[[テレメトリ]] の博士論文が言う「文脈豊富な両端で削減」——を eBPF でログのライフサイクル最上流（ディスク書き込み前）に適用した先行例であり、下流のログ圧縮やログパースが前提とする書き込み済みデータの量そのものを削る点で相補的。同時に [[eACGM]] の SYSU グループが 2025 年にさらに AI/ML 計装へ拡張する系譜の出発点でもある。(Source: [[@2023__ICSE__LogReducer - Identify and Reduce Log Hotspots in Kernel on the Fly]], [[Scaling Telemetry Workloads in Cloud Applications]]) > > - **OBI が eBPF ベースのゼロコード計装を GenAI プロバイダまで拡張する**: [[OBI]]（OpenTelemetry eBPF Instrumentation）は Grafana Beyla の後継として、eBPF プローブによるアプリケーション透過のトレース・メトリクス収集を 9 言語 × 8 プロトコル × 6 DB へ標準化した。Go・Rust 等のコンパイル言語でも、ソースへのトレースポイント追加を不要にする。さらに GenAI プロバイダ（OpenAI・Anthropic・Gemini・Bedrock・Qwen）のゼロコード計装も提供し、eBPF の適用先が従来のネットワーク/カーネル層から**アプリケーション API 層**へさらに拡張される。HTTP ヘッダエンリッチメント（v0.7.0）ではスパンにテナント ID を付与し、インシデント対応時の影響範囲特定を高速化する。（Source: [[@2026__OTelDocs__OBI - OpenTelemetry eBPF Instrumentation]]、[[@2026__OTelBlog__OBI HTTP Header Enrichment]]） > > - **実務書は eBPF 計装を「既存計装の代替」ではなく「アクセラレータ/ギャップフィラー」として明確に格下げする**: 本頁のこれまでの横断的知見は eBPF を非侵襲トレーシングの主役級技術(DeepFlow・ChainScope・eACGM 等)として扱ってきたが、`Observability Engineering` 第7章はより実務寄りの立場から、eBPF([[OBI]])を「アプリコードを変更できない/変更が困難な組織向けの補完手段」と位置づけ、既存の計装努力を置き換えるのではなく強化・ギャップ埋めするものと明言する。カーネル内で動くためプロセス外の追加ランタイムオーバーヘッドがなく、再起動・再コンパイルなしで有効化・無効化できる点を利点として挙げる一方、他の eBPF プログラムとの潜在的競合や、root 権限なしで動かす場合の権限設定といった運用上の懸念にも言及する。学術系譜が「非侵襲・低オーバーヘッドで計装層を代替できるか」を追求してきたのに対し、実務書は「計装ができない場合の次善策」という控えめな位置づけを取っており、両者の間には eBPF の役割認識に温度差がある。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 7 Instrumenting Your Code with OpenTelemetry]]) > - **サーバーレス環境の「ステートを外へ出す」設計は、eBPF が体現する「観測をアプリ外へ出す」設計思想の別表現である**: 本頁は「情報を最上流(カーネル)で絞る」という設計指針を繰り返し観察してきたが、`Observability Engineering` 第7章が紹介する AWS Lambda 向け statelessLambda tracing 戦略は、関数側をステートレスな SDK(生イベント送出のみ)に留め、拡張レイヤー内のステートフルな SDK と OpenTelemetry Collector 側でスパンを組み立てる。eBPF がアプリケーションプロセスの**外**(カーネル)で観測ロジックを実行するのと同型に、サーバーレスでは計装のステートフルな部分をランタイム制約の強い関数プロセスの**外**(拡張レイヤー)に追い出す。両者とも「制約の強い実行環境からロジックを外出しする」という共通の設計パターンだが、代償としてどちらも外出し先(Collector・拡張レイヤー)の実装が複雑化するというトレードオフを負う。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 7 Instrumenting Your Code with OpenTelemetry]]) > - **eBPF がサービストポロジの「ネットワーク層」計装として本番採用される**: [[Netflix]] の Service Topology([[@2026__Netflix TechBlog__From Silos to Service Topology - Why Netflix Built a Real-Time Service Map]])は、[[eBPF]]でカーネルレベルのネットワークフローをキャプチャし、計装の有無を問わず全サービス間の実トラフィックを把握する。IPC メトリクス(計装済みサービスのエンドポイント詳細)・分散トレース(リクエスト経路)との 3 層融合で、カバレッジと精度を補完し合う設計を採る。本事例は「eBPF = ネットワーク監視最上流」という役割を、AIOps・LLM 推論観測ではなく**サービス依存マップ構築**という用途で実証した点で、本 wiki の eBPF 用途カタログを広げる。(Source: [[@2026__Netflix TechBlog__From Silos to Service Topology - Why Netflix Built a Real-Time Service Map]]) > - **eBPF uprobe による CUDA API トレースが、GPU 利用のマクロ視図をソース改変なしで提供する**: [[@2026__eunomia.dev__CUDA Events - eBPF-based CUDA API Tracing]] は `libcudart.so` の `cudaMalloc`・`cudaMemcpy`・`cudaLaunchKernel` などに uprobe/uretprobe をアタッチし、メモリ割当・データ転送方向・カーネル起動・同期イベントを ring buffer で収集する実装例を示す。CUDA API 呼び出しあたり約 2 µs のオーバーヘッドで、GPU 利用ライフサイクルを再構成できるが、カーネル内部のスレッド動作までは届かない。この「CPU 側入口の可視化」と「GPU 内部の可視化(eGPU/bpftime)」の 2 層構造は、本 wiki が [[GPU観測性]] で整理したホスト側 eBPF と PTX 注入の関係を、チュートリアルという形で補強する。(Source: [[@2026__eunomia.dev__CUDA Events - eBPF-based CUDA API Tracing]], [[@2025__HCDS__eGPU - Extending eBPF Programmability and Observability to GPUs]]) > > - **カーネル内フローバンドリングはオーバーヘッドを「フロー数」でなく「サービス数」に依存させることで短命接続の増大を無効化する**: [[@2022__IPSJ JIP__Low Overhead TCP-UDP Socket-based Tracing for Discovering Network Services Dependencies]](Tsubouchi+, JIP 2022)は、eBPF + Kprobes でハッシュテーブルのキーからエフェメラルポートを除外し(`{saddr, daddr, lport, direction, proto}` のみ)、同一宛先ネットワークサービスへの複数コネクションを 1 フローに束ねる。既存のカーネル内集約手法(Neves+2020)が「コネクション数」に比例してオーバーヘッドが増加したのに対し、本手法は「サービス数」を不変量とすることで短命 TCP 接続が大量発生しても転送フロー数を抑制し、CPU オーバーヘッドを 2.2% 以下(100 万 RTT/s でストリーミング手法は同条件で ~1,000% 超)に保った。「情報を最上流(カーネル)で絞る」という eBPF 設計指針([[テレメトリ]] 博士論文の計装層削減テーゼ)の定量的実装事例であり、[[ネットワーク依存性発見]] の CPU オーバーヘッド問題への直接回答にもなる。実装: [[go-conntracer-bpf]](Linux 5.6+)。(Source: [[@2022__IPSJ JIP__Low Overhead TCP-UDP Socket-based Tracing for Discovering Network Services Dependencies]]) > > - **eBPF の適用層はカーネル・GPU に続き、ユーザ空間アプリケーション拡張へも広がる**: [[bpftime]] はユーザ空間 eBPF ランタイムとして、Linux カーネル eBPF の uprobe 実行をユーザ空間に移し、カーネルトラップを排除することで uprobe/uretprobe を 1 桁以上高速化する。OSDI'25 の [[@2025__OSDI__Extending Applications Safely and Efficiently]] は、bpftime を拡張の安全性と相互接続性を細粒度に指定する Extension Interface Model(EIM)の実装基盤として定式化した。これにより eBPF の「検証付きサンドボックス実行」という設計パターンが、カーネル拡張だけでなくアプリケーション拡張(Nginx プラグイン、Redis 耐久性調整、FUSE キャッシングなど)へも適用される。カーネル/ユーザ空間/GPU という多層化は、[[テレメトリ]] の「どこで計装するか」の問いを、観測対象の階層ではなく実行基盤の階層として再定義する。(Source: [[@2025__OSDI__Extending Applications Safely and Efficiently]], [[@2025__HCDS__eGPU - Extending eBPF Programmability and Observability to GPUs]]) > > - **eBPF の役割がテレメトリ(観測)からカーネル方針そのものの置換(制御)へ拡張し、「観測は eBPF・制御はカーネル」という暗黙の分業を崩す先行例が sched_ext → cache_ext と連鎖している**: 本 wiki のこれまでの eBPF 事例(DeepFlow・ChainScope・eACGM・eInfer 等)はいずれも eBPF を非侵襲な**観測**に用いていたのに対し、[[cache_ext]]([[@2026__TOCS__cache_ext - Customizing and Tracing the Page Cache with eBPF]])は Linux ページキャッシュの退避・受け入れ**方針そのもの**を `struct_ops`/kfunc で eBPF 実装に置き換える。この設計は [[sched_ext]](既に Linux にアップストリームされた eBPF スケジューラフレームワーク)を直接のモデルとし、「PID による識別子」「誤動作ポリシーを強制排除するウォッチドッグ」「特権ローダによる root 権限運用」という sched_ext のパターンをほぼそのまま踏襲しつつ、folio には PID 相当の一意識別子が無いという差異のためポインタベースの "valid folios registry" を新設した。これは eBPF が「カーネルを覗く」道具から「カーネルの一部を書き換える」道具へと重心を移す系譜の具体例であり、[[Linuxカーネルインタフェース]] が整理した「拡張容易性」軸(struct_ops・kfunc)の実例でもある。(Source: [[@2026__TOCS__cache_ext - Customizing and Tracing the Page Cache with eBPF]]) > - **「情報を絞る」設計指針が、退避方針の意思決定をカーネル内に留めることでも反復する**: cache_ext は、ユーザ空間へ退避決定をオフロードする構成の「最善ケース」オーバーヘッドを実測し(既存トレースポイント + ロックレスリングバッファのみで実処理なし)、YCSB A/C/一様分布でそれぞれ -16.6%/-17.8%/-20.6% のスループット低下を確認した。これは本 wiki が eBPF 系論文全般で観察してきた「情報を最上流(カーネル)で絞る」パターン([[テレメトリ]]・[[LogReducer]]・[[go-conntracer-bpf]])の逆方向の定量的裏付けであり、「高頻度イベント(ページキャッシュは秒間数百万 IOPS)は、観測だけでなく意思決定そのものもカーネル内に置かないと成立しない」ことを示す新しい知見である。(Source: [[@2026__TOCS__cache_ext - Customizing and Tracing the Page Cache with eBPF]]) > - **eBPF マップ自体の性能特性が「情報を最上流で絞る」設計指針の実装レベルの根拠を提供する**: 本 wiki の eBPF 系論文がこれまで扱ってきたのはトレーシング・制御アプリケーションとしての eBPF([[LogReducer]]・[[DeepFlow]]・[[cache_ext]] 等)であり、その基盤となる [[eBPFマップ]] 自体の性能特性は未整理だった。[[@2024__eBPF'24__Understanding Performance of eBPF Maps]] は array・hash・per-cpu 変種・ring/perf buffer・queue/stack を網羅的にベンチマークし、(a) メモリフットプリント(値サイズ・キーサイズ)とキャッシュホット性がオーバーヘッドの2大要因であること、(b) per-cpu hash マップは新規キー挿入時に全 CPU 分の値領域をゼロ初期化するためオーバーヘッドが増幅されること、(c) eBPF プログラムに「volume discount」特性(フック数が多いほど償却実行時間コストが下がる)があることを示した。これは本 wiki が繰り返し観察してきた「情報を最上流(カーネル)で絞る」という応用レベルの設計指針に対し、「なぜ小さな値サイズ・事前確保済み hash マップが有利か」という実装レベルの定量的根拠を与える。(Source: [[@2024__eBPF'24__Understanding Performance of eBPF Maps]]) > - **eBPFのアタッチ先(kprobe・tracepoint・USDT・perf_event)は、OSの割り込み/システムコールモデルの上に成立する**: 『詳解 システム・パフォーマンス 第2版』3章は、BPFプログラムが「ソケットイベント・トレースポイント・USDT・kprobe・uprobe・perf_eventなどのイベント発生時に実行される」ことを、システムコール(§3.2.3)・割り込み(§3.2.4)というOSの基本メカニズムの説明のあとに位置づけている。本wikiのeBPF系論文群がイベントソースを「動的計装(kprobe/uprobe) / 静的計装(tracepoints/USDT)」の2系統として扱ってきたのと対応するが、この教科書はさらにその手前にある「システムコールがモードスイッチ・コンテキストスイッチを起こす」「割り込みが同期/非同期に分かれる」という基盤事実を示し、eBPFのイベントソースが偶然の実装詳細ではなくOSカーネルの構造そのものに由来することを裏づける。(Source: [[@2021__yuuk.io__Linux eBPF Tracing Technology]], [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 3 オペレーティングシステム]] §3.2.3, §3.2.4, §3.4.4) > > - **戻り値ゲート型の常時稼働キャプチャが、性能異常検知とは異なる「稀少なカーネルバグの反応的捕捉」というeBPF応用軸を開く**: 本頁のこれまでのeBPF事例(DeepFlow・ChainScope・eACGM・LogReducer等)はいずれも高頻度イベントの継続的な観測・集約を扱うが、[[@2026__NAIC__RDMATracer - A scalable eBPF-based framework for tracing RDMA syscalls]](RDMATracer)は「詳細トレースは失敗時にのみ有用」という経験的観察に基づき、`fentry`/`fexit`プローブがsyscallの戻り値が非ゼロのときのみリングバッファへemitする設計を採る。per-CPUカウンタ配列(常時集計・ロスレス)とリングバッファ(失敗時のみ・オーバーフロー時は無音で欠落)という二重マップの組み合わせは、[[テレメトリ]]が言う「情報を最上流(カーネル)で絞る」パターンの新しい表現形——「常に絞る」のではなく「イベントの性質(成功/失敗)で条件分岐して絞る」——を提示する。観測されるイベント率(約3失敗/秒/ホスト)に対し基盤の呼び出しレートが10^3〜10^4倍高いという非対称性が、ftraceでは戻り値による事前フィルタが不可能なためユーザ空間へ一度転送してから捨てる必要があり、この非対称性下ではスケールしないことを明らかにした。(Source: [[@2026__NAIC__RDMATracer - A scalable eBPF-based framework for tracing RDMA syscalls]]) > - **eBPFによるカーネル計装が、性能診断(Collie/Husky)・仕様準拠性検証(Lumina)に続く第三の目的軸「稀少な相関バグの本番診断」を開く**: [[RDMA]] conceptが集約するRNIC研究(Collie・Husky・Lumina)はいずれも商用RNICを外部からブラックボックスとして扱い、探索的ワークロード駆動やin-networkイベント注入でRNIC内部の性能異常・仕様違反を発見する。対してRDMATracerはRNIC自体ではなく**ホストカーネル側のverbs層・ドライバ層のソースコードが公開されている領域**に計装し、「5〜20%のAI訓練ジョブ失敗がNICドライバのカーネルバグに起因するが、これを診断する既存の可観測性ツールがない」という別種の不可視性(ハードウェアのブラックボックス性ではなく、運用テレメトリの欠落)に対処する。RNIC自体のマイクロアーキテクチャが見えないことに起因する問題(Collie/Husky/Lumina)と、カーネル・ドライバコードは見えるが本番運用でその実行パスを追跡する仕組みがないことに起因する問題(RDMATracer)は、"見えない"の意味が異なる2つの障害モードとして区別できる。(Source: [[@2026__NAIC__RDMATracer - A scalable eBPF-based framework for tracing RDMA syscalls]]) > - **verifier が保証するのは単体安全性であり、百万台規模の共存配備にはカーネル既定の寿命管理・順序付けを上書きするオーケストレーション層が要る**: [[@2024__SIGCOMM__NetEdit - An Orchestration Platform for eBPF Network Functions at Scale]] は、DataDog・bpfd・l3af・Cilium・PolyCube がインターフェース切り離しは持つ一方、BPF-to-BPF 切り離しとサービスライフサイクル連動の動的着脱を欠くと示す。NetEdit は pinning で参照カウント GC を外し、bpf-iter で既存コネクションへ遡及適用し、グローバル優先順位配列でフック点ごとの順序保証のばらつきを潰す。RDMATracer が「社内オーケストレーション経由でデプロイ」と述べる基盤がこの層である。本頁が積み上げてきた「情報を最上流で絞る」観測系譜に対し、本ソースは**制御面のライフサイクル**を eBPF の本番要件として追加する。(Source: [[@2024__SIGCOMM__NetEdit - An Orchestration Platform for eBPF Network Functions at Scale]]) > - **struct_ops は観測フックではなくカーネル方針そのものの置換点であり、NetEdit の CCA tuningFeature と cache_ext は同じ拡張面をネットワークとページキャッシュで使っている**: NetEdit の BPF DCTCP / D2TCP / BET は Struct_ops(+Sockops) で輻輳制御を eBPF 実装し、カーネルロールアウトを待たずに CCA を反復する。これは [[cache_ext]] が sched_ext の struct_ops/kfunc パターンで退避方針を置換する系譜と、ドメインは違うが同一のカーネル拡張面である。NetEdit はさらに同一フック点での他プログラム実行阻止や再帰 struct_ops の未初期化レジスタといった、verifier 通過後に出るカーネル-eBPF 相互作用バグを本番で踏んだ。(Source: [[@2024__SIGCOMM__NetEdit - An Orchestration Platform for eBPF Network Functions at Scale]], [[@2026__TOCS__cache_ext - Customizing and Tracing the Page Cache with eBPF]]) > - **eBPF は観測・方針置換だけでなく、高速パケット生成の送信データプレーンにも使える**: [[XDPerf]] は XDP の `BPF_PROG_TEST_RUN` live frames mode と `XDP_TX` を利用し、Wasm で起動時に定義したパケットテンプレートを eBPF マップから per-CPU に読み出して送信する。eBPF の柔軟性を毎パケットの処理へ持ち込まず、検証器の制約を受けるカーネル側には差分適用とチェックサム処理だけを残す。(Source: [[@2026__KubeCon Japan Community Day__XDPerf - A High-Performance Traffic Generator Built with WASM and eBPF]]) > - **verifier の安全性はカーネルバージョン横断の動作互換性を保証しない**: [[XDPerf]] は Linux 6.1 の可変オフセット追跡や 7.2 の BPF stack-arguments 変更に対応するため、bounds check、`__noinline`、ビルド修正を行い、6.1〜7.2 の multi-kernel CI を実行する。NetEdit が verifier 通過後のカーネル-eBPF 相互作用バグを経験した事例と合わせると、eBPF の検証は単体安全性と、カーネル・ドライバ・ライブラリの組み合わせ互換性を分けて扱う必要がある。(Source: [[@2026__KubeCon Japan Community Day__XDPerf - A High-Performance Traffic Generator Built with WASM and eBPF]], [[@2024__SIGCOMM__NetEdit - An Orchestration Platform for eBPF Network Functions at Scale]]) > > - **verifier が保証しない「プログラム所有メモリのデータ競合」は、スピンロック・アトミック命令・per-CPU マップの 3 層防御で個別に埋める必要がある**: 本頁は verifier を「単体安全性の保証」として繰り返し扱ってきたが、[[@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, §3.3.2)は verifier が「カーネル状態へのヘルパー関数経由アクセス」は検査する一方、eBPF マップのエントリ・値というプログラム所有メモリへの競合は検査対象外であることを明示する。go-conntracer-bpf はこの隙間を、(1) マップ挿入時の `bpf_map_update_elem()` が内部で使うバケット単位のスピンロック、(2) 統計値更新のロックフリーなアトミック命令(`__sync_fetch_and_add()`)、(3) マルチコア競合を緩和する per-CPU マップ(`BPF_MAP_TYPE_PERCPU_HASH`)という 3 層で埋める。「verifier が保証する範囲」と「開発者が明示的な同期プリミティブで埋める範囲」の境界線を、カーネル内フロー束ねという具体的な実装が示した点が新しい。(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]]) > - **エージェント時代の eBPF は「安全性を緩める」のではなく「安全性を説明可能な開発経路へ写像する」方向へ進む**: LWN の報告と LSFMM 2026 のスライドは、verifier をカーネル内の安全境界として維持しつつ、Rust の構造化診断、実行時検査、User Mode Linux、`bpftool`・`drgn`・`veristat` を組み合わせる提案を示す。既存の eBPF が提供してきた「未信頼コードの安全なカーネル内実行」に、エージェントが修正可能なフィードバック形式という新しい要件が加わった。(Source: [[@2026__LWN__BPF in the agentic era]], [[@2026__BPFConf2026__BPF in the Agentic Era (LSFMM 2026)]]) > - **eBPF の表現力拡張は、カーネル観測のための API 拡張ではなく、Rust のメモリモデル・制御フロー・エラー処理をカーネル内へ写像する問題になる**: Rust-BPF の提案は arena、`PTR_TO_FUNC`、widening、拡張呼び出し規約、`panic=unwind` を一つの設計として扱う。これは eBPF が「小さなプローブを安全に動かす機構」から、検証可能な高水準プログラム実行基盤へ拡張する設計課題を示す。(Source: [[@2026__BPFConf2026__BPF in the Agentic Era (LSFMM 2026)]], [[@2026__LWN__BPF in the agentic era]]) > - **eBPF verifier のレジスタ範囲追跡アルゴリズムは、2018年のXDP原論文の時点で既に確立していた**: 本頁が集約する verifier 関連の知見の多くは応用側(検証を前提とした安全なカーネル拡張)を扱うが、[[@2018__CoNEXT__The eXpress Data Path - Fast Programmable Packet Processing in the Operating System Kernel]] は verifier 自体のアルゴリズムを詳述する一次資料である。制御フローのDAG構築 → 深さ優先探索によるループ検出 → 全経路を辿るレジスタ・スタック変数の状態(型・ポインタオフセット・値範囲)追跡という2パス構成、および「一分岐でR1の最大値を10、他方で最小値を11に設定する」といった条件分岐での範囲更新の具体例を示す。この2パスDAG検証というアルゴリズムの骨格は、その後のverifier拡張(bounded loops対応、関数呼び出しサポート等、[[XDPerf]]が触れる7.2のBPF stack-arguments変更等)の土台であり、「verifierが何を・どうやって検証するか」という実装レベルの詳細を本頁に初めて追加する。(Source: [[@2018__CoNEXT__The eXpress Data Path - Fast Programmable Packet Processing in the Operating System Kernel]] §3.4) > > - **off-CPU 分析は eBPF の「カーネル内集約」を、イベント頻度の高いスケジューラ計測へ適用した代表例である**: [[@2017__brendangregg.com__Off-CPU Analysis]] はスケジューラのコンテキストスイッチを kprobe し、スタックと待機時間を eBPF map 内で集約してからユーザー空間へ渡す。既存の通信監視・ログ削減・AI/ML 計装の事例と同じく、全イベント転送を避けることで計測の侵襲性を抑える設計であり、eBPF の価値が「フックできること」だけでなく「高頻度イベントをどこで要約するか」にあることを補強する。(Source: [[@2017__brendangregg.com__Off-CPU Analysis]], [[@2023__ICSE__LogReducer - Identify and Reduce Log Hotspots in Kernel on the Fly]], [[@2020__SAC__Black-box inter-application traffic monitoring for adaptive container placement]]) > - **Podのネットワークインターフェイスを計測点にすると、Node NAT後には失われるテナント帰属を保ったまま外部帯域を集計できる**: [[@2024__Preferred Networks__eBPFを用いてPod ごとのインターネットトラフィック量を計測するツールの開発]]は、Chained CNI PluginでTCへeBPFをアタッチし、Pod・Service・クラスタ外の3分類をper-CPU配列へ集約する。既存のKernelAggがソケット単位の通信グラフを作るのに対し、本手法はPodインターフェイス単位でテナントの帯域占有原因を特定する。両者は「高頻度パケットイベントをカーネル内で要約してからユーザー空間へ渡す」という設計原則を共有する。(Source: [[@2024__Preferred Networks__eBPFを用いてPod ごとのインターネットトラフィック量を計測するツールの開発]], [[@2020__SAC__Black-box inter-application traffic monitoring for adaptive container placement]]) > - **GPU ドライバのトレースでは、eBPF の共通フックとベンダー依存フックの境界が明確になる**: [[@2025__eunomia.dev__eBPF Tutorial by Example - Monitoring GPU Driver Activity with Kernel Tracepoints]] は DRM の `gpu_scheduler` トレースポイントを Intel・AMD・Nouveau 共通の入口として使う一方、i915・AMDGPU の詳細イベントや NVIDIA proprietary driver の kprobe は個別実装に依存させる。eBPF 自体のプログラム可搬性と、観測対象ドライバのイベント ABI 可搬性は別の問題である。(Source: [[@2025__eunomia.dev__eBPF Tutorial by Example - Monitoring GPU Driver Activity with Kernel Tracepoints]], [[@2018__CoNEXT__The eXpress Data Path - Fast Programmable Packet Processing in the Operating System Kernel]]) > - **eBPF ベースの CNI(Cilium)は intra-host で iptables/Netfilter 処理を完全に迂回し、これが CNI 性能比較における eBPF 優位性の最も直接的な定量根拠になる**: [[@2021__TNSM__Assessing Container Network Interface Plugins - Functionality, Performance, and Scalability]] は、veth にアタッチした eBPF プログラム(XDP・TC ingress/egress フック、`bpf_lxc`・`bpf_netdev`)がパケット転送とフィルタリングを一体化する Cilium の datapath を、CPU サイクル/パケット(CPP)で定量化した。intra-host では Cilium の eBPF オーバーヘッドは約 189 CPP で、他 CNI の Netfilter オーバーヘッド(約 245〜324 CPP)より低く、iptables チェーン数も 0(他 CNI は 3 チェーン/5 ルール)。本頁がこれまで「情報を最上流(カーネル)で絞る」パターンとして観察してきた設計指針が、ネットワーキングのデータパス(パケット転送そのもの)にも適用される具体例であり、トレーシング/観測用途とは異なる**制御パス(datapath)としての eBPF** の定量的裏付けを追加する。ただし inter-host では overlay 処理用の追加フックポイントにより eBPF オーバーヘッドが 236 CPP に増加し、「eBPF は常に最速」ではなく通過するフック数に依存することも示された。(Source: [[@2021__TNSM__Assessing Container Network Interface Plugins - Functionality, Performance, and Scalability]]) - [eBPFによる方針制御への拡張とverifierの保証範囲] NCCLbpf([[@2026__arXiv__NCCLbpf - Verified, Composable Policy Execution for GPU Collective Communication]])は、カーネル拡張点(struct_ops等)への方針置換の類比を GPU 集団通信ライブラリ([[NCCL]])のユーザ空間プラグイン ABI に写像し、[[bpftime]] のユーザ空間 eBPF ランタイムで tuner/profiler/net プラグインを検証済み・コンポーザブルなポリシーへ置き換える。verifier が保証するのはメモリ安全性・実行終了・スタック安全性・ヘルパー許可リストのみであり、意図的に劣化させたポリシー(channel 数 1 固定で AllReduce スループットを 87–95% 低下させる)も安全であるがゆえに verifier を通過してしまう事実を実測で示し、「verifier は意味的に正しい方針決定を保証しない」というカーネル eBPF での既知の限界がユーザ空間拡張でも同型に成立することを確認した。 ## 関連 - ソース: [[@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]] / [[@1993__USENIX__The BSD Packet Filter A New Architecture for User-level Packet Capture]] / [[@2020__SAC__Black-box inter-application traffic monitoring for adaptive container placement]] / [[@2021__yuuk.io__Linux eBPF Tracing Technology]] / [[@2023__SIGCOMM__Network-Centric Distributed Tracing with DeepFlow]] / [[@2026__eunomia.dev__eBPF × AI-LLMs - The Convergence of System Observability and AI]] / [[Scaling Telemetry Workloads in Cloud Applications]] / [[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]] / [[@2025__HCDS__eGPU - Extending eBPF Programmability and Observability to GPUs]] / [[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]] / [[@2025__IWQoS__eACGM - Non-instrumented Performance Tracing and Anomaly Detection towards Machine Learning Systems]] / [[@2023__ICSE__LogReducer - Identify and Reduce Log Hotspots in Kernel on the Fly]] / [[@2026__CoNEXT__ChainScope - Balancing Accuracy and Overhead in Non-intrusive Distributed Tracing of Microservices]] / [[@2026__Netflix TechBlog__From Silos to Service Topology - Why Netflix Built a Real-Time Service Map]] / [[@2025__OSDI__Extending Applications Safely and Efficiently]] / [[@2026__TOCS__cache_ext - Customizing and Tracing the Page Cache with eBPF]] / [[@2024__eBPF'24__Understanding Performance of eBPF Maps]] / [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 3 オペレーティングシステム]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 7 Instrumenting Your Code with OpenTelemetry]] / [[@2026__NAIC__RDMATracer - A scalable eBPF-based framework for tracing RDMA syscalls]] / [[@2024__SIGCOMM__NetEdit - An Orchestration Platform for eBPF Network Functions at Scale]] / [[@2021__TNSM__Assessing Container Network Interface Plugins - Functionality, Performance, and Scalability]] / [[@2024__Preferred Networks__eBPFを用いてPod ごとのインターネットトラフィック量を計測するツールの開発]] / [[@2026__LWN__BPF in the agentic era]] / [[@2026__BPFConf2026__BPF in the Agentic Era (LSFMM 2026)]] / [[@2026__OTelDocs__OBI - OpenTelemetry eBPF Instrumentation]] / [[@2026__OTelBlog__OBI HTTP Header Enrichment]] / [[@2018__CoNEXT__The eXpress Data Path - Fast Programmable Packet Processing in the Operating System Kernel]] / [[@2026__eunomia.dev__CUDA Events - eBPF-based CUDA API Tracing]] / [[@2025__eunomia.dev__The GPU Observability Gap - Why We Need eBPF on GPU devices]] / [[@2025__eunomia.dev__eBPF Tutorial by Example - Monitoring GPU Driver Activity with Kernel Tracepoints]] / [[@2022__IPSJ JIP__Low Overhead TCP-UDP Socket-based Tracing for Discovering Network Services Dependencies]] / [[@2017__brendangregg.com__Off-CPU Analysis]] - 概念: [[テレメトリ]] / [[agentic SRE]] / [[分散トレーシング]] / [[コンテナ配置最適化]] / [[GPUクラスタ運用]] / [[LLM学習モニタリング]] / [[ログ解析]] / [[暗黙のコンテキスト伝搬]] / [[Linuxカーネルインタフェース]] / [[eBPFマップ]] / [[コンテキストスイッチ]] / [[システムコール]] / [[RDMA]] / [[RDMAネットワーク監視]] / [[XDP]] / [[カーネルバイパスネットワーキング]] / [[Container Network Interface (CNI)]] - エンティティ: [[AgentSight]] / [[Kgent]] / [[GPTtrace]] / [[bpftime]] / [[eunomia-bpf]] / [[Yusheng Zheng]] / [[go-conntracer-bpf]] / [[LogReducer]] / [[BCC]] / [[bpftrace]] / [[libbpf]] / [[Yuuki Tsubouchi]] / [[DeepFlow]] / [[Francisco Neves]] / [[OBI]] / [[yunwei37]] / [[Extension Interface Model]] / [[cache_ext]] / [[cachestream]] / [[sched_ext]] / [[Brendan Gregg]] / [[Linux]] / [[AWS Lambda]] / [[Meta]] / [[Carnegie Mellon University]] / [[NCCL]] - 関連 MOC: [[AI Infra Telemetry - MOC]] ## 出典 - [[@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.3.2 データ競合対策: verifier が検査しないプログラム所有メモリ = eBPF マップへの競合を、スピンロック(`bpf_map_update_elem()`)・アトミック命令(`__sync_fetch_and_add()`)・per-CPU マップ(`BPF_MAP_TYPE_PERCPU_HASH`)の3層で防御) - [[@2024__eBPF'24__Understanding Performance of eBPF Maps]](eBPFマップ(array・hash・per-cpu変種・ring/perf buffer・queue/stack)の網羅的性能ベンチマーク。メモリフットプリント・キャッシュホット性が主要因、per-cpu hash のゼロ初期化増幅、「volume discount」特性) - [[@2026__eunomia.dev__eBPF × AI-LLMs - The Convergence of System Observability and AI]](共生ループ・eBPF for AI / AI for eBPF・Part 1–3) - [[Scaling Telemetry Workloads in Cloud Applications]]([[go-conntracer-bpf]] = カーネル内フローバンドリング) - [[@2023__ICSE__LogReducer - Identify and Reduce Log Hotspots in Kernel on the Fly]](`sys_write()` インターセプトによるカーネル空間ログフィルタリング、WeChat で 39.08% 削減) - [[@2021__yuuk.io__Linux eBPF Tracing Technology]](eBPF 基礎技術: アーキテクチャ・イベントソース・BCC/bpftrace/libbpf+CO-RE 開発ワークフロー) - [[@1993__USENIX__The BSD Packet Filter A New Architecture for User-level Packet Capture]](BPF の原典。register VM + CFG 評価 + verifier という eBPF の先祖的設計。CSPF 最大 20 倍高速化) - [[@2020__SAC__Black-box inter-application traffic monitoring for adaptive container placement]](KernelAgg: kprobe/kretprobe + `<pid,sock>` マップ + バイトカウンタ; 9% オーバーヘッド; Cassandra+Spark 配置最適化) - [[@2026__eunomia.dev__CUDA Events - eBPF-based CUDA API Tracing]](CUDA API トレースの実装例、uprobe/uretprobe + ring buffer、約 2 µs オーバーヘッド) - [[@2026__TOCS__cache_ext - Customizing and Tracing the Page Cache with eBPF]](struct_ops/kfunc で Linux ページキャッシュの退避方針を eBPF 化。sched_ext を設計モデルに、方針実行をカーネル内に留めることでユーザ空間オフロード比 最大 20.6% のスループット低下を回避) - [[@2021__TNSM__Assessing Container Network Interface Plugins - Functionality, Performance, and Scalability]](Cilium の eBPF datapath(XDP・TC フック)を CPP で定量化。intra-host 約 189 CPP・iptables チェーン 0、inter-host 約 236 CPP。他 CNI の Netfilter オーバーヘッド(245〜749 CPP)との比較) - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 3 オペレーティングシステム]](§3.2.3 システムコール、§3.2.4 割り込み、§3.4.4 拡張BPFのコンポーネントとイベントソース) - [[@2026__OReilly__Observability Engineering 2E - Chapter 7 Instrumenting Your Code with OpenTelemetry]]("Extended Berkeley Packet Filters" eBPF計装を既存計装の補完・アクセラレータとして位置づけ、OBIの言語/プロトコル対応、権限・競合の運用上の懸念、"Serverless" statelessLambda tracing戦略) - [[@2026__NAIC__RDMATracer - A scalable eBPF-based framework for tracing RDMA syscalls]](§提案手法 4ヒューリスティックによる13-hook選択的計装、per-CPUカウンタ+リングバッファの二重BPFマップ、fentry/fexit採用の定量比較、§実験結果 ALPS基準73%カバレッジ・オーバーヘッド1桁未満) - [[@2018__CoNEXT__The eXpress Data Path - Fast Programmable Packet Processing in the Operating System Kernel]](eBPF verifier の2パスDAG検証アルゴリズム、レジスタ範囲追跡による境界外メモリアクセス防止、BPFからeBPFへのレジスタ数・幅拡張の具体的な数値) - [[@2026__arXiv__NCCLbpf - Verified, Composable Policy Execution for GPU Collective Communication]](ユーザ空間 eBPF(bpftime)を NCCL プラグイン ABI に組み込み、検証済みホットリロード可能なポリシー実行を実証)