AI-Driven Adaptive eBPF Observability Framework (AI驱动的自适应eBPF观测框架)

1. 项目简介

本项目是一个基于 C/C++ 和 eBPF 技术实现的 AI 驱动的自适应观测框架，专为资源受限的嵌入式或边缘设备设计。它旨在解决传统监控方法中“持续高精度观测”与“低系统开销”之间的核心矛盾。

框架的核心理念是 **“按需深入、无事不扰” (Drill Down on Demand, Stay Quiet Otherwise)**。在系统正常运行时，它以极低的开销进行基线监控；一旦后端的 AI 引擎检测到异常，它会智能地决策并动态加载相应的高精度 eBPF 诊断探针，对问题进行深度根因分析。诊断结束后，系统会自动恢复到低开销的基线模式。

此项目的一大特色是提供了两种可插拔的 AI 决策后端：

1. MASA (移动平均标准差异常检测) 后端: 一个轻量级、无需训练的统计学模型，适用于快速部署和常规异常检测。
2. LSTM Autoencoder 后端: 一个基于深度学习的先进模型，能够学习系统正常运行的复杂时序模式，提供更精准、更深入的异常检测能力。

此项目完整地实现了从数据采集、异常检测、智能决策、动态执行到结果反馈的完整自适应闭环，为自动化系统诊断与优化提供了一个功能完备且高度可扩展的双引擎原型。

2. 核心特性

• 分层观测与丰富的探针库:

  • 基线监控层: 默认运行 baseline 探针，持续聚合系统级和进程级的核心指标（I/O计数、CPU时间、内存使用率）。
  • 深度诊断层: 包含一个可扩展的eBPF探针库，每个探针都为解决特定问题而设计，实现了从“症状”到“病因”的逐层深入分析。

• 双 AI 决策引擎:

  • MASA 统计后端: 无需训练，内置“预热期”和“最小波动容忍度”机制，表现鲁棒。
  • LSTM Autoencoder 深度学习后端: 能够捕捉统计方法难以发现的复杂模式偏差。

• 自动化根因分析:

  • 定向诊断: 能够将“元凶”进程PID注入诊断探针（如runqlat），实现“手术刀式”的精准追踪。
  • 文件 I/O 瓶颈分析: 通过 pagefault 探针，自动将高 I/O 延迟问题定位到具体的进程和文件名。
  • 锁竞争分析: 通过 locksensor 探针，自动将高上下文切换或高调度延迟问题定位到具体的“热锁”地址、持有者和等待者。

• 高稳定性与健壮性:

  • 类型安全的数据通路: 为不同诊断事件定义专属的、紧凑打包的数据结构，杜绝数据错乱。
  • 智能采样与异步上报: 在高频事件源中内置采样逻辑，并采用生产者-消费者模型异步批量上报，确保系统稳定。

• 离线自治能力:

  • 当与后端失联时，Agent能根据本地rules.json规则库独立完成“检测->诊断->恢复”的应急闭环，并将诊断数据安全缓存，待网络恢复后自动上报。

3. 系统架构与探针库详解

本框架采用“云-端”协同架构，主要由设备端 Agent、eBPF 探针库和可替换的 AI 后端组成。

3.1 eBPF 探针库 (The Sensors)

所有探针均采用 BPF CO-RE 设计，以增强可移植性。

探针名称	类型	核心功能与捕获数据
baseline	基线监控	持续运行，采集系统健康状况的“心跳”。 - io_time_ms: 系统总I/O时间。 - cpu_total/idle_jiffies: 系统总CPU时间与空闲时间。 - top_cpu_procs: CPU消耗最高的Top 5进程及其消耗时间。
runqlat	深度诊断	CPU调度延迟分析器。用于回答“为什么我的应用明明没跑满CPU，但还是很慢？”。 - latency_us: 进程从就绪状态到真正运行在CPU上的等待时间。 - 支持定向诊断，可只监控特定PID。
biolatency	深度诊断	块设备I/O延迟分析器。用于回答“磁盘I/O为什么慢？”。 - latency_us: 一个I/O请求从提交到完成的精确耗时。 - dev: 发生I/O的设备号。
pagefault	根因分析	文件I/O瓶颈定位器。用于回答“是哪个进程在读写哪个文件导致了高I/O？”。 - address: 发生缺页的虚拟内存地址。 - filename: Agent在用户态将地址解析出的文件名。
locksensor	根因分析	锁竞争分析器。用于回答“为什么应用卡死或上下文切换频繁？”。 - lock_type: mutex (内核锁) 或 futex (用户态锁)。 - lock_addr: 发生竞争的锁地址。 - waiter/owner: 等待者和持有者的进程信息。 - duration_ms: 本次锁竞争造成的等待时长。
oomkill	深度诊断	内存溢出杀手捕获器。用于事后分析“哪个进程因为内存耗尽被杀死了？”。 - total_vm_pages, anon_rss_pages 等: 被杀死进程在最后一刻的详细内存占用情况。
tcpconnlat	深度诊断	TCP连接延迟分析器 (实验性)。用于分析TCP连接建立的耗时。

