EviTrace：基于 eBPF 多源证据融合与主动验证的复合故障多根因诊断系统

EviTrace 面向 Linux / openKylin 系统异常诊断场景，将故障复现、eBPF 内核证据采集、多源时序证据构建、Top-K 根因分析、主动验证、证据图和诊断报告串联为一条可运行、可验证、可回溯的系统诊断链路。

核心流程：

FaultBench → eBPF Collector → Schema V2 → Temporal Evidence Builder → Top-K RCA → Active Verification → Evidence Graph → Diagnosis Report → Studio

1. 项目简介

传统系统监控工具通常能够回答“哪个指标发生了异常”，但在多个异常同时出现时，很难进一步回答：

哪些异常是真正的根因？
是否同时存在多个根因？
根因排序是否具有足够证据？
RCA 输出能否通过新的系统证据再次验证？
最终结论能否形成完整、可回溯的证据链？

EviTrace 围绕这些问题构建了一套基于 eBPF 的证据驱动诊断框架。

系统支持 CPU 饱和、I/O 抖动、内存压力、锁竞争和系统调用热点等典型异常，并进一步面向 CPU+Syscall、I/O+Memory、CPU+Lock 等复合故障进行 Top-K 根因恢复和主动验证。

1.1 应用场景

EviTrace 主要面向以下场景：

Linux / openKylin 系统异常排查与内核级根因诊断；
CPU、I/O、内存、锁竞争、系统调用等性能异常的证据化分析；
多个异常同时出现时的复合故障多根因恢复；
eBPF 可观测性、系统性能分析和操作系统实验教学；
需要可追溯、可复核诊断证据链的工程验证场景。

2. 核心能力

EviTrace 当前具备以下能力：

eBPF 内核事件与系统运行证据采集；
CPU、I/O、Memory、Lock、Syscall 五类典型故障复现；
Schema V2 结构化证据标准化；
时序窗口内多源证据关联；
Top-K 根因候选排序；
Active Verification 主动验证；
Evidence Graph 证据图构建；
JSON / Markdown 结构化诊断报告；
Adaptive Observation Controller 按需开启 Deep Trace；
Studio 可视化与最终实验结果展示；
Formal Gate、Performance Gate 和 Demo 自动验证。

3. 三项核心创新

3.1 面向复合故障的 Top-K 多根因诊断

单一 Top-1 RCA 在复合故障中容易遗漏第二根因。

EviTrace 保留多个高可信根因候选，通过 Top-K RCA 同时恢复复合故障中的多个原因。

正式消融实验结果：

方法	Macro Recall	Dual-cause Success
Top-1 only	50%	0%
Top-2 RCA	100%	100%
Full EviTrace	100%	100%

结果表明，在当前三个正式复合故障场景中，Top-K 机制能够恢复 Top-1 模式遗漏的第二根因。

3.2 多源时序证据融合与主动验证闭环

EviTrace 不直接把 RCA 排名作为最终结论。

系统首先综合 eBPF、系统状态和运行时证据形成根因候选，再通过 Active Verification 对候选根因执行进一步证据验证，将“候选假设”转化为“已验证诊断结论”。

三个正式复合故障场景中的 6 个 Top-2 根因候选均获得 CONFIRMED 状态。

多源证据消融结果：

设置	Macro Recall	Dual-cause Success
Full Evidence	100%	100%
Leave-One-Source-Out	50%	0%

该结果说明，在当前复合故障实验中，多源证据对完整恢复多个根因具有重要作用。

3.3 Adaptive Observation 按需深度观测

持续开启深度 eBPF 探针可能带来额外资源开销。

EviTrace 构建状态机：

NORMAL → SUSPECT → DEEP_TRACE → VERIFY → COOLDOWN → NORMAL

仅在异常证据达到触发条件后进入 Deep Trace，并在验证结束后退出深度观测状态。

正式实验中：

