无人值守的自动 dump(一)

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

  • 程序老是半夜崩,崩了以后就重启了,我也醒不来,现场早就丢了,不知道怎么定位
  • 这压测开压之后,随机出问题,可能两小时,也可能五小时以后才出问题,这我蹲点蹲出痔疮都不一定能等到崩溃的那个时间点啊
  • 有些级联失败,最后留下现场并不能帮助我们准确地判断问题的根因,我们需要出问题时第一时间的现场

1597142880827-122ddc46-598d-468a-88d8-3dbc23059744

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

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

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

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

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

  • xx 突然比正常情况下的平均值高出了 25%
  • xx 超过了模块正常情况下的最高水位线

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

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

time-Page-2

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

  • 把当前的 goroutine 栈 dump 下来
  • 把当前的 cpu profile dump 下来
  • 把当前的 off-cpu profile dump 下来
  • 不怕死的话,也可以 dump 几秒的 trace

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

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

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

无人值守的自动 dump(一)
Share this

家境贫寒,整理不易,客官如果觉得不错欢迎打赏!我的微信 xargin_buaa,如果想交流也欢迎来加~

京ICP备15065353号-1