Go 內(nèi)置的 pprof 雖然是問題定位的神器，但是沒有辦法讓你恰好在出問題的那個時間點(diǎn)，把相應(yīng)的現(xiàn)場保存下來進(jìn)行分析。特別是一些隨機(jī)出現(xiàn)的內(nèi)存泄露、CPU 抖動，等你發(fā)現(xiàn)有泄露的時候，可能程序已經(jīng) OOM 被 kill 掉了。而 CPU 抖動，你可以蹲了一星期都不一定蹲得到。

這個問題最好的解決辦法是 continuous profiling，不過這個理念需要公司的監(jiān)控系統(tǒng)配合，在沒有達(dá)到最終目標(biāo)前，我們可以先向前邁一小步，看看怎么用比較低的成本來解決這個問題。

從現(xiàn)象上，可以將出問題的癥狀簡單分個類：

• cpu 抖動：有可能是模塊內(nèi)有一些比較冷門的邏輯，觸發(fā)概率比較低，比如半夜的定時腳本，觸發(fā)了以后你還在睡覺，這時候要定位就比較鬧心了。
• 內(nèi)存使用抖動：有很多種情況會導(dǎo)致內(nèi)存使用抖動，比如突然涌入了大量請求，導(dǎo)致本身創(chuàng)建了過多的對象。也可能是 goroutine 泄露。也可能是突然有鎖沖突，也可能是突然有 IO 抖動。原因太多了，猜是沒法猜出根因的。
• goroutine 數(shù)暴漲，可能是死鎖，可能是數(shù)據(jù)生產(chǎn)完了 channel 沒關(guān)閉，也可能是 IO 抖了什么的。

CPU 使用，內(nèi)存占用和 goroutine 數(shù)，都可以用數(shù)值表示，所以不管是“暴漲”還是抖動，都可以用簡單的規(guī)則來表示：

• xx 突然比正常情況下的平均值高出了 25%
• xx 超過了模塊正常情況下的最高水位線

這兩條規(guī)則可以描述大部分情況下的異常，規(guī)則一可以表示瞬時的，劇烈的抖動，之后可能迅速恢復(fù)了；規(guī)則二可以用來表示那些緩慢上升，但最終超出系統(tǒng)負(fù)荷的情況，例如 1s 泄露一兆內(nèi)存，直至幾小時后 OOM。

而與均值的 diff，在沒有歷史數(shù)據(jù)的情況下，就只能在程序內(nèi)自行收集了，比如 goroutine 的數(shù)據(jù)，我們可以每 x 秒運(yùn)行一次采集，在內(nèi)存中保留最近 N 個周期的 goroutine 計數(shù)，并持續(xù)與之前記錄的 goroutine 數(shù)據(jù)均值進(jìn)行 diff：

time-Page-2

比如像圖里的情況，前十個周期收集到的 goroutine 數(shù)在 1300 左右波動，而最新周期收集到的數(shù)據(jù)為 2w+，這顯然是瞬時觸發(fā)導(dǎo)致的異常情況，那么我們就可以在這個點(diǎn)自動地去做一些事情，比如：

• 把當(dāng)前的 goroutine 棧 dump 下來
• 把當(dāng)前的 cpu profile dump 下來
• 把當(dāng)前的 off-cpu profile dump 下來
• 不怕死的話，也可以 dump 幾秒的 trace

文件保存下來，模塊掛掉也就無所謂了。之后在喝茶的時候，發(fā)現(xiàn)線上曾經(jīng)出現(xiàn)過崩潰，那再去線上機(jī)器把文件撈下來，一邊喝茶一邊分析，還是比較悠哉的。