系统运维利器，百万服务器运维实战总结！一文了解最新版 SysAK｜龙蜥技术

在刚刚结束的龙蜥峰会 eBPF & Linux 稳定性专场上，龙蜥系统运维 SIG Maintainer 张毅做了《SysAK 系统运维工具集》的主题演讲，以下为演讲实录。

大家好，在去年的云栖大会，我们在龙蜥社区开源了系统运维工具集 SysAK，并提供了多种诊断功能。作为系统运维 SIG（Special Interest Group） 主力项目之一。这一年来，SysAK 为适应更多场景，在技术架构和应用场景上也做出了更多升级。今天分享下最新版本的核心技术结构和使用场景，限于时间关系，会重点介绍监控模式的相关组件，利用龙蜥 OS、SysAK 的增强特色，去做疑难问题和系统健康度的监控。

一、SysAK 框架介绍

SysAK 全称为 System Analyse Kit，是龙蜥系统运维 SIG。我们通过对过往百万服务器运维经验进行抽象总结，提供了一个全方位的系统运维工具集，可以覆盖系统日常监控、线上问题诊断和系统故障修复等常见运维场景。主要包括三个方面：

• 系统监控：针对各种系统资源(CPU、内存、网络、文件 IO、内核管理结构等)提供更精细化的资源监控，帮助业务运维实现细粒度的运维调度，高效运用资源。

• 系统诊断：诊断的典型问题如负载异常、网络抖动、内存泄漏、IO 毛刺、性能瓶颈、应用异常等，针对性提供工具，同时尽量减少工具的专业性，让用户更易使用和解读。

• 系统介入：主要针对故障注入、系统恢复和故障隔离 3 种情况提供系统介入的能力。

SysAK 框架包括两大模式，分别为监控模式和诊断模式。

系统资源瓶颈指标包括 CPU 瓶颈、内存瓶颈、网络瓶颈、IO 瓶颈，通过对瓶颈的监控可以发现应用运行过程中对资源的依赖度，再通过依赖度有效配合其他数据，对应用做合理的调度和资源分配。

除了硬件四大资源之外，系统软件本身也也存在瓶颈，比如 Linux 内核系统实现各种文件、句柄、cache、共享资源的访问过程中都有可能会产生并发瓶颈， SysAK 针对此瓶颈也做了很多工作。

干扰是应用运行过程中是比较常见的因素，会引发抖动或运行中断等。针对目前云原生的趋势下，SysAK 实现了容器资源可视化。

诊断模式指及时发现问题，并根据问题根因做诊断，随用随起。根据用户运维场景，目前支持以下这三类：

• 系统负载分析：系统负载时系统运维过程中的典型问题，可以针对于此进行根因分析，避免影响进程堆栈。

• 系统健康一键诊断：比如对系统各个资源维度进行分析，查看配置是否合理等。

• IO 问题自动诊断：比如分析 IO 打满时，是应用瓶颈还是业务底层存储瓶颈导致。

除了用户场景，我们也针对高级技术人员提供了更深层次的数据诊断，比如系统调用数据耗时较长的函数、中断运行统计、调度模块、内存模块、延时抖动、内存泄露等，会根据每个子系统的特点做专项功能诊断。

SysAK 通过松散耦合、依赖管理、多架构多版本的构建支持等方式保障工具的开发者仅需一次开发、无需额外工作，即可在主流的架构和操作系统版本上集成。

二、SysAK 监控场景应用

SysAK 的监控服务 mservice 主要提供了资源监控、异常告警、根因分析三大能力。其中异常告警功能会设定特殊阈值，提供告警，并进行自动分析。

SysAK 能够利用增强指标监控容器资源的使用，主要依托于龙蜥 OS 内核的增强特性以及 SysAK 本身的扩展。

计算资源方面：包括容器负载、运行和阻塞任务数。

内存资源方面：内存使用过程中会频繁遇到瓶颈，主要针对延迟做了增强监控。内存回收延迟包括全局内存回收和容器内存回收，两者都都会影响容器的服务运行状态。因此我们对回收延迟分布以及规整次数做了统计，根据统计结果判断容器业务运行过程是否遇到瓶颈。

IO 资源方面：包括容器读写等待时间、排队个数以及平均字节数。

抖动是日常运维过程偶发的问题。而偶发过程中难以采集实际的根因数据。如果数据采集过多，会影响整体系统性能；而采集过少则不足以分析问题根因。引发业务抖动的原因可以总结为以下三类：

• 进行/线程调度延迟：比如运行队列挤压、排队时间过长以及高优先级应用抢占或本身调度策略设置不合理。

• 中断和软中断响应不及时：业务运行过程会依赖于中断和软中断执行过程，包括网络收发包、IO 读写等。因此可以分析关中断时长来判断中断的响应时间。

• 内核态执行过长：包括系统本身存在的瓶颈以及内核里其他资源竞争等情况。

上述三大类原因基本能够覆盖 70%-80% 的抖动根因，因此针对以上三类问题进行检测，大多可以解决抖动问题。

SysAk 对系统健康告警也做了增强。

比如应用没有发生抖动，但突然变慢，长时间的积累会导致系统进入不可用状态，比如夯机。夯机会造成较大影响，且大多不可恢复。但在此之前可以通过多种手段提前预警，比如可以通过算法查看夯机的影响指标，判断是否会发生夯机，提前做健康度预判等。主要判断指标包括调度的延迟、内核态锁竞争时延、内存回收时延等。

结合过往经验，我们将当前的异常参考阈值定为 50%。

SysAK 目前主要用于单机诊断和监控，而除了在机器上使用 SysAK mservice 命令直接查看数据外，也支持以 http 端口的形式对外提供数据服务，如上图。同时，也可根据数据做图形化展示。

三、未来演进路线

未来，除了完善工具本身的使用场景，我们将持续增强 SysAK 的其他能力。目前，SysAK 仅能在系统级做诊断，后续我们也将考虑从应用级别做诊断，为应用诊断提供更多数据。另外，SysAK 已经在龙蜥开源，我们希望更多开发者加入，让运维发展得更好。我们也希望 SysAK 工具持续发展，作为运维平台的技术数据采集发挥特性，因此会着重于平台插件化。目前，它已经作为 SysOM 和云监控的组件在使用，未来希望能够作为 Prometheus 的插件扩展以满足更多场景。

相关地址链接：

系统运维 SIG：https://openanolis.cn/sig/sysom

源码官网：https://gitee.com/anolis/sysak

关于龙蜥 eBPF & Linux 稳定性专场课件获取方式：

【PPT 课件获取】：关注微信公众号（OpenAnolis），回复“龙蜥课件”即可获取。有任何疑问请随时咨询龙蜥助手—小龙（微信：openanolis_assis)。

【视频回放】：视频回放已上传至龙蜥官网：https://openanolis.cn/video 查看。

—— 完 ——