eBPF 系统异常观测与根因定位工具

基于 BCC/eBPF 的系统级异常检测工具，覆盖 CPU、I/O、Memory、锁竞争 4 类异常场景，输出结构化诊断结果。

环境要求

OS: openKylin / Ubuntu / Debian (x86_64)
Kernel: Linux 6.6+
权限: root (sudo)
依赖: BCC 工具链, Python 3, stress-ng, fio

一键安装

cd ebpf-anomaly-detector
sudo ./install.sh

安装脚本会自动完成：

安装系统依赖（linux-headers, bpfcc-tools, stress-ng, fio）
安装 Python 依赖（bcc, pyyaml）
验证 BCC 可用性

使用方式

# 基本用法
sudo python3 detector.py --scenario cpu --duration 180 --output result.json

# 参数说明
sudo python3 detector.py \
  --scenario <cpu|io|memory|lock|all> \
  --duration <采集秒数，默认 180> \
  --output <输出文件路径，默认 stdout> \
  --interval <采样间隔秒数，默认 1> \
  --format <json|yaml，默认 json> \
  --thresholds <自定义阈值配置文件路径>

示例

1. 检测 CPU 异常（3 分钟）

sudo python3 detector.py --scenario cpu --duration 180 --output cpu_report.json

2. 检测所有场景

sudo python3 detector.py --scenario all --duration 120 --output full_report.json

3. 输出 YAML 格式

sudo python3 detector.py --scenario memory --duration 60 --format yaml

复现异常场景

使用 scenarios/trigger.sh 一键生成异常负载：

# CPU 异常（4 核矩阵乘法压力）
sudo ./scenarios/trigger.sh cpu 180

# I/O 抖动（随机读写压力）
sudo ./scenarios/trigger.sh io 120

# 内存抖动（4 个 VM worker 占用 80% 内存）
sudo ./scenarios/trigger.sh memory 180

# 锁竞争（8 线程 mutex 压力）
sudo ./scenarios/trigger.sh lock 180

在另一个终端同时运行检测器即可捕获异常：

# 终端1: 触发异常
sudo ./scenarios/trigger.sh cpu 60

# 终端2: 检测异常
sudo python3 detector.py --scenario cpu --duration 60 --output cpu_report.json

输出格式

检测结果输出为结构化 JSON：

{
  "report": {
    "tool_name": "ebpf-anomaly-detector",
    "version": "1.0.0",
    "timestamp": "2026-07-22T15:30:00+08:00",
    "scenario": "cpu",
    "duration_sec": 180
  },
  "anomalies": [
    {
      "anomaly_type": "CPU异常占用",
      "severity": "warning",
      "time_window": { "start": "...", "end": "...", "duration_sec": 180 },
      "related_objects": { "pid": 12845, "process_name": "stress-ng-cpu" },
      "key_metrics": { "cpu_usage_pct": 92.3, "context_switches_per_sec": 32000 },
      "suspected_root_cause": "CPU饱和伴随调度压力",
      "evidence_chain": ["CPU使用率持续高于90%", "run_queue超过阈值", "..."],
      "suggestion": "检查进程CPU计算逻辑，考虑使用cgroup限制CPU配额"
    }
  ],
  "summary": {
    "total_anomalies": 1,
    "scenarios_checked": ["cpu"],
    "overall_status": "warning"
  }
}

项目结构

ebpf-anomaly-detector/
├── detector.py            # CLI 主入口
├── probes/
│   ├── cpu_probe.py       # CPU 异常占用检测
│   ├── io_probe.py        # I/O 延迟抖动检测
│   ├── memory_probe.py    # 内存抖动 / OOM 风险检测
│   └── lock_probe.py      # 锁竞争检测
├── lib/
│   ├── diagnosis.py       # 阈值规则引擎
│   ├── output.py          # JSON / YAML 输出
│   └── runner.py          # 探针运行调度器
├── scenarios/
│   └── trigger.sh         # 复现脚本
├── tests/
│   └── test_diagnosis.py  # 诊断规则单元测试
├── install.sh             # 一键安装
├── requirements.txt       # Python 依赖
└── README.md

诊断规则

