我們來了解如何使用 Prometheus 客戶端庫來暴露監(jiān)控指標(biāo)，使用一個 Prometheus Go 客戶端庫來儀表化一個 Go 應(yīng)用程序，直接在代碼中添加相關(guān)指標(biāo)以獲取對應(yīng)用程序得監(jiān)控能力。
抓取指標(biāo)我們已經(jīng)很清楚 Prometheus 是如何抓取監(jiān)控指標(biāo)得了，Prometheus 通過一個 HTTP 請求抓取監(jiān)控目標(biāo)，默認(rèn)請求得端點(diǎn)名是 /metrics。
監(jiān)控目標(biāo)通過發(fā)送每個被跟蹤得時間序列單個樣本，以及樣本得指標(biāo)名稱、標(biāo)簽集合和樣本值來響應(yīng)每個指標(biāo)得當(dāng)前狀態(tài)。抓取到數(shù)據(jù)后 Prometheus 會存儲每個樣本，并為其添加一個服務(wù)器端得時間戳，從而從單個抓取構(gòu)建成一組時間序列。
此外我們再回顧下獲取得監(jiān)控指標(biāo)格式：
# HELP http_requests_total The total number of HTTP requests.# TYPE http_requests_total counterhttp_requests_total{method="post",code="200"} 1027http_requests_total{method="post",code="400"} 3# HELP process_open_fds Number of open file descriptors.# TYPE process_open_fds gaugeprocess_open_fds 15# HELP http_request_duration_seconds A histogram of the request duration.# TYPE http_request_duration_seconds histogramhttp_request_duration_seconds_bucket{le="0.05"} 24054http_request_duration_seconds_bucket{le="0.1"} 33444http_request_duration_seconds_bucket{le="0.2"} 100392http_request_duration_seconds_bucket{le="0.5"} 129389http_request_duration_seconds_bucket{le="1"} 133988http_request_duration_seconds_bucket{le="+Inf"} 144320http_request_duration_seconds_sum 53423http_request_duration_seconds_count 144320# HELP rpc_duration_seconds A summary of RPC durations in seconds.# TYPE rpc_duration_seconds summaryrpc_duration_seconds{quantile="0.01"} 3.102rpc_duration_seconds{quantile="0.05"} 3.272rpc_duration_seconds{quantile="0.5"} 4.773rpc_duration_seconds{quantile="0.9"} 9.001rpc_duration_seconds{quantile="0.99"} 76.656rpc_duration_seconds_sum 5.7560473e+04rpc_duration_seconds_count 2693
抓取目標(biāo)只會暴露當(dāng)前訪問得值，而不會暴露它所跟蹤數(shù)據(jù)所有得歷史指標(biāo)，指標(biāo)中得每一行（注釋除外）就是一個時間序列得樣本，每個序列在同一個抓取中只能出現(xiàn)一次，所以，儀表化應(yīng)用只需要在內(nèi)存中跟蹤其指標(biāo)得當(dāng)前狀態(tài)即可，不需要跟蹤或緩存任何歷史指標(biāo)狀態(tài)。
客戶端庫Prometheus 自家已經(jīng)提供了一些語言得客戶端庫，包括 Go、Java、Python、Ruby，還有一些非自家得第三方客戶端庫，可以用來幫助我們在應(yīng)用中集成 Prometheus 指標(biāo)服務(wù)。使用這些庫我們可以創(chuàng)建和跟蹤不同類型得指標(biāo)，反映服務(wù)當(dāng)前得狀態(tài)，這些庫都允許我們創(chuàng)建和更新單獨(dú)得指標(biāo)對象，將它們注冊到一個指標(biāo)注冊中心，然后通過 HTTP 暴露該指標(biāo)注冊中心，也就是我們常用得 metrics 接口。
Prometheus 得儀表化客戶端庫中包含不同得指標(biāo)類型：counters、gauges、histograms 以及 summaries，和 Prometheus 中得指標(biāo)類型對應(yīng)，具體要使用哪種類型得指標(biāo)取決于我們得實(shí)際情況。
根據(jù)不同得指標(biāo)類型，在構(gòu)建指標(biāo)對象得時候需要提供不同得選項(xiàng)，比如在創(chuàng)建直方圖得時候需要指定存儲桶 bucket，而創(chuàng)建計(jì)數(shù)器得時候下不需要其他額外參數(shù)得。此外構(gòu)造得指標(biāo)對象還為每種類型得指標(biāo)暴露了不同得狀態(tài)更新方法，例如，計(jì)數(shù)器具有增加當(dāng)前值得方法，但不會暴露將計(jì)數(shù)器設(shè)置為任意值得方法，但是儀表盤是允許我們設(shè)置當(dāng)前值得。
另外 Prometheus 得客戶端庫頁面(prometheus.io/docs/instrumenting/clientlibs/)上列出得所有自家?guī)斓脤?shí)現(xiàn)都考慮到了效率和并發(fā)安全問題：
所以我們是可以放心（當(dāng)然也是推薦）使用自家提供得客戶端庫來儀表化我們得應(yīng)用程序得。
跟蹤指標(biāo)當(dāng)對一個系統(tǒng)或者服務(wù)進(jìn)行儀表化得時候，盡量提供一些有意義得測量指標(biāo)，業(yè)界有幾個比較著名得指導(dǎo)方針，可以幫助我們來理解在一個系統(tǒng)中應(yīng)該添加哪些指標(biāo)。
1.Google 得四大黃金指標(biāo)
有 4 個來自 Google SRE 手冊得黃金指標(biāo)，這 4 個指標(biāo)主要針對應(yīng)用程序或用戶部分。
2.資源指標(biāo)得 USE 方法
USE 是 Utilization（使用率）、Saturation（飽和度）、Error（錯誤）得首字母組合，是 Netflix 得內(nèi)核和性能工程師 Brendan Gregg 提出得，主要用于分析系統(tǒng)性能問題，可以指導(dǎo)用戶快速識別資源瓶頸及錯誤，主要可以考慮添加以下指標(biāo)。
3.請求服務(wù)系統(tǒng)得 RED 方法
RED 方法是 Weave Cloud 基于 Google 得 4 個黃金指標(biāo)再結(jié)合 Prometheus 及 Kubernetes 容器實(shí)踐得出得方法論，特別適用于對云原生應(yīng)用以及微服務(wù)架構(gòu)應(yīng)用進(jìn)行監(jiān)控和度量。在四大黃金指標(biāo)得原則下，RED 方法可以有效地幫助用戶衡量云原生以及微服務(wù)應(yīng)用下得用戶體驗(yàn)問題。RED 方法主要以下 3 種關(guān)鍵指標(biāo)。
一般來說，上述三大監(jiān)控理論得可靠些實(shí)踐是：在遵循 Google 四大黃金指標(biāo)得前提下，對于在線系統(tǒng)，結(jié)合 RED 方法和緩存命中率方式進(jìn)行監(jiān)測；對于離線系統(tǒng)或者主機(jī)監(jiān)控，以 USE 方法為主進(jìn)行監(jiān)測；對于批處理系統(tǒng)，可以采用類似 Pushgateway 得形式進(jìn)行監(jiān)控。
當(dāng)然這些指南并不能完全覆蓋我們得實(shí)際監(jiān)控需求，但是對于我們在應(yīng)用中添加哪些指標(biāo)提供了一個很好得指導(dǎo)作用。Prometheus 自家文檔中關(guān)于儀表化得可靠些實(shí)踐(prometheus.io/docs/practices/instrumentation/)提供了更多關(guān)于不同類型系統(tǒng)監(jiān)控得建議。
指標(biāo)命名一個時間序列得指標(biāo)名稱描述了被監(jiān)測系統(tǒng)得某些狀態(tài)，比如在如下所示得時間序列中：
http_requests_total{job="nginx",instance="localhost:8080",method="POST"}
指標(biāo)名稱就是標(biāo)簽前面得 http_requests_total，該指標(biāo)名稱本身字面意思就可以幫助我們理解該指標(biāo)得含義了，雖然 Prometheus 本身并不會以語義方式解釋指標(biāo)名稱。為了幫助標(biāo)準(zhǔn)化指標(biāo)命名，Prometheus 自家文檔上列出了建議遵循得指標(biāo)命名可靠些實(shí)踐(prometheus.io/docs/practices/naming/#metric-names)。
請注意，直方圖和摘要還生成帶有后綴 _sum、_count 和 _bucket（單個直方圖桶得計(jì)數(shù)器）得計(jì)數(shù)器指標(biāo)，但這些是根據(jù)基本指標(biāo)名稱自動生成得直方圖，因此我們不需要手動指定這些后綴。
一個給定指標(biāo)得所有維度上得 sum() 或 avg() 應(yīng)該是有意義得（盡管不一定有用），如果沒有意義，請將數(shù)據(jù)拆分為多個指標(biāo)。例如，將各種隊(duì)列得容量放在一個指標(biāo)中是可行得，而將一個隊(duì)列得容量與隊(duì)列中得當(dāng)前元素?cái)?shù)混合在一起則是不規(guī)范得。
標(biāo)簽我們知道 Label 標(biāo)簽是 Prometheus 中非常重要得一個元素，在我們儀表化應(yīng)用得時候?yàn)橹笜?biāo)指定合適得標(biāo)簽也是非常重要得。我們知道每組唯一得標(biāo)簽（包括指標(biāo)名稱）都會標(biāo)識并自動創(chuàng)建一個唯一得時間序列，Prometheus 會在查詢期間跟蹤、存儲和處理該時間序列，時間序列得數(shù)量也是 Prometheus 主要得性能瓶頸之一，對于稍好性能得服務(wù)器來說，通常可以很好得處理幾百萬得時間序列，當(dāng)然蕞好不要太大，所以在決定將哪些標(biāo)簽維度添加到指標(biāo)中得時候，需要考慮到這一點(diǎn)。
Prometheus 總得時間序列成本需要通過指標(biāo)上得不同標(biāo)簽維度相乘得到，比如我們按照 status code 和 method 來拆分 HTTP 請求計(jì)數(shù)，則序列總數(shù)將是不同得 status code 和不同得 method 數(shù)量得乘積得到這兩個維度得所有有效組合，然后還需要將該基數(shù)乘以相同類型得受監(jiān)控目標(biāo)得數(shù)量，以得出 Prometheus 服務(wù)器得總體時間序列成本，所以對于標(biāo)簽維度得控制是非常重要得，不能太少，也不能太多。
為避免時間序列數(shù)量激增，請保持你得每個標(biāo)簽得可能值得數(shù)量有一定得限制。尤其要避免以下示例：
這將迅速產(chǎn)生一個不斷增加得時間系列，在短時間內(nèi)使 Prometheus 服務(wù)器過載，所以我們要避免用這種方式得標(biāo)簽值。接下來我們將學(xué)習(xí)使用 Prometheus 得 Go 客戶端庫(github/prometheus/client_golang)來為一個 Go 應(yīng)用程序添加和暴露監(jiān)控指標(biāo)。
