系统运维利器,百万服务器运维实战总结!一文了解最新版SysAK 原创

龙蜥社区OpenAnolis
发布于 2022-11-16 17:01
浏览
0收藏

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

系统运维利器,百万服务器运维实战总结!一文了解最新版SysAK-鸿蒙开发者社区


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

一、SysAK 框架介绍

 

系统运维利器,百万服务器运维实战总结!一文了解最新版SysAK-鸿蒙开发者社区

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

  • 系统监控:针对各种系统资源(CPU、内存、网络、文件 IO、内核管理结构等)提供更精细化的资源监控,帮助业务运维实现细粒度的运维调度,高效运用资源。
  • 系统诊断:诊断的典型问题如负载异常、网络抖动、内存泄漏、IO毛刺、性能瓶颈、应用异常等,针对性提供工具,同时尽量减少工具的专业性,让用户更易使用和解读。
  • 系统介入:主要针对故障注入、系统恢复和故障隔离3种情况提供系统介入的能力。

系统运维利器,百万服务器运维实战总结!一文了解最新版SysAK-鸿蒙开发者社区

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


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


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


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


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

  • 系统负载分析:系统负载时系统运维过程中的典型问题,可以针对于此进行根因分析,避免影响进程堆栈。
  • 系统健康一键诊断:比如对系统各个资源维度进行分析,查看配置是否合理等。
  • IO 问题自动诊断:比如分析 IO 打满时,是应用瓶颈还是业务底层存储瓶颈导致。


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

系统运维利器,百万服务器运维实战总结!一文了解最新版SysAK-鸿蒙开发者社区

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

二、SysAK 监控场景应用 

系统运维利器,百万服务器运维实战总结!一文了解最新版SysAK-鸿蒙开发者社区

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

系统运维利器,百万服务器运维实战总结!一文了解最新版SysAK-鸿蒙开发者社区

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

  • 计算资源方面:包括容器负载、运行和阻塞任务数。
  • 内存资源方面:内存使用过程中会频繁遇到瓶颈,主要针对延迟做了增强监控。内存回收延迟包括全局内存回收和容器内存回收,两者都都会影响容器的服务运行状态。因此我们对回收延迟分布以及规整次数做了统计,根据统计结果判断容器业务运行过程是否遇到瓶颈。
  • IO资源方面:包括容器读写等待时间、排队个数以及平均字节数。

系统运维利器,百万服务器运维实战总结!一文了解最新版SysAK-鸿蒙开发者社区

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

  • 进行/线程调度延迟:比如运行队列挤压、排队时间过长以及高优先级应用抢占或本身调度策略设置不合理。
  • 中断和软中断响应不及时:业务运行过程会依赖于中断和软中断执行过程,包括网络收发包、IO 读写等。因此可以分析关中断时长来判断中断的响应时间。
  • 内核态执行过长:包括系统本身存在的瓶颈以及内核里其他资源竞争等情况。


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

系统运维利器,百万服务器运维实战总结!一文了解最新版SysAK-鸿蒙开发者社区

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


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


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

系统运维利器,百万服务器运维实战总结!一文了解最新版SysAK-鸿蒙开发者社区


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

三、未来演进路线

 

系统运维利器,百万服务器运维实战总结!一文了解最新版SysAK-鸿蒙开发者社区

未来,除了完善工具本身的使用场景,我们将持续增强 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​​ 查看。

—— 完 ——

加入龙蜥社群

加入微信群:添加社区助理-龙蜥社区小龙(微信:openanolis_assis),备注【龙蜥】与你同在;加入钉钉群(钉钉搜索群号13600003427或13600003427入群交流)。欢迎开发者/用户加入龙蜥社区(OpenAnolis)交流,共同推进龙蜥社区的发展,一起打造一个活跃的、健康的开源操作系统生态!

©著作权归作者所有,如需转载,请注明出处,否则将追究法律责任
1
收藏
回复
举报
回复
    相关推荐