[[355432]]

本文轉載自微信公眾號「 腦子進煎魚了」，作者陳煎魚。轉載本文請聯系腦子進煎魚了公眾號。

在類 Unix 系統中，我們常常會使用 ps 命令來查看系統當前所運行的進程信息，該命令為我們提供了較大的幫助，能夠快速的定位到某些進程的運行情況和狀態。

而在 Go 語言中，也有類似的命令工具，那就是 gops[1](Go Process Status)。

gops 是由 Google 官方出品的一個命令行工具，與 ps 命令的功能類似，能夠查看并診斷當前系統中 Go 程序的運行狀態及內部情況，在一些使用場景中具有較大的存在意義，屬于常用工具。

在本文中我們將對 gops 進行全面的使用和介紹。

基本使用

我們先創建一個示例項目，然后在項目根目錄執行下述模塊安裝命令：

$ go get -u github.com/google/gops 

寫入如下啟動代碼：

import ( 
 ... 
 "github.com/google/gops/agent" 
) 
 
func main() { 
 // 創建并監聽 gops agent，gops 命令會通過連接 agent 來讀取進程信息 
 // 若需要遠程訪問，可配置 agent.Options{Addr: "0.0.0.0:6060"}，否則默認僅允許本地訪問 
 if err := agent.Listen(agent.Options{}); err != nil { 
  log.Fatalf("agent.Listen err: %v", err) 
 } 
  
 http.HandleFunc("/hello", func(w http.ResponseWriter, r *http.Request) { 
  _, _ = w.Write([]byte(`Go語言編程之旅`)) 
 }) 
 _ := http.ListenAndServe(":6060", http.DefaultServeMux) 
} 

在完成示例啟動代碼的寫入后，我們啟動該程序，并在命令行執行 gops 命令進行查看：

3739  3725  main  * go1.14   /private/var/folders/jm/.../b001/exe/main 
3725  71093 go      go1.14   /usr/local/Cellar/go/1.14/libexec/bin/go 
62357 46131 go      go1.14   /usr/local/Cellar/go/1.14/libexec/bin/go 
3872  3742  gops    go1.14   /Users/eddycjy/go/bin/gops 
62379 62357 main    go1.14   /private/var/folders/jm/.../b001/exe/main 
... 

在上述輸出中，你很快就發現有一點不一樣，那就是為什么某一行的輸出結果中會包含一個 * 符號，如下：

3739  3725  main  * go1.14   /private/var/folders/jm/.../b001/exe/main 

這實際上代表著該 Go 進程，包含了 agent，因此它可以啟用更強大的診斷功能，包括當前堆棧跟蹤，Go版本，內存統計信息等等。

在最后也有一個 main 的 Go 進程，它不包含 * 符號，這意味著它是一個普通的 Go 程序，也就是沒有植入 agent，只能使用最基本的功能。

常規命令

gops 工具包含了大量的分析命令，我們可以通過 gops help 進行查看：

$ gops help 
gops is a tool to list and diagnose Go processes. 
 
Usage: 
  gops <cmd> <pid|addr> ... 
  gops <pid> # displays process info 
  gops help  # displays this help message 
 
Commands: 
  stack      Prints the stack trace. 
  gc         Runs the garbage collector and blocks until successful. 
  setgc      Sets the garbage collection target percentage. 
  memstats   Prints the allocation and garbage collection stats. 
  version    Prints the Go version used to build the program. 
  stats      Prints runtime stats. 
  trace      Runs the runtime tracer for 5 secs and launches "go tool trace". 
  pprof-heap Reads the heap profile and launches "go tool pprof". 
  pprof-cpu  Reads the CPU profile and launches "go tool pprof". 

在接下來的小節中，我們將針對幾個常用的分析功能進行概要分析。

查看指定進程信息

$ gops <pid> 
parent PID: 3725 
threads: 7 
memory usage: 0.042% 
cpu usage: 0.003% 
username: eddycjy 
cmd+args: /var/folders/jm/pk20jr_s74x49kqmyt87n2800000gn/T/go-build943691423/b001/exe/main 
elapsed time: 10:56 
local/remote: 127.0.0.1:59369 <-> :0 (LISTEN) 
local/remote: *:6060 <-> :0 (LISTEN) 

獲取 Go 進程的概要信息，包括父級PID、線程數、內存/CPU使用率、運行者的賬戶名、進程的啟動命令行參數、啟動后所經過的時間以及 gops 的 agent 監聽信息(若無植入 agent，則沒有這項信息)。

查看調用棧信息