场景	异常条件	严重级别
CPU	CPU > 90% + run_queue > cores×2	warning
CPU	热点函数采样 > 80%	warning
I/O	P99 > 100ms	critical
I/O	P99 > 50ms + queue_depth > 32	warning
Memory	OOM Kill 事件	critical
Memory	可用内存 < 10% + major_fault > 1000/s	warning
Memory	major_fault 激增 > 5x 基线	warning
Lock	avg_wait > 30ms + contention_pct > 50%	warning
Lock	avg_wait > 10ms	info

运行测试

cd ebpf-anomaly-detector
python3 tests/test_diagnosis.py

单元测试覆盖所有 4 个场景的诊断规则，无需 eBPF 环境即可运行。

赛题题目：基于eBPF的系统异常观测与根因定位工具（社区赛题）

赛题说明：

随着云计算、边缘计算和智能终端的快速发展，操作系统在复杂业务负载下常出现 CPU 异常占用、I/O 延迟抖动、内存回收抖动、锁竞争严重、上下文切换频繁等问题。这类问题通常具有突发性、短时性和定位链路长等特点，传统依赖日志或静态监控的方式难以及时、准确定位根因。eBPF 作为近年来操作系统可观测性的重要技术方向，能够以低侵入、低开销的方式动态跟踪内核与用户态行为，为系统性能分析、故障诊断和在线问题定位提供新的技术手段。本赛题要求参赛队伍设计并实现一套基于 eBPF 的轻量级系统异常观测与根因定位工具，支持对典型系统异常进行实时观测、指标采集、事件关联分析和诊断结果输出，并能够在openKylin等开源操作系统上运行，体现良好的泛化能力、工程能力与可评测性。

赛题要求：

参赛作品应基于开源技术栈进行设计与开发，核心方案可复现、可验证，并围绕系统异常观测、诊断分析、工程实现和多平台适配完成以下任务：

最终交付的代码需在openKylin操作系统版本上能够正常编译、运行和测试，鼓励支持 X86、ARM、RISC-V等多种架构，鼓励支持更多Linux发行版。
作品需至少覆盖以下5类典型异常场景中的4类及以上，并鼓励实现全部5类场景的观测与分析：CPU 异常占用或调度延迟、I/O 延迟抖动或阻塞等待、内存抖动或 OOM 风险、锁竞争导致的性能退化、高频或高耗时系统调用热点。

1.CPU 异常场景样例：场景说明可设定为单进程或多线程持续高 CPU 占用，并伴随调度延迟和上下文切换升高。参考根因可定义为 CPU 密集型计算、线程竞争或异常 busy loop；关键证据点可包括 CPU 使用率、run queue 长度、热点函数、上下文切换次数和调度等待时间；预期指标变化可包括 CPU 使用率持续高于 90%、负载升高、热点线程长期占用核心；参考输出样例可包括“异常类型：CPU 异常占用；关联对象：进程/线程 ID；关键指标：CPU 92%、上下文切换 3.2w 次/分钟；疑似根因：用户态计算热点导致 CPU 饱和”。 2.I/O 抖动场景样例：场景说明可设定为随机读写压力、多作业并发和队列拥堵。参考根因可定义为磁盘队列过深、热点文件访问集中或缓存失效；关键证据点可包括 IOPS、平均时延、P99 时延、await、队列深度和热点文件/设备信息；预期指标变化可包括 P99 时延显著升高、阻塞等待时间增加、吞吐波动明显；参考输出样例可包括“异常类型：I/O 延迟抖动；关联对象：块设备/文件路径；关键指标：P99 时延 85ms；疑似根因：随机写压力导致设备队列拥堵”。 3.内存抖动场景样例：场景说明可设定为高内存占用、频繁缺页、回收抖动或 OOM 风险。参考根因可定义为匿名页持续增长、缓存与业务内存竞争或异常内存申请；关键证据点可包括内存使用率、major/minor page fault、kswapd 活跃度、回收次数和 OOM 相关日志；预期指标变化可包括可用内存持续下降、缺页次数增加、回收线程活跃度提升；参考输出样例可包括“异常类型：内存抖动；关联对象：进程 ID；关键指标：可用内存下降至 8%、major fault 激增；疑似根因：业务进程持续申请大块内存导致回收压力上升”。 4.锁竞争场景样例：场景说明可设定为多线程争用 mutex、futex 或其他锁资源，导致吞吐下降和时延升高。参考根因可定义为临界区过大、锁粒度过粗或热点锁集中争用；关键证据点可包括锁等待时间、futex 热点、调度阻塞时间和线程堆栈聚集情况；预期指标变化可包括等待时间升高、吞吐下降、热点锁调用集中；参考输出样例可包括“异常类型：锁竞争；关联对象：锁实例/线程组；关键指标：平均锁等待 37ms；疑似根因：多线程争用同一临界区导致性能退化”。