指标	结果
Adaptive average CPU overhead vs Baseline	4.874%
Deep Trace phase fraction	36.506%
Deep Trace residency reduction	63.494%
Adaptive vs Always-on Peak RSS reduction	78.483%
Adaptive vs Always-on Mean RSS reduction	81.940%

Deep Trace phase fraction 表示控制器层面的深度观测阶段占比，不等价于整个系统的总开销比例。

4. 系统架构

总体诊断链路：

FaultBench Workload ↓ eBPF Collector ↓ Schema V2 ↓ Temporal Evidence Builder ↓ Top-K RCA ↓ Active Verifier ↓ Evidence Graph ↓ JSON / Markdown Report ↓ Studio Visualization

核心源码位于：

src/

5. 支持的异常场景

5.1 单故障

项目正式覆盖以下五类异常：

场景	主要异常
cpu_saturation	CPU 饱和与调度压力
io_jitter	Block I/O 延迟和队列拥塞
memory_pressure	内存压力与回收行为
lock_contention	锁竞争与 futex 热点
syscall_hotspot	高频或高耗时系统调用

五场景正式质量门均已通过。

5.2 复合故障

最终正式复合故障包括：

场景	Top-1	Top-2
CPU+Syscall	CPU Resource Saturation	Syscall Hotspot
I/O+Memory	Memory Pressure	I/O Queue Congestion
CPU+Lock	Lock Contention	CPU Resource Saturation

三个正式场景均成功生成 Top-2 根因并完成主动验证。

6. 复合故障正式结果

6.1 RCA 得分

场景	Top-1 Score	Top-2 Score
CPU+Syscall	0.803	0.658
I/O+Memory	0.919	0.724
CPU+Lock	0.940	0.751

6.2 Active Verification

六个候选根因均获得 CONFIRMED：

场景	Rank	Verification Support
CPU+Syscall	1	0.960
CPU+Syscall	2	0.823
I/O+Memory	1	1.000
I/O+Memory	2	0.997
CPU+Lock	1	0.999
CPU+Lock	2	0.969

Active Verification 用于形成新的验证证据和诊断闭环，不将其表述为 RCA 准确率提升。

7. 鲁棒性实验

每种复合故障重复运行 5 次，共 15 次正式鲁棒性实验。

场景	Dual Confirmed
CPU+Syscall	4 / 5
I/O+Memory	5 / 5
CPU+Lock	5 / 5
Overall	14 / 15

总体 Dual-confirm success rate 为：

93.33%

其中一次 CPU+Syscall 运行中的第二候选处于阈值附近，为 PROBABLE，而不是候选缺失。

8. 最终诊断延迟

正式优化后的复合故障端到端延迟：

场景	E2E after fault window
CPU+Syscall	0.802 s
I/O+Memory	0.664 s
CPU+Lock	1.343 s

最终三个场景均控制在约 1.35 s 内。

9. Pipeline Tail-Latency Optimization

最终优化主要针对 Pipeline tail 和 event materialization，不将其描述为 RCA 算法本身的单独加速。

场景	Before	After	E2E Reduction
CPU+Syscall	5.554 s	0.802 s	85.564%
I/O+Memory	1.528 s	0.664 s	56.519%
CPU+Lock	7.054 s	1.343 s	80.963%

10. 性能影响

10.1 RSS

Process-tree RSS 正式实验：

Mode	Peak RSS	Mean RSS
Baseline	11.06 MiB	10.87 MiB
Always-on	156.14 MiB	149.55 MiB
Adaptive	33.60 MiB	27.01 MiB

Adaptive 相比 Always-on：

Peak RSS 降低 78.483%；
Mean RSS 降低 81.940%。

10.2 FIO

FIO 正式实验比较的是 Always-on Observation 与 Baseline，而不是 Adaptive FIO。

Always-on 相比 Baseline：

指标	变化
Read mean latency	+3.651%
Read P99 latency	+22.132%
Write mean latency	+3.562%
Write P99 latency	+21.745%
Total IOPS	-3.494%
Total Bandwidth	-3.494%

11. Ground Truth 隔离

Ground Truth 只用于离线评价，不参与：

