Update README.md
随着云计算、边缘计算和智能终端的快速发展，操作系统在复杂业务负载下常出现 CPU 异常占用、I/O 延迟抖动、内存回收抖动、锁竞争严重、上下文切换频繁等问题。这类问题通常具有突发性、短时性和定位链路长等特点，传统依赖日志或静态监控的方式难以及时、准确定位根因。eBPF 作为近年来操作系统可观测性的重要技术方向，能够以低侵入、低开销的方式动态跟踪内核与用户态行为，为系统性能分析、故障诊断和在线问题定位提供新的技术手段。本赛题要求参赛队伍设计并实现一套基于 eBPF 的轻量级系统异常观测与根因定位工具，支持对典型系统异常进行实时观测、指标采集、事件关联分析和诊断结果输出，并能够在openKylin等开源操作系统上运行，体现良好的泛化能力、工程能力与可评测性。
参赛作品应基于开源技术栈进行设计与开发，核心方案可复现、可验证，并围绕系统异常观测、诊断分析、工程实现和多平台适配完成以下任务：
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；疑似根因：多线程争用同一临界区导致性能退化”。
1.场景覆盖数量（15 分）：支持 4 类标准异常场景可得基础分，支持全部 5 类场景并具备稳定观测能力可得满分； 2.结构化输出完整性（15 分）：输出结果应至少包含异常类型、关联对象、关键指标、异常时间窗口、疑似根因、证据链和建议性结论；字段完整、格式规范、便于机器解析的作品得分更高； 3.多平台适配情况（10分）：在 openKylin 上稳定运行可获得基础分，同时支持不同内核版本、x86_64/ARM64 架构或其他主流开源操作系统的，可获得更高分。
1.异常识别正确率（10 分）：重点考察对给定异常类型的识别是否正确，误报率和漏报率越低得分越高； 2.根因定位正确率（12 分）：重点考察对关键进程、线程、系统调用、资源对象或锁热点的定位是否准确，是否能够贴近标准答案或参考根因； 3.证据链一致性（8 分）：重点考察诊断结论与采集指标、事件关联结果、调用栈或日志证据之间是否相互支撑、逻辑一致。
1.CPU 开销（4 分）：工具加载前后 CPU 占用增量越低得分越高； 2.内存开销（3 分）：工具运行时额外内存占用越低得分越高； 3.时延影响（4 分）：重点考察平均时延及P99时延的相对变化，变化越小得分越高； 4.吞吐影响（4 分）：重点考察加载工具后系统吞吐下降幅度，下降越小得分越高。
1.代码规范（4 分）：代码结构清晰、模块划分合理、命名和注释规范； 2.文档完整性（4 分）：包含安装说明、使用说明、参数说明、设计说明和限制说明； 3.复现脚本（4 分）：提供一键部署、测试或复现场景脚本，并能够稳定运行； 4.测试说明（3 分）：提供测试步骤、输入输出说明和结果示例，便于评委复核。
葛老师 gepc1@lenovo.com
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
版权所有：中国计算机学会技术支持：开源发展技术委员会 京ICP备13000930号-9 京公网安备 11010802047560号
赛题题目： 基于eBPF的系统异常观测与根因定位工具（社区赛题）
赛题说明：
随着云计算、边缘计算和智能终端的快速发展，操作系统在复杂业务负载下常出现 CPU 异常占用、I/O 延迟抖动、内存回收抖动、锁竞争严重、上下文切换频繁等问题。这类问题通常具有突发性、短时性和定位链路长等特点，传统依赖日志或静态监控的方式难以及时、准确定位根因。eBPF 作为近年来操作系统可观测性的重要技术方向，能够以低侵入、低开销的方式动态跟踪内核与用户态行为，为系统性能分析、故障诊断和在线问题定位提供新的技术手段。本赛题要求参赛队伍设计并实现一套基于 eBPF 的轻量级系统异常观测与根因定位工具，支持对典型系统异常进行实时观测、指标采集、事件关联分析和诊断结果输出，并能够在openKylin等开源操作系统上运行，体现良好的泛化能力、工程能力与可评测性。
赛题要求：
参赛作品应基于开源技术栈进行设计与开发，核心方案可复现、可验证，并围绕系统异常观测、诊断分析、工程实现和多平台适配完成以下任务：
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；疑似根因：多线程争用同一临界区导致性能退化”。
评分细则（明确评审角度、标准和分值范围）：
1.场景覆盖数量（15 分）：支持 4 类标准异常场景可得基础分，支持全部 5 类场景并具备稳定观测能力可得满分； 2.结构化输出完整性（15 分）：输出结果应至少包含异常类型、关联对象、关键指标、异常时间窗口、疑似根因、证据链和建议性结论；字段完整、格式规范、便于机器解析的作品得分更高； 3.多平台适配情况（10分）：在 openKylin 上稳定运行可获得基础分，同时支持不同内核版本、x86_64/ARM64 架构或其他主流开源操作系统的，可获得更高分。
1.异常识别正确率（10 分）：重点考察对给定异常类型的识别是否正确，误报率和漏报率越低得分越高； 2.根因定位正确率（12 分）：重点考察对关键进程、线程、系统调用、资源对象或锁热点的定位是否准确，是否能够贴近标准答案或参考根因； 3.证据链一致性（8 分）：重点考察诊断结论与采集指标、事件关联结果、调用栈或日志证据之间是否相互支撑、逻辑一致。
1.CPU 开销（4 分）：工具加载前后 CPU 占用增量越低得分越高； 2.内存开销（3 分）：工具运行时额外内存占用越低得分越高； 3.时延影响（4 分）：重点考察平均时延及P99时延的相对变化，变化越小得分越高； 4.吞吐影响（4 分）：重点考察加载工具后系统吞吐下降幅度，下降越小得分越高。
1.代码规范（4 分）：代码结构清晰、模块划分合理、命名和注释规范； 2.文档完整性（4 分）：包含安装说明、使用说明、参数说明、设计说明和限制说明； 3.复现脚本（4 分）：提供一键部署、测试或复现场景脚本，并能够稳定运行； 4.测试说明（3 分）：提供测试步骤、输入输出说明和结果示例，便于评委复核。
赛题联系人：
葛老师 gepc1@lenovo.com
参考资料：
典型异常场景的参考脚本如下：
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