线上 Go 程序偶尔出现异常怎么办？这个思路可解决你的烦恼

发布时间：2025-11-05 10:43:47 来源：创站工坊 作者：系统运维

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

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

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

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

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

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

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

time-Page-2

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

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

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

相关文章