RCA 排名；
Active Verification；
Diagnosis Reporter；
Evidence Graph 在线生成。

正式复合故障结果记录：

ground_truth_used = false

ground-truth expected profiles 位于：

src/evaluation/ground_truth/

相关文件仅由离线 evaluation 使用。

12. 项目目录

项目最终提交结构：

EviTrace/ ├── README.md ├── src/ │ ├── agent/ │ ├── backend/ │ ├── collector/ │ ├── config/ │ ├── controller/ │ ├── diagnosis/ │ ├── ebpf/ │ ├── evaluation/ │ ├── experiments/ │ ├── frontend/ │ ├── graph/ │ ├── rca/ │ ├── scripts/ │ ├── verifier/ │ └── requirements.txt ├── tests/ │ ├── final-data/ │ ├── figures/ │ └── verification/ ├── demo/ │ ├── README.md │ ├── run_demo.sh │ ├── verify_demo.sh │ └── sample_output/ ├── docs/ │ ├── 项目说明书.pdf │ ├── 项目创新说明.pdf │ ├── 成员分工及主要贡献说明.pdf │ └── 人工智能及第三方工具使用说明.pdf ├── presentation/ │ ├── 决赛现场演示PPT.pptx │ └── 决赛演示视频.mp4 └── 作品原创承诺书.pdf

13. 系统环境与依赖要求

项目正式验证环境：

操作系统：openKylin 2.0 SP2；
内核版本：Linux 6.6.x；
处理器架构：x86_64；
Python：3.12.x；
bpftrace：0.20.x；
fio：3.36；
Node.js：22.x；
npm：10.x；
其他工具：Bash、stress-ng、Git、sha256sum。

说明：

核心 Python 诊断链路通过 src/requirements.txt 安装依赖；
Studio 前端需要 Node.js / npm；
实时 eBPF / bpftrace 观测及部分故障注入需要 root 权限；
冻结 Demo 可在不重新注入故障的情况下完成结果验证。

14. 构建、安装与环境初始化

EviTrace 核心诊断链路以 Python、Bash 和 eBPF/bpftrace 脚本为主，无需额外的本地编译过程。完成运行依赖安装后即可执行核心诊断与测试脚本；Studio 前端由 Node.js / npm 工具链构建和运行。

在项目根目录执行：

python3 -m venv .venv source .venv/bin/activate pip install -r src/requirements.txt

可通过以下命令检查关键运行环境：

python3 –version bpftrace –version fio –version node –version npm –version stress-ng –version

EviTrace 核心 Python 模块无需单独编译，完成依赖安装后即可通过 src/scripts/ 中的正式入口脚本运行。Studio 的启动入口见第 19 节。

15. 一键 Demo

最快的项目验证方式：

bash demo/run_demo.sh

该命令不需要重新注入故障，会展示并验证随项目提交的冻结正式样例。

正常情况下最终显示：

DEMO VERIFICATION: PASS

实时复现：

sudo bash demo/run_demo.sh –live

16. 正式质量门

五场景正式质量门：

bash src/scripts/verify_five_scenario_formal_gate.sh

Adaptive Final Gate：

bash src/scripts/verify_adaptive_final_gate.sh

Performance Impact Gate：

bash src/scripts/verify_performance_impact_gate.sh

17. 单故障运行入口

主要脚本位于：

src/scripts/

包括：

run_cpu_saturation_pipeline_v2.sh
run_memory_pressure_pipeline_v2.sh
run_lock_contention_pipeline_v2.sh
run_evitrace_competition_pipeline_v2.sh
run_five_scenario_suite.sh

实时 eBPF 运行时根据环境需要使用 root 权限。

18. Adaptive Observation

Adaptive Controller：

src/controller/adaptive_controller.py

外部 I/O Controller：

src/controller/adaptive_external_io_controller.py

主要正式脚本：

src/scripts/run_adaptive_evitrace.sh src/scripts/run_adaptive_overhead_benchmark.sh src/scripts/run_adaptive_residency_experiment.sh

