[TOC]web
咱們來回顧一下以前分享的知識點:瀏覽器
介紹了基本你的gRPC的使用方式,框架,交互方式等網絡
分享了gRPC的四種認證方式中重要的2種方式,有興趣能夠點擊看看哦框架
整理了openssl 證書的生成,關鍵點已經高亮標註,值得一看函數
gRPC生態中的中間件,主要是作統一認證工做,沒必要要在每個接口中都寫一次認證方式工具
文章中有分享gRPC的各類功能的中間件,有興趣能夠點擊連接,大佬們還請不吝賜教post
今天咱們來介紹一下go的請求追蹤,也就是說go Trace ,分享trace有以下幾個緣由:學習
trace
以後,你可以本身去實踐,清晰的瞭解整個程序的調用棧
咱們或許都有這樣的體會,本身思考明白,設計出來的程序,能夠很清晰明瞭的將細節解釋明白,對功能的增刪改也是能夠作到靈活應對。spa
但是讓咱們一會兒去修改別人寫的功能或模塊的時候,不少時候會一臉懵逼,這也不敢動,那也不敢動,在不理解的狀況下,有疑問,必定要問清楚原理和邏輯,不然搞很差就是線上問題。線程
如上狀況,最重要的一個緣由就是本身對當前模塊/功能的熟悉程度,以及本身的思惟模型是否可遷移。
總而言之,對程序,要有敬畏之心,好奇之心,鍥而不捨專研下去,要有解決問題的決心。
不合適
go tool pprof
合適
go tool trace
能夠經過 view trace
連接提供的其餘可視化功能,對於診斷爭用問題幫助極大GOMAXPROCS
設置能夠同時執行的cpu
的最大數量,此處咱們設置爲 1 個
server.go
package main import ( "context" "fmt" "os" "runtime" "runtime/trace" "sync" ) func main() { // 使用 GOMAXPROCS設置能夠同時執行的cpu的最大數量 爲 1 個 runtime.GOMAXPROCS(1) f, _ := os.Create("myTrace.dat") defer f.Close() //開始跟蹤,在跟蹤時,跟蹤將被緩衝並寫入 一個咱們指定的文件中 _ = trace.Start(f) defer trace.Stop() // 我們自定義一個任務 ctx, task := trace.NewTask(context.Background(), "customerTask") defer task.End() var wg sync.WaitGroup wg.Add(10) for i := 0; i < 10; i++ { // 啓動10個協程,模擬作任務 go func(num string) { defer wg.Done() // 標記 num trace.WithRegion(ctx, num, func() { var sum, i int64 // 模擬執行任務 for ; i < 500000000; i++ { sum += i } fmt.Println(num, sum) }) }(fmt.Sprintf("num_%02d", i)) } wg.Wait() }
操做步驟:
myTrace.dat
trace
的web頁面
,以下
tag | 說明 |
---|---|
View trace | 查看可視化的跟蹤狀況 |
Goroutine analysis | 協程分析 |
Network blocking profile (⬇) | 網絡擁塞狀況 |
Synchronization blocking profile (⬇) | 同步阻塞狀況 |
Syscall blocking profile (⬇) | 系統調用阻塞狀況 |
Scheduler latency profile (⬇) | 調度延遲狀況 |
User-defined tasks | 用戶自定義的任務 |
User-defined regions | 用戶自定義的區域 |
Minimum mutator utilization | 最低 Mutator 利用率 |
可視化的web追蹤頁面
tag | 說明 |
---|---|
時間線 | 用於顯示執行的時間單元,根據時間維度的不一樣能夠調整區間,能夠點擊按鈕,即可以在界面上拖拽時間線 |
堆 | 用於顯示執行期間的內存分配和釋放狀況 |
協程 | 用於顯示在執行期間的每一個 Goroutine 運行階段有多少個協程在運行,其包含 GC 等待(GCWaiting )、可運行(Runnable )、運行中(Running )這三種狀態。 |
OS 線程 | 顯示在執行期間有多少個線程在運行,其包含正在調用 Syscall (InSyscall )、運行中(Running )這兩種狀態。 |
虛擬處理器 | 每一個虛擬處理器顯示一行,虛擬處理器的數量通常默認爲系統內核數。 |
協程和事件 | 顯示在每一個虛擬處理器上有什麼 Goroutine 正在運行,而連線行爲表明事件關聯。 |
可使用 shift + ?
喚出幫助手冊
點擊PROC顏色區域
能夠看到該處理器此段時間再作什麼事情,如圖
tag | 說明 |
---|---|
Start | 開始時間 |
Wall Duration: | 持續時間 |
Self Time | 執行時間 |
Start Stack Trace | 開始時的堆棧信息 |
End Stack Trace | 結束時的堆棧信息 |
Incoming flow | 輸入流 |
Outgoing flow | 輸出流 |
Preceding events | 以前的事件 |
Following events | 以後的事件 |
All connected | 全部鏈接的事件 |
Event(s)下方的 Preceding events
點擊進去能夠看到每個調用棧的執行時間
便可看到此段時間的調用棧,開始時間,結束時間,以及用戶定義的任務開了多少個協程等等
User-defined tasks
點擊Count
點擊goroutine view
點擊顏色區域
便可看到此段時間具體在執行什麼動做,具體的信息以下
與上述查看用戶自定義任務的方式大同小異,以下
User-defined regions
點擊具體的Count
便可查看到此協程的總共耗時,網絡擁塞,同步阻塞,系統調用阻塞,調度等待,垃圾回收掃描,垃圾回收暫停的相關參數信息
那麼某一些關鍵的goroutine
被阻止運行時,可能會有延遲問題,大概的緣由相信你們應該有些譜了吧
正好上述緣由的追蹤均可以使用go tool trace 識別到 ,對於咱們追蹤問題,查詢問題原理起了很好的助力做用
好了,本次就到這裏,下一次分享 gRPC的HTTP網關,
技術是開放的,咱們的心態,更應是開放的。擁抱變化,向陽而生,努力向前行。
我是小魔童哪吒,歡迎點贊關注收藏,下次見~