關于go-zero服務自動收集問題分析

更新時間：2022年12月14日 16:16:25 作者：Mikaelemmmm

這篇文章主要介紹了關于go-zero服務自動收集問題，本文給大家介紹的非常詳細，對大家的學習或工作具有一定的參考借鑒價值，需要的朋友可以參考下

前言

? 對于pprof，相信熟悉go語言的程序員基本都不陌生，一般線上的問題都是靠它可以快速定位。但是實際項目中，很多時候我們?yōu)榱诵阅芏疾粫_啟它，但是出了問題又要靠它來分析。好在go-zero已經(jīng)幫我們很好的集成進來了，我們只需要像開關一樣去開啟、關閉它即可，這樣我們就可以配合運維監(jiān)控，當出現(xiàn)cpu、內(nèi)存等異常情況時候，自動開始開啟收集，比如大半夜你睡的正香的時候，那么第二天可以通過分析當時的采樣還原現(xiàn)場，那我們看看go-zero是如何做的。

源碼分析

? 我們可以看go-zero源碼位置 https://github.com/zeromicro/go-zero/blob/master/core/proc/signals.go

func init() {
	go func() {
		......
		signals := make(chan os.Signal, 1)
		signal.Notify(signals, syscall.SIGUSR1, syscall.SIGUSR2, syscall.SIGTERM)
		for {
			v := <-signals
			switch v {
			....
			case syscall.SIGUSR2:
				if profiler == nil {
					profiler = StartProfile()
				} else {
					profiler.Stop()
					profiler = nil
				}
		.......
		}
	}()
}

服務啟動的時候，go-zero在init初始化了監(jiān)聽信號操作（gracefulStop也是通過這里通知的，這里不展開講了），可以看到在接收到 syscall.SIGUSR2 信號時候，如果是第一次就開始收集，第二次就停止收集，看到這塊可能瞬間就明白了，我們只需要在服務器執(zhí)行 “kill -usr2 [服務進程id]” 就可以開始收集這個服務的pprof信息了，在執(zhí)行一次就停止了收集，就可以將這些文件導出到本地，使用go tool pprof分析。

一次線上實戰(zhàn)

我們線上有一個mq的服務監(jiān)控告警，內(nèi)存占用比較高，這時候我打開grafna看到服務內(nèi)存累計占用的確異常，如下圖：

這時候到線上找到這個服務的服務器，執(zhí)行了ps aux | grep xxx_mq ，查詢到了這個mq服務的進程ID 21181，我們這時候就可以給這個xxx_mq服務發(fā)送信號收集pprof信息 “kill -usr2 21181”

第一次執(zhí)行了這個命令后，在對應服務的access.log日志中可以看到enable了pprof，當我們再次執(zhí)行 “ kill -usr2 21181” access.log日志中可以看到disable了pprof信息，這時候代表收集完成了。值得注意的是收集的信息都在/tmp文件夾下，以這個服務名命名的如下：

xxxx-mq-cpu-xxx.pprof
xxxx-mq-memory-xxx.pprof
xxxx-mq-mutex-xxx.pprof
xxxx-mq-block-xxx.pprof
…

這時候就可以下載對應的pprof去本地分析，可以使用go tool pprof xxxx-mq-memory-xxx.pprof，也可以配合graphviz使用web ui查看，由于我這邊通過命令行就快速定位了問題，就沒用使用web ui。

我使用go tool pprof xxxx-**-mq-memory-xxx.pprof 然后進入命令行交互，使用top 30查看前面占用較高的資源

前面基本是底層序列化等操作，發(fā)現(xiàn)主要問題集中在紅色框中導致持續(xù)上漲的內(nèi)存，因為業(yè)務同學在mq中消費完了消息又向下游其他的mq服務使用publisher發(fā)送一個mq消息，每次發(fā)送都調用一個NewPublisher然后在defer close，恰恰這個mq服務又大量消息消費又特別頻繁，導致內(nèi)存不斷上漲，最終解決方案將NewPublisher在svcCtx中初始化一個client就可以了，沒必要每次都要NewPublisher，世界又恢復清凈了。

寫在最后

想一下go-zero給了我們pprof開關，讓我們很方便的實現(xiàn)分析問題，但是不是所有問題都是一直存在的，比如半夜突發(fā)內(nèi)存、cpu過高，早上起來服務正常了，這怎么排查？所以我們希望如果異常了，能保留問題現(xiàn)場，那我們是不是可以配合運維監(jiān)控實現(xiàn)自動保存問題現(xiàn)場呢？比如內(nèi)存、cpu連續(xù)超過80%指標3分鐘的話，我們就調用這個開關收集，之后我們就可以根據(jù)這個文件來分析問題了，這樣就達到自動化了。