系统运维 SysOM profiling 在云上环境的应用观测实践 | 龙蜥技术

2023-02-02
北京
本文字数：2565 字
阅读完需：约 8 分钟

文/系统运维 SIG

01 背景

云上环境，ECS 用户一般都会布置一些常规监控观察系统指标或者业务指标，虽然通过这些指标能监控到系统或者应用的异常，但却不能完全了解系统/应用正在做什么导致的指标异常。常见的如：看到系统 CPU 偶尔飙高却不知道是哪个应用引起、抓包发现报文已经到达了本机却不知道应用为何迟迟不收包等等，束手无策之余只能认为“系统有问题” ，而在排查系统问题之后发现往往是应用对系统资源在做一些野蛮消耗，这些应用有些是业务自身，有些则悄悄躲在 "ps -ef" 的千百个任务中，很难发现。于是我们想通过 profiling 的方式去观测系统/应用的运行行为，帮助用户解决难题。

02 实现方案

所谓的"profiling"可以认为是以一种动态的方式去观测程序的执行逻辑。这个程序可以大到一个操作系统，甚至是一个基础设施，有兴趣的同学可以看下文[1]，也可以小到一个 pod，甚至一个简单的应用程序。如果在这种方式上再增加一个时间维度，持续性的以“profiling”的方式去做观测，对上面说的常见系统资源偶现指标异常等问题就可以做一个很好的追踪，不需要苦苦守着问题出现。

那么如何去做 profiling 呢？

不同的编程语言有不同的 profiling 工具，像 Go 的 pprof、Java 的 jstack 等，这里我们希望观测应用但又想抛开语言的差异化，于是我们借助 eBPF 来实现程序栈信息的获取，这里的栈信息包括一个应用在用户态执行和内核态的执行的全部信息。借助 eBPF 的好处在于我们可以做到 profiling 过程的可控：频率快慢、运行时安全、系统资源占用小等。

如下图所示，通过 eBPF 加 PMU(Performance Monitoring Unit)事件我们就可以定期获取应用的执行栈信息，同时利用 bpf map 对每个应用的栈信息做统计。借助我们前期开源的 Coolbpf(eBPF 开发编译框架，具备 CORE、高低版本适配能力)，我们对不同的内核版本做了相关适配，具体可执行版本见下文。

profiling 应用的那些行为逻辑

一个程序的运行时最简单的可以概括为执行和不执行两种状态，即 on cpu 和 off cpu。on cpu 我们希望看到程序占用 CPU 时的执行逻辑，哪个任务甚至任务的哪一段代码在 CPU 上消耗资源，而 off cpu 我们希望看到应用是否是自愿放弃的 CPU，出于何种原因不占用 CPU，如等锁、等 IO 等，以此希望发现一些应用等损耗时造成的收发包延迟等问题。

针对网络抖动的常见问题我们在收包的两个阶段：

硬中断和软中断收包。

2.用户态应用进程系统调用取包，也做了相关的 profiling 观测：

如何持续地 profiling

整体我们采用 c/s 的架构方式，日常问题定位中我们只需要部署 agent 去负责 profiling，在 server 端去查看数据。同时将 profiling 数据做切片处理，定时从 map 中拿数据并清空 map 上一周期的采样数据，这样的话确保我们在做数据回放的时候看到的是对应时间段的 profiling 结果。考虑用户对云上环境数据安全的要求，我们也可以借助 SLS 通道完成数据上传。

03 使用说明

在 SysOM 上可以有两种使用方式。

如果想持续性的观测系统那么可以监控模式下 profiling 功能，对应路径在：监控中心->机器 ip->General dashboard->sysom-profiling。

如果是想获取 profiling 的一些结论性信息可以通过诊断模式，对应路径在：诊断中心->调度诊断中心->应用 profile 分析。

当前会统计 top 10 应用 CPU 占用百分比，同时会将热点栈信息展示出，热点栈在应用自身所有栈信息的百分比也会做一个统计，最后会对热点栈做个分析，明确热点栈是在应用自身还是在 OS。

以上展示的是 oncpu 的面板信息，profiling 的其他功能的面板信息持续适配中。

具体 profiling 功能可以执行 sysAK 统一监控目录下的 raptor 获取，除了功能项也可以设置运行模式等。

运行模式

profilng 功能支持的内核版本

CentOS 7.6 及以上，alinux2/3、anolis，同时也支持了倚天 Arm 架构。

04 相关案例

1.某用户 CPU 指标偶有飙高，而相同业务的其他机器并无异常，怀疑 ECS 资源有问题

ecs 监控如下：

由于是间歇性抖动，常规手段较难抓到现场，对系统持续 profiling 一天后发现抖动时刻对应系统上 nginx 应用占用的 CPU 最多，并且 nginx 主要在做收发包处理，用户优化业务流量请求分布后该问题得到解决。

2.某用户系统业务压力没有增加的情况下 sys 指标莫名升高

用户监控如下：

对系统做 profiling 观测后发现有个 cachestat 脚本开启了 ftrace 功能，该脚本是之前同学定位问题部署后没有及时停止，停掉脚本后系统恢复正常。由于 ftrace 不是通过 sysfs 目录打开，查看 sysfs 的 ftrace 其实并无改动。

3.某用户机器 CPU 指标异常，ssh 无法登陆，整机夯住

用户监控图如下：

ssh 无法登陆、CPU 指标异常、内存有压力，根据“经验”一般怀疑系统在做内存回收，但是通常情况下无法拿到第一现场佐证，没有说服力。通过 profiling，部署一天，我们抓到了第一现场，13:57 分 CPU 占用异常高，大阳线拔地而起，再看系统行为就是内核占着 CPU 在做内存回收，随后建议用户优化应用的内存使用。该问题可以算是云上环境的“经典问题”。