$ gops stack 3739 
goroutine 19 [running]: 
runtime/pprof.writeGoroutineStacks(0x1385aa0, 0xc000132038, 0x30, 0xd0) 
 ... 
 /Users/eddycjy/go/src/github.com/google/gops/agent/agent.go:185 +0x1af 
github.com/google/gops/agent.listen() 
 /Users/eddycjy/go/src/github.com/google/gops/agent/agent.go:133 +0x2bf 
created by github.com/google/gops/agent.Listen 
 /Users/eddycjy/go/src/github.com/google/gops/agent/agent.go:111 +0x36b 
 
goroutine 1 [IO wait]: 
internal/poll.runtime_pollWait(0x2f55e38, 0x72, 0x0) 
 /usr/local/Cellar/go/1.14/libexec/src/runtime/netpoll.go:203 +0x55 
 ... 

獲取對應進程的代碼調用堆棧信息，可用于分析調用鏈路。

查看內存使用情況

$ gops memstats 3739 
alloc: 1.15MB (1205272 bytes) 
total-alloc: 1.15MB (1205272 bytes) 
sys: 69.45MB (72827136 bytes) 
lookups: 0 
mallocs: 644 
frees: 12 
heap-alloc: 1.15MB (1205272 bytes) 
heap-sys: 63.66MB (66748416 bytes) 
heap-idle: 62.05MB (65060864 bytes) 
heap-in-use: 1.61MB (1687552 bytes) 
heap-released: 62.02MB (65028096 bytes) 
heap-objects: 632 
... 

獲取 Go 在運行時的當前內存使用情況，主要是 runtime.MemStats[2] 的相關字段信息。

查看運行時信息

$ gops stats 3739 
goroutines: 2 
OS threads: 8 
GOMAXPROCS: 4 
num CPU: 4 

獲取 Go 運行時的基本信息，包括當前的 Goroutine 數量、系統線程、GOMAXPROCS 數值以及當前系統的 CPU 核數。

查看 trace 信息

$ gops trace 3739 
Tracing now, will take 5 secs... 
Trace dump saved to: /var/folders/jm/pk20jr_s74x49kqmyt87n2800000gn/T/trace092133110 
Parsing trace... 
Splitting trace... 
Opening browser. Trace viewer is listening on http://127.0.0.1:53811 

與 go tool trace 作用基本一致。

查看 profile 信息

$ gops pprof-cpu 3739 
Profiling CPU now, will take 30 secs... 
Profile dump saved to: /var/folders/jm/pk20jr_s74x49kqmyt87n2800000gn/T/profile563685966 
Binary file saved to: /var/folders/jm/pk20jr_s74x49kqmyt87n2800000gn/T/binary265411413 
File: binary265411413 
Type: cpu 
... 
(pprof)  
 
$ gops pprof-heap 3739 
Profile dump saved to: /var/folders/jm/pk20jr_s74x49kqmyt87n2800000gn/T/profile967076057 
Binary file saved to: /var/folders/jm/pk20jr_s74x49kqmyt87n2800000gn/T/binary904879716 
File: binary904879716 
Type: inuse_space 
... 
(pprof)  

與 go tool pprof 作用基本一致。

你怎么知道我是誰

在學習了 gops 的使用后，我們突然發現一個問題，那就是 gops 是怎么知道哪些進程是與 Go 相關的進程?

如果是植入了 agent 的應用程序還好說，可以理解為埋入了識別點。但實際情況是，沒有植入 agent 的 Go 程序也被識別到了，說明 gops 本身并不是這么實現的，考慮植入agent 應當只是用于診斷信息的拓展使用，并不是一個識別點，那么 gops 到底是怎么發現哪些進程是 Go 相關的呢?

我們回歸問題的前置需求，假設我們想知道哪些進程與 Go 相關，那么第一步我們要先知道我們當前系統中都運行了哪些進程，這些記錄在哪里有?

認真思考一下，答案也就呼之欲出了，假設是 Linux 相關的系統下，其會將進程所有的相關信息都按照約定的數據結構寫入 /proc 目錄下，因此我們有充分的懷疑認為 gops 就是從 /proc 目錄下讀取到相關信息的，源代碼如下：

func PidsWithContext(ctx context.Context) ([]int32, error) { 
 var ret []int32 
 
 d, err := os.Open(common.HostProc()) 
 if err != nil { 
  return nil, err 
 } 
 defer d.Close() 
 
 fnames, err := d.Readdirnames(-1) 
 if err != nil { 
  return nil, err 
 } 
 for _, fname := range fnames { 
  pid, err := strconv.ParseInt(fname, 10, 32) 
  if err != nil { 
   continue 
  } 
  ret = append(ret, int32(pid)) 
 } 
 
 return ret, nil 
} 
 
