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

文/系统运维 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 等，以此希望发现一些应用等损耗时造成的收发包延迟等问题。

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

1. 硬中断和软中断收包。

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 获取，除了功能项也可以设置运行模式等。

运行模式

常规模式	trigger 模式	filter 模式
定时触发去 profiling，默认 5 分钟一次	设定指标阈值异常时触发	限定应用或者 CPU，针对明确了异常应用或者应用绑核只在特定 CPU 上有问题场景。

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 在做内存回收，随后建议用户优化应用的内存使用。该问题可以算是云上环境的“经典问题”。

4.某用户机器 ping 报文偶现秒级时延抖动

ping 主机偶现秒级的时延抖动，同时伴随个别 CPU sys 偶现占用达到 100%。

由于是个别 CPU 的短暂抖动，因此我们对某一 CPU 上的执行情况做 profiling。我们看到网络抖动时间点，runc 在读 /proc/cpuinfo 信息，“smp_call_function_single”核间call 存在热点，跟我们看到的 sys 偶尔高现象也能吻合。

最终容器同学通过对 cpuinfo 信息缓存备份以减少对 /proc/cpuinfo 的访问，缓解系统压力，当然高版本内核对 /proc/cpuinfo 的访问也做了部分优化，相关 patch 见[4]。

05

总结

SysOM 致力打造一个集主机管理、配置部署、监控报警、异常诊断、安全审计等一些列功能的自动化运维平台。以上是对 SysOM profiling 功能的相关介绍，由于篇幅有限只介绍了部分案例，相关功能模块已完成功能验证，正在开源中，敬请期待。

更多的运维技术，可关注我们的 gitee 开源运维仓库：SysOM：https://gitee.com/anolis/sysomSysAK：https://gitee.com/anolis/sysakCoolbpf：https://gitee.com/anolis/coolbpf

​

参考

[1]《Google-Wide Profiling: A Continuous Profiling Infrastructure for Data Centers》

[2]《Observability Engineering》

[3]  http://www.brendangregg.com/perf.html

[4] https://www.mail-archive.com/[e-mail]/msg2414427.html

—— 完 ——

加入龙蜥社群

加入微信群：添加社区助理-龙蜥社区小龙（微信：openanolis_assis），备注【龙蜥】与你同在；加入钉钉群：扫描下方钉钉群二维码。

往期精彩推荐1.人人都可以参与开源！龙蜥社区最不容错过的开发者活动来了
2.小龙力荐！人人都可以完成算法代码，简单易上手3.龙蜥开发者说：6 年前打开的开源“潘多拉盲盒”，如今都解了哪些未知数 | 第 15 期
4.镜像拉取节省 90% 以上，快手基于 Dragonfly 的超大规模分发实践

▼ 欢迎点击阅读原文，访问「系统运维 SIG」主页。