最近一直在思考如何對線上服務做深度監控。基礎的服務可用性監控很簡單，定期Ping即可。但是怎樣才能監控伺服器的一些更加關鍵的資料呢?比如，每一個API Point的請求次數(QPS)，最大響應時間，平均響應時間等。最終我希望實現的效果是有一個Dashboard，我可以清楚地看到各種引數曲線，對伺服器的執行情況瞭然於胸。

繪製Dashboard不難，目前提供資料視覺化的工具很多，隨便選一個都能滿足需要。關鍵問題是，怎樣將整個流程打通?

伺服器該以怎樣的形式暴露出資料?

資料怎樣被收集和儲存起來?

儲存起來的資料怎樣提供給資料視覺化工具?

怎樣做到足夠靈活，可以視覺化自己感興趣的任意資料?

Prometheus

像QPS和響應時間這些資料，外部工具是沒辦法直接拿到的，必須要伺服器以某種方式將資料暴露出來。最常見的做法是寫日誌。比如Nginx，每一條請求對應一個日誌，日誌中有響應時間這個欄位。通過對日誌分析，我們就可以得到QPS，最大響應時間，平均響應時間等，再通過視覺化工具即可繪製我們想要的Dashboard。

日誌這個方法固然是可行的，但是還有更好的方法。這個方法就是時序資料庫(Time Series Database)。時序資料庫簡單來說就是儲存隨時間變化的資料的資料庫。什麼是隨時間變化的資料呢?舉個簡單的例子，比如，CPU使用率，典型的隨時間變化的量，這一秒是50%，下一秒也許就是80%了。或者是溫度，今天是20度，明天可能就是18度了。

Prometheus就是一個用Go編寫的時序資料庫，官網對其的優點介紹的很清楚，這裡就不再贅述了。總之，使用簡單，功能強大。

安裝

安裝直接去官網下載對應的安裝包即可。當然，如果你是Mac使用者的話，brew永遠不會讓你失望brew install prometheus。

格式

Prometheus獲取資料的策略是Pull而不是Push，也就是說，它會自己去抓取，而不用你來推送。抓取使用的是HTTP協議，在配置檔案中指定目標程式的埠，路徑及間隔時間即可。這也就意味著任何程式想要使用Prometheus儲存資料都很簡單，定義一個HTTP介面即可。

Prometheus的資料格式是簡單的文字格式，可以直接閱讀。其中，#號開頭的是註釋，除此之外，每一行一個數據項，資料名在前，值在後。{}中是標籤，一條資料可以有多個標籤。

配置

Prometheus使用YAML進行配置。global配置一些全域性資訊，scrape_configs配置具體想要抓取的目標。這段配置的含義是：啟動一個叫做go-test的任務，每隔五秒鐘，訪問localhost:8888/metrics獲取資料。

測試程式

我們來寫一個程式測試一下Prometheus的功能。雖然可以手動返回Prometheus需要的資料，但是使用開發好的客戶端會更加方便。

這裡我們使用Go語言，編寫一個簡單的伺服器和客戶端。客戶端會以一個穩定的速度請求伺服器的/test路徑，但是每兩分鐘會加大流量，持續30秒再回到之前的水平。伺服器95%的情況下會花費50ms進行響應，還有5%的情況下會花費100ms。

這裡我們定義了兩個指標，httpRequestCount記錄HTTP的請求數，httpRequestDuration記錄響應時間，他們都有一個endpoint標籤用於記錄請求路徑。這兩個指標分別是Counter型別和Summary型別，Prometheus定義了四種指標型別，基本涵蓋了各種用例場景，具體可以去看相關文件。簡單來說，Counter型別的資料表示一個只會向上增加的資料，比如請求數。而Summary型別的資料表示一個按區間分佈的資料，比如響應時間或者請求體大小。

1. /** @Author: CJ Ting* @Date: 2017-03-12 17:27:23* @Last Modified by: CJ Ting* @Last Modified time: 2017-03-12 23:49:55 */packagemainimport("log""math/rand""net/http""time""github.com/prometheus/client_golang/prometheus""github.com/prometheus/client_golang/prometheus/promhttp")varhttpRequestCount=prometheus.NewCounterVec(prometheus.CounterOpts{Name:"http_request_count",Help:"http request count",},[]string{"endpoint"},)varhttpRequestDuration=prometheus.NewSummaryVec(prometheus.SummaryOpts{Name:"http_request_duration",Help:"http request duration",},[]string{"endpoint"},)funcinit(){prometheus.MustRegister(httpRequestCount)prometheus.MustRegister(httpRequestDuration)}funcmain(){http.Handle("/metrics",promhttp.Handler())http.HandleFunc("/test",handler)gofunc(){http.ListenAndServe(":8888",nil)}()startClient()doneChan:=make(chanstruct{})<-doneChan}funchandler(whttp.ResponseWriter,r*http.Request){start:=time.Now()path:=r.URL.PathhttpRequestCount.WithLabelValues(path).Inc()n:=rand.Intn(100)ifn>=95{time.Sleep(100*time.Millisecond)}else{time.Sleep(50*time.Millisecond)}elapsed:=(float64)(time.Since(start)/time.Millisecond)httpRequestDuration.WithLabelValues(path).Observe(elapsed)}funcstartClient(){sleepTime:=1000gofunc(){ticker:=time.NewTicker(2*time.Minute)for{<-ticker.CsleepTime-ticker.CsleepTime=200<-time.After(30*time.Second)sleepTime=1000}}()fori:=0;i<100;i++{gofunc(){for{sendRequest()time.Sleep((time.Duration)(sleepTime)*time.Millisecond)}}()}}funcsendRequest(){resp,err:=http.Get("http://localhost:8888/test")iferr!=nil{log.Println(err)return}resp.Body.Close()}copy code