作品需能够输出结构化诊断结果，至少包括异常类型、关联进程或线程、关键指标、异常时间窗口、疑似根因及建议性分析结论。
作品应具备较高的根因分析准确性，支持分析过程的可回溯，降低模型幻觉导致的错误率。
工具应具备较好的工程可用性，至少提供清晰的命令行或配置化使用方式、安装部署文档、测试或复现场景说明，以及 JSON、YAML 或 Markdown 等结构化结果输出能力。
作品应尽量控制运行时资源开销，避免对目标系统业务产生明显影响。
鼓励参赛队伍在异常自动归类、多维关联分析、容器场景观测、插件化扩展和自动生成诊断报告等方向开展扩展创新。
基础评测环境：软件环境为openKylin，Kernel 6.6及以上版本，可基于标准虚拟机镜像或Docker/Podman容器环境；硬件环境最低配置为4核CPU、8GB内存、50GB存储，具备root权限或CAP_BPF、CAP_PERFMON、CAP_SYS_ADMIN等必要操作权限。
评分细则（明确评审角度、标准和分值范围）：
功能完成度（40 分）：

1.场景覆盖数量（15 分）：支持 4 类标准异常场景可得基础分，支持全部 5 类场景并具备稳定观测能力可得满分； 2.结构化输出完整性（15 分）：输出结果应至少包含异常类型、关联对象、关键指标、异常时间窗口、疑似根因、证据链和建议性结论；字段完整、格式规范、便于机器解析的作品得分更高； 3.多平台适配情况（10分）：在 openKylin 上稳定运行可获得基础分，同时支持不同内核版本、x86_64/ARM64 架构或其他主流开源操作系统的，可获得更高分。

诊断准确性（30 分）：

1.异常识别正确率（10 分）：重点考察对给定异常类型的识别是否正确，误报率和漏报率越低得分越高； 2.根因定位正确率（12 分）：重点考察对关键进程、线程、系统调用、资源对象或锁热点的定位是否准确，是否能够贴近标准答案或参考根因； 3.证据链一致性（8 分）：重点考察诊断结论与采集指标、事件关联结果、调用栈或日志证据之间是否相互支撑、逻辑一致。

性能开销（15 分）：

1.CPU 开销（4 分）：工具加载前后 CPU 占用增量越低得分越高； 2.内存开销（3 分）：工具运行时额外内存占用越低得分越高； 3.时延影响（4 分）：重点考察平均时延及P99时延的相对变化，变化越小得分越高； 4.吞吐影响（4 分）：重点考察加载工具后系统吞吐下降幅度，下降越小得分越高。

工程质量与开源规范（15 分）：

1.代码规范（4 分）：代码结构清晰、模块划分合理、命名和注释规范； 2.文档完整性（4 分）：包含安装说明、使用说明、参数说明、设计说明和限制说明； 3.复现脚本（4 分）：提供一键部署、测试或复现场景脚本，并能够稳定运行； 4.测试说明（3 分）：提供测试步骤、输入输出说明和结果示例，便于评委复核。

赛题联系人：

葛老师 gepc1@lenovo.com

参考资料：

eBPF 官方文档、BCC、bpftrace、perf、ftrace 等开源工具资料。
openKylin内核调度、内存管理、块设备 I/O 等子系统相关文档，以及开发与调试资料。
Linux Performance Observability、Cloud Native Observability 等相关技术资料。
openKylin内核版本适配、容器运行时与系统诊断实践案例。
典型异常场景的参考脚本如下：

1)CPU场景：stress-ng –cpu 4 –cpu-method matrixprod –timeout 180s –metrics-brief 2)I/O场景：fio –name=randrw-test –filename=/tmp/fio-test.img –size=4G –rw=randrw –rwmixread=70 –bs=4k –iodepth=64 –numjobs=4 –runtime=180 –time_based –group_reporting 3)内存场景：stress-ng –vm 4 –vm-bytes 80% –vm-keep –timeout 180s –metrics-brief 4)锁竞争场景：stress-ng –mutex 8 –timeout 180s –metrics-brief