# 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 つ。([[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]]) ## 横断的知見 - **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]], [[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]]) - **生成系を検証器で囲むのが 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__arXiv__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__arXiv__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]], [[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]]) - **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 がサービストポロジの「ネットワーク層」計装として本番採用される**: [[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]]) ## BPF から eBPF への系譜 [[BPF]](BSD Packet Filter)は 1993 年に [[Steven McCanne]] と [[Van Jacobson]] が [[LBNL]] で設計したカーネル内パケットフィルタリングアーキテクチャで、eBPF の直接的な先祖である([[@1993__USENIX__The BSD Packet Filter A New Architecture for User-level Packet Capture]])。BPF が確立した「レジスタベース VM + verifier + ユーザ空間コンパイル/カーネル内実行の分離」という設計原則は eBPF にそのまま引き継がれ、フックポイントと命令セットの大幅な拡張により汎用カーネル拡張機構へと発展した。詳細は [[BPF]] と [[カーネル内VM]] を参照。 ## 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 計装の共通実装知識でもある。 ## 未解決の問い - [[AgentSight]] はコーディングエージェント(claude code 等)をカーネル層で観測する。この**エージェント可観測性**を [[agentic SRE]] の安全制御([[SRE AI Autonomy Levels]]・[[Actus]])に接続し、「エージェントの行動をカーネルで監視・遮断する」一次研究は本 wiki にまだ無い。eBPF+LSM による AI エージェントのアクチュエーション制御を ingest して横断を厚くする。 - 本ソースは 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 制御とアプリ層のエージェント制御が同じ設計原則(検証付きサンドボックス実行、フォールバック、ウォッチドッグ)を共有しているかを検証する余地がある。 ## 関連 - ソース: [[@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]] / [[@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__HCDS__eGPU - Extending eBPF Programmability and Observability to GPUs]] / [[@2026__arXiv__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]] - 概念: [[テレメトリ]] / [[agentic SRE]] / [[分散トレーシング]] / [[コンテナ配置最適化]] / [[GPUクラスタ運用]] / [[LLM学習モニタリング]] / [[ログ解析]] / [[暗黙のコンテキスト伝搬]] / [[Linuxカーネルインタフェース]] - エンティティ: [[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]] - 関連 MOC: [[AI Infra Telemetry - MOC]] ## 出典 - [[@2026__eunomia.dev__eBPF × AI-LLMs - The Convergence of System Observability and AI]](共生ループ・eBPF for AI / AI for eBPF・Part 1–3) - [[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]]([[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% のスループット低下を回避)