前言

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

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

一次線上實(shí)戰(zhàn)

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

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

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

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

這時(shí)候就可以下載對(duì)應(yīng)的pprof去本地分析，可以使用go tool pprof xxxx-mq-memory-xxx.pprof，也可以配合graphviz使用web ui查看，由于我這邊通過(guò)命令行就快速定位了問(wèn)題，就沒(méi)用使用web ui。

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

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

寫在最后

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

項(xiàng)目地址

go-zero微服務(wù)框架：https://github.com/zeromicro/go-zero

go-zero微服務(wù)最佳實(shí)踐項(xiàng)目：https://github.com/Mikaelemmmm/go-zero-looklook

到此這篇關(guān)于關(guān)于go-zero服務(wù)自動(dòng)收集問(wèn)題分析的文章就介紹到這了,更多相關(guān)go-zero服務(wù)自動(dòng)收集內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論