3.2 根因分析模块详解

3.2.1 Pagefault: 文件 I/O 瓶颈定位

当AI检测到高I/O等待时，会自动部署pagefault探针。该模块通过“内核捕获+用户态解析”的两阶段工作流，将模糊的“I/O高”症状，精确到“cat进程正在大量读取large_test_file文件”的具体根因，为应用启动慢、数据加载慢等问题提供直接证据。

3.2.2 Locksensor: 锁竞争分析

当AI检测到高CPU负载但又无明确的用户态元凶时（通常表现为高上下文切换或高swapper活跃度），会推断可能存在锁竞争并部署locksensor探针。该模块的后端分析器会对捕获到的海量锁竞争事件进行实时聚合，每秒生成一份“热锁”报告，量化由锁竞争造成的性能损耗，并定位到具体的锁地址、持有者和等待者，揭示系统内部最隐蔽的性能瓶颈。

4. 环境准备

• 操作系统: Ubuntu 22.04 LTS
• 编译器: clang, llvm (>= 14)
• 核心依赖: libbpf-dev, libelf-dev, linux-tools-generic, bpftool, stress, stress-ng
• Python 环境: python3, pip, venv

# 安装系统依赖
sudo apt update
sudo apt install -y build-essential clang llvm libelf-dev libbpf-dev linux-tools-common linux-tools-generic bpftool stress stress-ng

# 创建并激活 Python 虚拟环境

# 安装python环境

sudo apt install python3.12-venv

python3 -m venv backend/venv
source backend/venv/bin/activate

# 创建并激活 Python 虚拟环境
#  deactivate
rm -rf backend/venv
python3 -m venv backend/venv
source backend/venv/bin/activate

# 安装 Python 依赖 (包括 PyTorch 和 Scikit-learn)
pip install flask requests numpy pandas torch scikit-learn joblib

# 下载子模块
rm -rf agent/third_party/cpp-httplib

git clone https://github.com/yhirose/cpp-httplib.git agent/third_party/cpp-httplib

5. 编译项目

1. 生成 vmlinux.h:

   sudo bpftool btf dump file /sys/kernel/btf/vmlinux format c > bpf_probes/vmlinux.h

2. 编译:

   make

6. 运行实验

6.1 启动后端与Agent

• 启动AI后端: 在python虚拟环境中，根据需求选择其一：
  • MASA (统计) 后端: make run-backend-masa
  • LSTM (深度学习) 后端: make run-backend-lstm (需先按README.lstm.md指引训练模型)
• 启动Agent: make run-agent
• 等待预热: 等待AI后端打印Warm-up complete.日志 (约1分钟)。

6.2 执行诊断场景

(在AI预热完成后，于新终端中执行)

场景一：CPU瓶颈与定向诊断

• 制造负载: stress --cpu 2 --timeout 60s
• 预期行为: AI检测到高CPU，识别stress为元凶，并下发对stress进程的定向诊断指令，加载runqlat探针。后端只会收到来自stress进程的调度延迟数据。

场景二：文件I/O瓶颈根因分析

1. 准备大文件: dd if=/dev/zero of=./large_test_file bs=1M count=1024
2. 清空缓存: sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
3. 制造负载: cat ./large_test_file > /dev/null

• 预期行为: AI检测到高I/O，决策加载pagefault探针。后端将收到大量诊断事件，其中filename字段清晰地指向./large_test_file，成功定位根因。

场景三：锁竞争根因分析

1. 准备测试程序: gcc scripts/contention.c -o contention -lpthread
2. 制造负载: ./contention

• 预期行为: AI检测到高swapper活跃度，推断存在锁竞争，决策加载locksensor探针。后端将每秒打印一份“热锁”报告，清晰地展示竞争最激烈的锁地址、等待者、持有者和总等待时间。

场景四：内存压力预警

• 制造负载: stress-ng --vm 1 --vm-bytes 10G --timeout 30s
• 预期行为: AI检测到低可用内存，加载oomkill探针。如果系统发生OOM Kill，探针将捕获并上报被杀死的进程及其内存信息。

场景五：离线自治能力

1. 模拟断网: Ctrl+C停止AI后端。
2. 观察Agent: Agent进入OFFLINE mode。
3. 制造负载: 运行./contention或stress。

• 预期行为: Agent的本地决策引擎会根据rules.json独立加载locksensor或runqlat探针，并将诊断数据安全缓存。
• 恢复网络: 重启AI后端。Agent会自动重连并上报所有缓存数据。

7. 停止程序

• 在 后端终端 按 Ctrl+C。
• 在 Agent 终端 按 Ctrl+C。

8. 未来展望

• 混合决策引擎: 结合 MASA 的快速响应和 LSTM 的深度模式识别能力。
• 故障自愈闭环: 将诊断结果（如“热锁”地址）反馈给自动化运维系统，实现自动调优或告警。
• 模型在线更新: 实现 AI 模型的在线学习，让框架持续自适应环境变化。