SysOM 的可观测和智能监控实践

2024-03-20
陕西
本文字数：3046 字
阅读完需：约 10 分钟

编者按：龙蜥社区系统运维 SIG Contributor 刘馨蔚在 2023 龙蜥操作系统大会上分享了随着云原生的发展，给运维带来了极大挑战，并提到了现有运维产品的现状和不足。为了解决这些痛点，实现“零”运维，提出了两点解决方案。以下为本次分享全文：

01 当前运维的趋势和挑战

随着云原生不断的发展，给用户带来了非常多的便利，开发会变得更简单。同时大家不用再去感知机器、容器甚至系统底层的信息。相反，用户体验的提升也带来一些挑战和机遇。

应用的运维功能上移，系统运行的情况无法深入感知，导致系统运维无所适从。基于此，龙蜥社区系统运维 SIG 打造了一站式操作系统运维平台，融入了 SIG 成员的成功商用运维实践经验，能够帮助用户在统一平台上实现主机管理、系统监控、异常诊断、日志审计、安全管控等复杂操作系统管理 SysOM（ System Operation&Maintenance）。SysOM 从两个方向去解决类似的问题，一是 SysOM 的应用观测方案，从应用视角主动观测、通过垂直往下的剖析，分析问题根因，针对 MySQL、应用调用关系追踪、Java 场景的观测方案；第二是针对大规模集群的智能监控方案，其中从容器角度、节点角度去评估集群的健康状态，并结合 AI 指标关联分析、智能化深度诊断，分析问题根因。

上图是目前运维产品的现状和挑战。比如有些配置型的部署，可能有比较多的指标，看着这些指标只知其然，不知所以然。对于系统监控，有比较熟悉的 Grafana，也有比较多的指标数据、指标大盘。但有一个问题，大家在看到这些大盘之后，并不能清楚接下来需要做什么操作动作，也不知道这些指标带来的告警意义。同样的，大家可以在用户态通过 perf 等工具进行问题的定位，而这个就需要专业级别的系统运维人员，同时通过大量的工具组合的应用，这个也可以说是难知所以然。

上图中出现的内核问题案例，由进程 B 引发了这样的申请内存并访问，进而引发了一些内存访问延时或者是内存不足的警告。但是大家可能无法立即看到它是由进程 A 不断的频繁读写文件造成大量的 page Cache 而形成的。在日常操作中，不仅是以上案例所阐述的内存问题，可能在操作系统内部网络、IO、内存、文件系统调度都存在大量的类似问题。

02 探索及实现路径

基于运维产品的现状和挑战，带大家回顾一下 Llinux 的跟踪及观测技术。

从内核态到用户态中间，比如有内核的 KO、kprobe，中间一层有 eBPF 及 tracing 的一些功能，到用户态通过 perf 或者是 libbpf 都可以实现跟踪及观测。

SysOM 也希望从底部到顶部，不管是从内核模块或者是 trace，还是 BPF，到更接近客户的应用层的 profiling，再到应用的可观测，我们希望更贴近用户，即使知道可能是比较底层的问题。但是也希望从用户的角度去解决这些问题。

上图是可观测的成熟度模型。通过可靠性和用户的满意度，希望达到最高的业务的可观测性。如最普通的监控，可以监测相关的健康的状态，或者是通过报警的规则去自动触发报警。通过不断的进步，可以从基础的可观测性到因果，到主动的可观测性，最后更加贴近用户，达到业务的可观测性。

接下来分享下 SysOM 在智能监控上的一些措施和演进道路。主要关注四个大的指标，一是延时，比如说在通过系统调用的延时或者中断的延时。第二个就是流量，包括网络的流量，或者是一些系统的吞吐和负载。第三个就是可能遇到的系统错误，包括可能会遇到的宕机、Hungtask 等，可以在系统日志中找到一些错误。第四个就是饱和度，这个是在有限资源的使用情况下，比如说 CPU 或者内存，是否有使用超限的情况。通过以上监控报警指标，结合自动化分析诊断、根因分析，达到自动化修复，快速修复的过程。

值得一提的是，智能监控包含了集群健康度的评估。包括容器、节点到整个集群方面，都有一系列的评估标准，以此来去评估节点、容器、集群是否有健康度。由于在多个指标当中，并不一定能够快速的去定位到当前整个集群的状态，可能某一些指标或者是一些联合的指标都有问题的时候，可以反映出集群是否健康的程度。同时再结合指标关联的根因分析，去实现从众多的指标监控收集上来的信息去自动化的分发诊断，匹配更深层的诊断，得到更好的解决方案。

对于混部场景，龙蜥社区系统运维 SIG 也有一些探索。首先是对整个资源画像去做了算法上的研究。由于在线任务是普遍存在潮汐规律的，所以在混步场景中会对它进行资源画像的训练。同时，还会对相关的水位进行评估。通过训练和评估之后，会给出系统参数的一些配置和调整建议。

综上两个方面，我们是希望从底层去进行监控上的采集指标，结合中心端数据分析，例如指标关联分析、日志分析、异常事件分析，做到轻量级的诊断，能够自动化的进行，或者是提示给用户可以进行更深层次的一些诊断。做到这样的 AI 根因分析和智能诊断，实现应用性能和瓶颈发现、智能监控、异常告警及深入诊断。

03 SysOM 应用观测实践

从应用观测上来说，主要是想深度剖析的问题成因，自顶向下的关联去降低应用运维门槛，可以覆盖典型的包括 Mysql、Java 和 Nginx 这样的应用，包括全局的流量拓扑、数据库可应用的观测、Java 应用的可观测和 HTTP 应用的可观测。

上图就是全局流量拓扑。可以看到如果节点异常的时候会将它标红，同时轻触会有相关的弹出指标，可以跳转到应用的监控大盘或者是异常事件的大盘。通过调转之后，再去进行相应的分析诊断，根因分析。这样的全局流量拓扑，也使得用户能够有更直观的场景，去看到集群或者主机上的应用状态。

上图是 Mysql 的应用实践。可以看到指标监控出现了一些异常的浮动。点击相关的异常，看到下面可以观测到 RT 也高上来，点击图示的一些异常或者 RT 高的事件之后，可以进入相关的分析诊断页面，会给用户提示出相关的诊断信息，或者是否需要进行相关的深入诊断。

对于 Nginx 应用也是类似，会观测到指标的异常或者是数据的抖动，也有相对应的异常事件可以进行点击跳转，去到更加深层次的诊断。

对于 Java 的应用，会关注实时 RT 或者是一占用 CPU 高的一些指标，或者是如上图右下角所示的一些抖动。对于 Java 运行时的分析，在 SysOM 整个运行页面上，可以点击左上角去进行异常原因的进一步诊断，同时会给出修复的建议。同时结合 Java 调用栈去给出关键的调用栈信息。再比如刚刚上图还有实时 RT，可能也有一些走延时增大这样的现象，也是同样的进入诊断界面可以看到，此时主要时间是消耗在 CPU 上。对于抖动，也可以从左键点入进入指标异常分析，类似的有对于多个指标进行指标关联，指标对比，再去通过指标给出更加详细的异常原因和推荐进一步的诊断和修复建议。