19. Studio

Studio 后端位于：

src/backend/

前端位于：

src/frontend/

启动：

bash src/scripts/start_evitrace_studio.sh

默认：

Backend: http://127.0.0.1:8010
Frontend: http://127.0.0.1:5173

停止：

bash src/scripts/stop_evitrace_studio.sh

20. 正式数据与图表

冻结后的最终数据：

tests/final-data/

其中包含：

final_summary.json
compound_results.csv
verification_results.csv
ablation_results.csv
evidence_ablation_results.csv
robustness_results.csv
latency_results.csv
latency_optimization_results.csv
adaptive_results.csv
performance_results.csv

数据文件配套 SHA256SUMS，可进行完整性校验：

cd tests/final-data sha256sum -c SHA256SUMS cd ../..

最终图表：

tests/figures/

包含 PNG、SVG 以及可重新生成图表的：

tests/figures/generate_final_figures.py

21. 测试与验证材料

测试材料统一位于：

tests/

需求覆盖说明：

tests/verification/requirement_coverage.md

最终冻结实验数据：

tests/final-data/

最终实验图：

tests/figures/

主要验证入口：

bash src/scripts/verify_five_scenario_formal_gate.sh bash src/scripts/verify_adaptive_final_gate.sh bash src/scripts/verify_performance_impact_gate.sh bash demo/verify_demo.sh

评审人员可先运行 bash demo/run_demo.sh 查看冻结正式样例，再使用上述质量门和校验命令复核关键功能与实验结果。

22. Demo 输出

冻结 Demo 包含：

demo/sample_output/events/ demo/sample_output/diagnosis/ demo/sample_output/evidence_graph/ demo/sample_output/reports/ demo/sample_output/run_summary.json

运行：

bash demo/verify_demo.sh

即可自动验证关键产物及 Ground Truth 隔离状态。

23. 已知限制与设计边界

需要特别说明：

EviTrace 是面向系统异常诊断与证据分析的工程原型，不替代完整生产级 APM 平台。
正式复合故障实验目前覆盖 CPU+Syscall、I/O+Memory、CPU+Lock 三类代表性组合。
Ground Truth 只参与离线评估。
Active Verification 的作用是验证候选和形成证据闭环，不表述为直接提高 RCA recall。
Adaptive Deep Trace phase fraction 不等同于整个系统总资源开销下降比例。
FIO 正式结果为 Always-on Observation vs Baseline，不表述为 Adaptive FIO 性能结果。
正式验证主要在 openKylin 2.0 SP2 / Linux 6.6.x / x86_64 环境完成，不能直接等同为所有 Linux 发行版、内核版本和硬件平台下均取得相同结果。
阈值附近样本可能出现 PROBABLE 状态；当前正式鲁棒性实验中曾出现 1 次 CPU+Syscall 第二候选位于验证阈值附近的情况。

24. 最终结果摘要

EviTrace 已形成从故障复现、内核证据采集、Top-K 根因分析、主动验证到证据图和报告输出的完整系统异常诊断闭环。

最终正式结果包括：

五类单故障场景质量门通过；
三类复合故障均恢复两个目标根因；
Top-K 消融 Macro Recall 从 50% 提升至 100%；
Top-K 消融 Dual-cause Success 从 0% 提升至 100%；
15 次复合故障鲁棒性实验中 14 次双根因确认；
总体 Dual-confirm success rate 为 93.33%；
三类复合故障最终 E2E 均不超过约 1.35 s；
Deep Trace phase fraction 为 36.506%；
Deep Trace residency reduction 为 63.494%；
Adaptive 相比 Always-on Peak RSS 降低 78.483%；
Adaptive 相比 Always-on Mean RSS 降低 81.940%。

EviTrace 的目标不是只告诉用户“系统发生了异常”，而是提供：

发现异常 → 保留多个根因候选 → 主动验证候选 → 构建证据链 → 输出可复核诊断结论

从而形成完整、可解释、可验证的系统根因分析闭环。