// common.HostProc 
func HostProc(combineWith ...string) string { 
 return GetEnv("HOST_PROC", "/proc", combineWith...) 
} 

在上述代碼中，該方法通過調用 os.Open 方法打開了 proc 目錄，并利用 Readdirnames 方法對該目錄進行了掃描，最終獲取到了所有需要 pid，最終完成其使命，返回了所有 pid。

在確定了 gops 是通過掃描 /proc 目錄得到的進程信息后，我們又遇到了一個新的疑問點，那就是 gops 是怎么確定這個進程是 Go 進程，又怎么知道它的具體版本信息的呢，源代碼如下：

func isGo(pr ps.Process) (path, version string, agent, ok bool, err error) { 
 ... 
 path, _ = pr.Path() 
 if err != nil { 
  return 
 } 
 var versionInfo goversion.Version 
 versionInfo, err = goversion.ReadExe(path) 
 if err != nil { 
  return 
 } 
 ok = true 
 version = versionInfo.Release 
 pidfile, err := internal.PIDFile(pr.Pid()) 
 if err == nil { 
  _, err := os.Stat(pidfile) 
  agent = err == nil 
 } 
 return path, version, agent, ok, nil 
} 

我們可以看到該方法的主要作用是根據掃描 /proc 目錄所得到的二進制文件地址中查找相關的標識，用于判斷其是否 Go 程序，如果是 Go 程序，那么它將會返回該進程的 pid、二進制文件的名稱以及二進制文件的完整存儲路徑，判斷的標識如下：

if name == "runtime.main" || name == "main.main" { 
        isGo = true 
    } 
    if name == "runtime.buildVersion" { 
        isGo = true 
    } 

而關于所編譯的 Go 語言的版本，Go 編譯器會在二進制文件中打入 runtime.buildVersion標識，這個標識能夠快速我們快速識別它的編譯信息，而 gops 也正正是利用了這一點。

我們可以利用 gdb 來進行查看 Go 所編譯的二進制文件的版本信息，如下：

$ export GOFLAGS="-ldflags=-compressdwarf=false" && go build . 
 
$ gdb awesomeProject  
... 
(gdb) p 'runtime.buildVersion' 
$1 = 0x131bbb0 "go1.14" 

在上述輸出中，我們先對示例項目進行了編譯，然后利用 gdb 中查看了 runtime.buildVersion 變量，最終可得知編譯這個 Go 程序的版本是 Go1.14。

但在編譯時，有一點需要注意，就是我們在編譯時指定了 export GOFLAGS="-ldflags=-compressdwarf=false" 參數。

如果不進行指定的話，就會出現 Reading symbols from awesomeProject...(no debugging symbols found)...done. 的相關報錯，會將會影響部分功能使用。

這是因為在 Go1.11 版本開始，進行了調試信息的壓縮，目的是為了減小所編譯的二進制文件大小，但 Mac 上的 gdb 無法理解壓縮的 DWARF，因此會產生問題。

需要進行指定在調試時不進行 DWARF 的壓縮，便于 Mac 上的 gdb 使用。

需要注意的一點

假設我們在一些特殊場景下希望對 Go 所編譯的二進制文件進行壓縮，那么在最后我們常常會使用到 upx 工具來減少其整體大小，命令如下：

$ upx awesomeProject 

這時候我們再重新運行所編譯的 awesomeProject 文件，這時候需要思考的是，gops 能不能識別到它是一個 Go 程序呢?

答案是不行的，經過 upx 壓縮后的二進制文件將無法被識別為 Go 程序，并且在我所使用的 gops v0.3.7版本中，由于這類加殼進程的存在，執行 gops 命令直接出現了空指針調用的恐慌(panic)，顯然，這是一個 BUG，大家在實際環境中需要多加留意，如果要使用 gops 則盡量不要使用 upx 進行壓縮。

總結

在本文中我們針對 Google 官方出品的 gops 進行了基本使用和原理性的部分剖析。

如果你仔細研讀了，就會發現其實 gops 幾乎包含了大部分 Go 剖析工具的功能，是名副其實的進程診斷工具。

gops 集成了大量 Go 業界中常用的分析鏈，在排查問題上也會非常的方便，不需要一個個單獨找特定工具在哪里，只需要使用 gops 即可，而更深層次的使用可以根據實際情況進行更一步的了解。

參考資料

[1]gops: https://github.com/google/gops

[2]runtime.MemStats: https://golang.org/pkg/runtime/#MemStats