Go 项目做的比较大（主要说代码多，参与人多）之后，可能会遇到类似下面这样的问题：

Go 内置的 pprof 虽然是问题定位的神器，但是没有办法让你恰好在出问题的那个时间点，把相应的现场保存下来进行分析。特别是一些随机出现的内存泄露、CPU 抖动，等你发现有泄露的时候，可能程序已经 OOM 被 kill 掉了。而 CPU 抖动，你可以蹲了一星期都不一定蹲得到。

这个问题最好的解决办法是 continuous profiling，不过这个理念需要公司的监控系统配合，在没有达到最终目标前，我们可以先向前迈一小步，看看怎么用比较低的成本来解决这个问题。

从现象上，可以将出问题的症状简单分个类：

cpu 抖动：有可能是模块内有一些比较冷门的逻辑，触发概率比较低，比如半夜的定时脚本，触发了以后你还在睡觉，这时候要定位就比较闹心了。
内存使用抖动：有很多种情况会导致内存使用抖动，比如突然涌入了大量请求，导致本身创建了过多的对象。也可能是 goroutine 泄露。也可能是突然有锁冲突，也可能是突然有 IO 抖动。原因太多了，猜是没法猜出根因的。
goroutine 数暴涨，可能是死锁，可能是数据生产完了 channel 没关闭，也可能是 IO 抖了什么的。

CPU 使用，内存占用和 goroutine 数，都可以用数值表示，所以不管是“暴涨”还是抖动，都可以用简单的规则来表示：

这两条规则可以描述大部分情况下的异常，规则一可以表示瞬时的，剧烈的抖动，之后可能迅速恢复了；规则二可以用来表示那些缓慢上升，但最终超出系统负荷的情况，例如 1s 泄露一兆内存，直至几小时后 OOM。

而与均值的 diff，在没有历史数据的情况下，就只能在程序内自行收集了，比如 goroutine 的数据，我们可以每 x 秒运行一次采集，在内存中保留最近 N 个周期的 goroutine 计数，并持续与之前记录的 goroutine 数据均值进行 diff：

time-Page-2

比如像图里的情况，前十个周期收集到的 goroutine 数在 1300 左右波动，而最新周期收集到的数据为 2w+，这显然是瞬时触发导致的异常情况，那么我们就可以在这个点自动地去做一些事情，比如：

文件保存下来，模块挂掉也就无所谓了。之后在喝茶的时候，发现线上曾经出现过崩溃，那再去线上机器把文件捞下来，一边喝茶一边分析，还是比较悠哉的。

这里面稍微麻烦一些的是 CPU 和内存使用量的采集，现在的应用可能跑在物理机上，也可能跑在 docker 中，因此在获取用量时，需要我们自己去做一些定制。物理机中的数据采集，可以使用 gopsutil[1]，docker 中的数据采集，可以参考少量 cgroups[2] 中的实现。

更具体的代码会在之后的文章讲，我们编写的 lib 也会在不久后开源，当然，这篇文章其实已经把大部分实现思路讲完了~

参考资料

[1]

gopsutil: https://github.com/shirou/gopsutil

[2]

cgroups: https://github.com/containerd/cgroups

瑞岁编程网