啟動Prometheusprometheus -config.file config.yml以後，再啟動我們的測試程式go run test.go。開啟Prometheus控制檯localhost:9090/targets就可以看到Prometheus正在抓取資料，一切正常。

控制檯

Prometheus的一個強大之處在於可以使用各種函式和操作符來查詢資料。在上面的測試程式中，每個資料都帶有endpoint這個標籤，表示請求的路徑。

開啟Prometheus的控制檯http://localhost:9090/graph，點選console標籤頁，輸入http_request_count{endpoint="/a"}就可以查詢路徑為/a的API Point到目前為止的總請求數。

如果想看QPS的話，可以使用自帶的函式rate，rate(http_request_count[10s])表示以10s作為時間單元來統計QPS。

Prometheus的控制檯自帶一個簡單的繪圖系統，點選graph標籤頁，輸入表示式就可以看到圖表。

例如輸入rate(http_request_count{endpoint="/test"}[10s])就可以看到我們測試程式中/test路徑的QPS，從圖中可以明顯發現，每隔一段時間就會有一個波峰流量。

httpRequestDuration是一個Summary型別的指標，比簡單的Counter要複雜，會生成三個資料項。分別是http_request_duration_sum，表示響應時間加在一起的總和。

http_request_duration_count，表示響應時間的總個數以及http_request_duration，表示響應時間的分佈情況，這個資料項會使用quantile標籤對響應時間進行分組。

如下圖所示，quantile=0.5值為50，表示50%的請求響應時間都在50ms以下。quantile=0.9的值為54，表示90%的請求響應時間都在54ms以下。但是，quantile=0.99的值為103，表示99%的請求響應時間在103ms以下。這就說明了一個問題，那就是極個別的請求耗費了大量時間。

通過使用表示式http_request_duration_sum / http_request_duration_count，我們可以得到平均響應時間，如下圖。

當然，這個圖的作用不大(平均數往往反映不了什麼問題)，不像上圖那樣，我們無法看出有部分請求花費了大量時間。

以上只是對資料項的最簡單利用，Prometheus自帶了很多函式和操作符，可以方便地對資料進行處理，具體可以參考官方文件。

Grafana

Prometheus自帶的圖表是非常基礎的，只能用來臨時檢視一下資料。如果要構建強大的Dashboard，還是需要更加專業的工具才行。這個工具就是Grafana。

安裝

同樣是去官網下載相應的安裝包。Mac使用者可以再次感受到brew的優越性。brew install grafana。

啟動

直接用預設配置就挺好的。在Mac上，啟動指令如下。

Grafana預設監聽在3000埠上，預設使用者名稱和密碼都是admin。

設定

輸入使用者名稱和密碼以後，進入Grafana頁面。第一件事是要設定資料來源(Data Source)，即Grafana從什麼地方獲取資料，選擇Prometheus即可。

資料來源設定好以後，接下來就是建立Dashboard了。Dashboard裡面可以放置很多“元件”。比如圖表，狀態值，表格，文字等。

這裡我們選擇Graph圖表，Grafana會建立一個預設的空圖表。

點選圖表標題，選擇Edit來編輯圖表引數。最重要的引數就是Metrics標籤裡的Query欄位，這個欄位定義了我們的圖表到底要展示什麼資料。

輸入rate(http_request_count{endpoint="/test"}[10s])，就可以看到/test路徑的QPS曲線了。

同理，在Query中輸入http_request_duration就可以得到響應時間曲線。通過使用Prometheus提供的操作符和函式，我們可以對資料進行我們想要的任意視覺化，十分靈活。

在這兩個工具的配合使用下，對伺服器資訊的監控變得非常簡單。首先，伺服器定義一個HTTP介面，暴露出想要監控的資料，然後使用Prometheus收集並存儲這些資料，最後在Grafana中繪製這些資料。一個完整的監控方案就誕生了。

當然，在實際系統中，還缺少了一個環節，那就是報警。監控發現問題以後，需要馬上報警通知相關的維護人員。這是另外一個話題了，以後再介紹。