Prometheus Metrics 設計的最佳實踐和應用實體，看這篇夠了！

Prometheus 是一個開源的監控解決方案，部署簡單易使用，難點在于如何設計符合特定需求的 Metrics 去全面高效地反映系統實時狀態，以助力故障問題的發現與定位，本文即基于最佳實踐的 Metrics 設計方法，結合具體的場景實體——TKE 的網路組件 IPAMD 的內部監控，以個人實踐經驗談一談如何設計和實作適合的、能夠更好反映系統實時狀態的監控指標（Metrics），該篇內容適于 Prometheus 或相關監控系統的初學者(可無任何基礎了解)，以及近期有 Prometheus 監控方案搭建和維護需求的系統開發管理者，通過這篇文章，可以加深對 Prometheus Metrics 的理解，并能針對實際的監控場景提出更好的指標（Metrics）設計，

1 引言

Prometheus 是一個開源的監控解決方案，它能夠提供監控指標資料的采集、存盤、查詢以及監控告警等功能，作為云原生基金會(CNCF)的畢業專案，Prometheus 已經在云原生領域得到了大范圍的應用，并逐漸成為了業界最流行的監控解決方案之一，

Prometheus 的部署和使用可以說是簡單易上手，但是如何針對實際的問題和需求設計適宜的 Metrics 卻并不是那么直接可行，反而需要優先解決暴露出來的諸多不確定問題，比如何時選用 Vector，如何設計適宜的 buckets，Summary 和 Histogram 指標型別的取舍等，然而，要想有效助力故障及問題的發現與定位，必須要有一個合理有效的 Metrics 去全面高效地反映系統實時狀態，

本文將介紹基于最佳實踐的 Metrics 設計方法，并結合具體的場景實體——TKE 的網路組件 IPAMD 的內部監控，以個人實踐經驗談一談如何設計和實作適合的、能夠更好反映系統實時狀態的監控指標(Metrics)，

本文之后的第 2 節將對 Prometheus 的 Metrics 做簡單的介紹，對此已有了解的讀者可跳過，之后第 3 節將介紹 Metrics 設計的最佳實踐，第 4 節將結合具體的實體應用相關設計方法，第 5 節將介紹 Golang 上指標收集的實作方案，

2 Prometheus Metrics Type 簡介

Prometheus Metrics 是整個監控系統的核心，所有的監控指標資料都由其記錄，Prometheus 中，所有 Metrics 皆為時序資料，并以名字作區分，即每個指標收集到的樣本資料包含至少三個維度的資訊：名字、時刻和數值，

而 Prometheus Metrics 有四種基本的 type：

• Counter: 只增不減的單變數
• Gauge：可增可減的單變數
• Histogram：多桶統計的多變數
• Summary：聚合統計的多變數

此外，Prometheus Metrics 中有一種將樣本資料以標簽（Label）為維度作切分的資料型別，稱為向量(Vector)，四種基本型別也都有其 Vector 型別：

• CounterVec
• GaugeVec
• HistogramVec
• SummaryVec

Vector 相當于一組同名同型別的 Metrics，以 Label 做區分，Label 可以有多個，Prometheus 實際會為每個 Label 組合創建一個 Metric，Vector 型別記錄資料時需先打 Label 才能呼叫 Metrics 的方法記錄資料，

如對于 HTTP 請求延遲這一指標，由于 HTTP 請求可在多個地域的服務器處理，且具有不同的方法，于是，可定義名為 http_request_latency_seconds 的 SummaryVec，標簽有region和method，以此表示不同地域服務器的不同請求方法的請求延遲，

以下將對每個型別做詳細的介紹，

2.1 Counter

• 定義：是單調遞增的計數器，重啟時重置為0，其余時候只能增加，

• 方法：

  type Counter interface {  Metric  Collector  // 自增1  Inc()  // 把給定值加入到計數器中. 若值小于 0 會 panic  Add(float64)}
  

• 常測量物件：

• • 請求的數量
  • 任務完成的數量
  • 函式呼叫次數
  • 錯誤發生次數
  • ...

2.2 Gauge

• 定義：表示一個可增可減的數字變數，初值為0

• 方法：

  type Gauge interface {  Metric  Collector  Set(float64)    // 直接設定成給定值  Inc()   // 自增1  Dec()   // 自減1  Add(float64)     // 增加給定值，可為負  Sub(float64)    // 減少給定值，可為負  // SetToCurrentTime 將 Gauge 設定成當前的 Unix 時間戳  SetToCurrentTime()}
  

• 常測量物件：

• • 溫度
  • 記憶體用量
  • 并發請求數
  • ...

2.3 Histogram

• 定義：Histogram 會對觀測資料取樣，然后將觀測資料放入有數值上界的桶中，并記錄各桶中資料的個數，所有資料的個數和資料數值總和，

• 方法：

  type Histogram interface {  Metric  Collector  // Observe 將一個觀測到的樣本資料加入 Histogram 中，并更新相關資訊  Observe(float64)}
  

• 常測量物件：

• • 請求時延
  • 回復長度
  • ...各種有樣本資料

• 具體實作：Histogram 會根據觀測的樣本生成如下資料：

  inf 表無窮值，a1,a2,...是單調遞增的數值序列，

• • [basename]_count: 資料的個數，型別為 counter
  • [basename]_sum: 資料的加和，型別為 counter
  • [basename]_bucket{le=a1}: 處于[-inf,a1]的數值個數
  • [basename]_bucket{le=a2}: 處于[-inf,a2]的數值個數
  • ...
  • [basename]_bucket{le=<+inf>}：處于[-inf,+inf]的數值個數，prometheus默認額外生成，無需用戶定義

• Histogram 可以計算樣本資料的百分位數，其計算原理為：通過找特定的百分位數值在哪個桶中，然后再通過插值得到結果，比如目前有兩個桶，分別存盤了[-inf, 1]和[-inf, 2]的資料，然后現在有20%的資料在[-inf, 1]的桶，100%的資料在[-inf, 2]的桶，那么，50%分位數就應該在[1, 2]的區間中，且處于(50%-20%) / (100%-20%) = 30% / 80% = 37.5% 的位置處，Prometheus計算時假設區間中資料是均勻分布，因此直接通過線性插值可以得到 (2-1)*3/8+1 = 1.375.

2.4 Summary

• 定義：Summary 與 Histogram 類似，會對觀測資料進行取樣，得到資料的個數和總和，此外，還會取一個滑動視窗，計算視窗內樣本資料的分位數，

• 方法：

  type Summary interface {  Metric  Collector  // Observe 將一個觀測到的樣本資料加入 Summary 中，并更新相關資訊  Observe(float64)}
  

• 常測量物件：

• • 請求時延
  • 回復長度
  • ...各種有樣本資料

• 具體實作：Summary 完全是在client端聚合資料，每次呼叫 obeserve 會計算出如下資料：

• • [basename]_count: 資料的個數，型別為 counter
  • [basename]_sum: 資料的加和，型別為 counter
  • [basename]{quantile=0.5}: 滑動視窗內 50% 分位數值
  • [basename]{quantile=0.9}: 滑動視窗內 90% 分位數值
  • [basename]{quantile=0.99}: 滑動視窗內 99% 分位數值
  • ...

實際分位數值可根據需求制定，且是對每一個 Label 組合做聚合，

2.5 Histogram 和 Summary 簡單對比

可以看出，Histogram 和 Summary 型別測量的物件是比較接近的，但根據其實作方式和其本身的特點，在性能耗費、適用場景等方面具有一定差別，本文總結如下：

3 Metrics 設計的最佳實踐

3.1 如何確定需要測量的物件

在具體設計 Metrics 之前，首先需要明確需要測量的物件，需要測量的物件應該依據具體的問題背景、需求和需監控的系統本身來確定，

思路1：從需求出發

Google 針對大量分布式監控的經驗總結出四個監控的黃金指標，這四個指標對于一般性的監控測量物件都具有較好的參考意義，這四個指標分別為：

• 延遲：服務請求的時間，
• 通訊量：監控當前系統的流量，用于衡量服務的容量需求，
• 錯誤：監控當前系統所有發生的錯誤請求，衡量當前系統錯誤發生的速率，
• 飽和度：衡量當前服務的飽和度，主要強調最能影響服務狀態的受限制的資源，例如，如果系統主要受記憶體影響，那就主要關注系統的記憶體狀態，

而筆者認為，以上四種指標，其實是為了滿足四個監控需求：

• 反映用戶體驗，衡量系統核心性能，如：在線系統的時延，作業計算系統的作業完成時間等，
• 反映系統的服務量，如：請求數，發出和接收的網路包大小等，
• 幫助發現和定位故障和問題，如：錯誤計數、呼叫失敗率等，
• 反映系統的飽和度和負載，如：系統占用的記憶體、作業佇列的長度等，

除了以上常規需求，還可根據具體的問題場景，為了排除和發現以前出現過或可能出現的問題，確定相應的測量物件，比如，系統需要經常呼叫的一個庫的介面可能耗時較長，或偶有失敗，可制定 Metrics 以測量這個介面的時延和失敗數，

思路2：從需監控的系統出發

另一方面，為了滿足相應的需求，不同系統需要觀測的測量物件也是不同的，在 官方檔案 的最佳實踐中，將需要監控的應用分為了三類：

• 線上服務系統（Online-serving systems）：需對請求做即時的回應，請求發起者會等待回應，如 web 服務器，
• 線下計算系統（Offline processing）：請求發起者不會等待回應，請求的作業通常會耗時較長，如批處理計算框架 Spark 等，
• 批處理作業（Batch jobs）：這類應用通常為一次性的，不會一直運行，運行完成后便會結束運行，如資料分析的 MapReduce 作業，

對于每一類應用其通常情況下測量的物件是不太一樣的，其總結如下：

• 線上服務系統：主要有請求、出錯的數量，請求的時延等，
• 線下計算系統：最后開始處理作業的時間，目前正在處理作業的數量，發出了多少 items， 作業佇列的長度等，
• 批處理作業：最后成功執行的時刻，每個主要 stage 的執行時間，總的耗時，處理的記錄數量等，

除了系統本身，有時還需監控子系統：

• 使用的庫（Libraries）: 呼叫次數，成功數，出錯數，呼叫的時延，
• 日志（Logging）：計數每一條寫入的日志，從而可找到每條日志發生的頻率和時間，
• Failures: 錯誤計數，
• 執行緒池：排隊的請求數，正在使用的執行緒數，總執行緒數，耗時，正在處理的任務數等，
• 快取：請求數，命中數，總時延等，
• ...

最后的測量物件的確定應結合以上兩點思路確定，

3.2 如何選用 Vector

選用 Vec 的原則：

• 資料型別類似但資源型別、收集地點等不同
• Vec 內資料單位統一

例子：

• 不同資源物件的請求延遲
• 不同地域服務器的請求延遲
• 不同 http 請求錯誤的計數
• ...

此外，官方檔案 中建議，對于一個資源物件的不同操作，如 Read/Write、Send/Receive， 應采用不同的 Metric 去記錄，而不要放在一個 Metric 里，原因是監控時一般不會對這兩者做聚合，而是分別去觀測，

不過對于 request 的測量，通常是以 Label 做區分不同的 action，

3.3 如何確定 Label

根據3.2，常見 Label 的選擇有：

• resource
• region
• type
• ...

確定 Label 的一個重要原則是：同一維度 Label 的資料是可平均和可加和的，也即單位要統一，如風扇的風速和電壓就不能放在一個 Label 里，

此外，不建議下列做法：

my_metric{label=a} 1my_metric{label=b} 6my_metric{label=total} 7

即在 Label 中同時統計了分和總的資料，建議采用 PromQL 在服務器端聚合得到總和的結果，或者用另外的 Metric 去測量總的資料，

3.4 如何命名 Metrics 和 Label

好的命名能夠見名知義，因此命名也是良好設計的一環，

Metric 的命名：

• 需要符合 pattern: [a-zA-Z:][a-zA-Z0-9:]*

• 應該包含一個單詞作為前綴，表明這個 Metric 所屬的域，如：

• • prometheus_notifications_total
  • process_cpu_seconds_total
  • ipamd_request_latency

• 應該包含一個單位的單位作為后綴，表明這個 Metric 的單位，如：

• • http_request_duration_seconds
  • node_memory_usage_bytes
  • http_requests_total (for a unit-less accumulating count)

• 邏輯上與被測量的變數含義相同，

• 盡量使用基本單位，如 seconds，bytes，而不是 Milliseconds, megabytes，

Label 的命名：

• 依據選擇的維度命名，如：

• • region: shenzhen/guangzhou/beijing
  • owner: user1/user2/user3
  • stage: extract/transform/load

3.5 如何設計適宜的 Buckets

根據前述 histogram 的統計原理可知，適宜的 buckets 能使 histogram 的百分位數計算更加準確，

理想情況下，桶會使得資料分布呈階梯狀，即各桶區間內資料個數大致相同，如圖1所示，是本人在實際場景下配置的buckets 資料直方圖，y 軸為 buckets 內的資料個數，x 軸是各 buckets，可以看出其近似成階梯狀，這種情況下，當前桶個數下對資料的解析度最大，各百分位數計算的準確率較高，

圖1 較為理想的桶資料分布

而根據筆者實踐經驗，為了達成以上目標，buckets 的設計可遵從如下經驗：

• 需要知道資料的大致分布，若事先不知道可先用默認桶 （{.005, .01, .025, .05, .1, .25, .5, 1, 2.5, 5, 10}）或 2 倍數桶（{1,2,4,8...}）觀察資料分布再調整 buckets，
• 資料分布較密處桶間隔制定的較窄一些，分布稀疏處可制定的較寬一些，
• 對于多數時延資料，一般具有長尾的特性，較適宜用指數形式的桶（ExponentialBuckets），
• 初始桶上界一般覆寫10%左右的資料，若不關注頭部資料也可以讓初始上界更大一些，
• 若為了更準確計算特定百分位數，如90%，可在90%的資料處加密分布桶，即減少桶的間隔，

4 實體：TKE-ENI-IPAMD Metrics 設計與規劃

4.1 組件簡介

該組件用于支持騰訊云 TKE 的策略路由網路方案，在這一網路方案中，每個 pod 的 IP 都是 VPC 子網的一個IP，且系結到了所在節點的彈性網卡上，通過策略路由連通網路，并且使得容器可以支持騰訊云的 VPC 的所有特性，

其中，在 2.0.0 版本以前，tke-eni-ipamd 組件是一個 IP 分配管理的 GRPC Server，其主要職責為:

• cni IP 真正分配/洗掉的 GRPC Server，分配/釋放 IP 會呼叫騰訊云彈性網卡介面執行相應的 IP 系結/解綁操作
• Node 控制器（用于給 Node 系結/解綁彈性網卡）
• Stateulfset 控制器（用于給 Statefulset 預留 IP 資源）

其作業原理和流程如圖 2 所示：

圖2 tke-eni-ipamd(v2.0.0-) 作業原理和流程

4.2 IPAMD 的使用場景和我們的要求

背景：

• ip 分配/釋放對時延比較敏感，為了方便確定 ip 分配/釋放程序中性能瓶頸是由我們自身代碼造成的還是底層模塊造成的（如 ipamd 呼叫的 vpc 介面等），同時也方便對我們的代碼和推進底層模塊的性能優化，
• ipamd 運行程序中可能會出現故障等問題，為了及時發現故障，定位問題，也需要有內部監控，

需求：

• 需要能夠統計 ip 分配和釋放各個階段的時延，以確定性能瓶頸
• 需要知道當前的并發請求數，以確定 IPAMD 負載
• vpc 介面 ip分配/釋放，彈性網卡創建/系結/解綁/釋放耗時比較長，并且經常有失敗情況，需要能夠統計這些介面的時延和呼叫成功率，以定位性能瓶頸，
• node controller，statefulset controller 進行 sync 階段會有一系列流程，希望能清楚主要流程耗時，方便定位瓶頸
• 彈性網卡的創建/洗掉等程序中容易產生臟資料，需要能夠統計臟資料的個數，以發現臟資料問題，
• 需要有較強的實時性，能夠清楚的看到最近（~分鐘級別）系統的運行狀態

我們的場景：

• ipamd 是部署在每個用戶集群中的一個組件
• 每個用戶集群內有 prometheus server 做聚合，然后每個 region 也有 server 去拉取資料

4.3 總體設計

因此，需要以下幾類 Metric：

• ip alloc/free 各階段時延
• 基本運行資訊：請求并發數、記憶體用量、goroutine 數，執行緒數
• vpc 介面時延
• vpc 介面呼叫成功率
• controller sync 時延
• 臟資料計數

4.4 Histogram vs. Summary

時延可選擇 Histogram 或 Summary 進行測量，如何選擇？

基于 2.5 節的兩者對比，有如下分析：

Summary:

• 優點：

• 1. 能夠非常準確的計算百分位數
  2. 不需要提前知道資料的分布

• 缺點：

• 1. 靈活性不足，實時性需要通過 maxAge 來保證，寫死了后靈活性就不太夠（比如想知道更長維度的百分位數）
  2. 在 client 端已經做了聚合，即在各個用戶集群的 ipamd 中已經聚合了，我們如果需要觀察全部 user 下的百分位數資料是不行的（只能看均值）
  3. 用戶集群的 ipamd 的呼叫頻率可能很低（如小集群或者穩定集群），這種情況下 client 端聚合計算百分位數值失去意義（資料太少不穩定），如果把 maxAge 增大則失去實時性

Histogram:

• 優點：

• 1. 兼具靈活性和實時性
  2. 可以靈活的聚合資料，觀察各個尺度和維度下的資料

• 缺點：

• 1. 需要提前知道資料的大致分布，并以此設計出合適而準確的桶序列
  2. 難以通過 Label 串聯多種 Metrics，因為各個 Metrics 的資料分布可能差異較大，如果都只用一種桶序列的話會導致百分位數計算差異較大

Summary 的缺點過于致命，難以回避，Histogram 的缺點可以通過增加作業量（即通過測驗環境中的實驗來確定各 Metrics 的大致分布）和增加 Metrics（不用 Label 區分）來較好解決，

所以傾向于使用 Histogram，

4.5 Metrics 規劃示例

詳細的 Metrics 規劃內容較多，這里選取了一些代表性的樣例，列舉如下：

注1：DefBuckets指默認桶 （{.005, .01, .025, .05, .1, .25, .5, 1, 2.5, 5, 10}），

注2：以上 buckets 持續微調中，

5 指標收集的 Golang 實作方案

5.1 總體實作思路

• 利用 prometheus 的 golang client 實作自定義的 exporter（包括自定義的 Metrics ），并嵌入到 ipamd 代碼中，以收集資料
• 所有的 Metrics 作為 Metrics 包的外部變數可供其他包使用，呼叫測量方法
• 自定義 exporter 參考 prometheus client golang example
• 將收集到的資料通過 http server 暴露出來

5.2 Metrics 收集方案

方案1：非侵入式裝飾器模式

樣例: kubelet/kuberuntime/instrumented_services.go

type instrumentedRuntimeService struct {    service internalapi.RuntimeService}func recordOperation(operation string, start time.Time) {    metrics.RuntimeOperations.WithLabelValues(operation).Inc()    metrics.DeprecatedRuntimeOperations.WithLabelValues(operation).Inc()    metrics.RuntimeOperationsDuration.WithLabelValues(operation).Observe(metrics.SinceInSeconds(start))    metrics.DeprecatedRuntimeOperationsLatency.WithLabelValues(operation).Observe(metrics.SinceInMicroseconds(start))}func (in instrumentedRuntimeService) Status() (*runtimeapi.RuntimeStatus, error) {    const operation = "status"    defer recordOperation(operation, time.Now())    out, err := in.service.Status()    recordError(operation, err)    return out, err}

優點：

• 上層呼叫函式處幾乎不用修改，只需修改呼叫的實體
• 抽象較好，非侵入式設計，代碼耦合度低

缺點：

• 需單獨封裝每個呼叫函式，復用度低
• 無法封裝內部函式，只能適用于測量對外服務函式的資料

方案2：defer 函式收集

樣例：

func test() (retErr error){    defer func(){        metrics.LatencySeconds.Observe(...)    }()    ...    func body    ...}

優點：

• 上層呼叫函式處完全不用修改
• 適用于所有函式的測量

缺點：

• 有點濫用 defer
• 侵入式設計，具有一定的耦合度

5.3 目前 IPAMD 的指標收集實作方案

• 時延統計：通過 golang 的 time 模塊計時，在函式中嵌入 time.Now 和并在其后 defer time.Since 來統計，
• 呼叫成功率統計：呼叫次數在介面函式里直接用 counter 進行統計，失敗次數在defer里獲取命名回傳值統計，最后在 prometheus server 端聚合的時候通過 PromQL 利用這兩個資料計算出呼叫成功率，
• 并發請求數的統計：在最外層的 AddPodIP 和 DelPodIP 中，在函式中和 defer func 中分別呼叫Inc和Dec，

6 總結

本文介紹了 Prometheus Metrics 及最佳實踐的 Metrics 設計和收集實作方法，并在具體的監控場景—— TKE 的網路組件 IPAMD 的內部監控中應用了相關方法，

具體而言，本文基于最佳實踐，回答了 Prometheus Metrics 設計程序中的若干問題：

• 如何確定需要測量的物件：依據需求(反映用戶體驗、服務量、飽和度和幫助發現問題等)和需監控的具體系統，
• 何時選用 Vec：資料型別類似但資源型別、收集地點等不同，資料單位統一，
• 如何確定 Label：可平均和可加和的，單位要統一；總和資料另外計，
• 如何命名 Metrics 和 Label：見名知義，應包含監控的系統名/模塊名，指標名，單位等資訊，
• 如何設計適宜的 Buckets：依據資料分布制定，密集部分桶區間較窄，總體桶分布盡量接近階梯狀，
• 如何取舍 Histogram 和 Summary：Histogram 計算誤差大，但靈活性較強，適用客戶端監控、或組件在系統中較多、或不太關心精確的百分位數值的場景；Summary 計算精確，但靈活性較差，適用服務端監控、或組件在系統中唯一或只有個位數、或需要知道較準確的百分位數值(如性能優化場景)的場景，

此外，Metrics 設計并不是一蹴而就的，需依據具體的需求的變化進行反復迭代，比如需新增 Metrics 去發現定位可能出現的新問題和故障，再比如 Buckets 的設計也需要變化來適應測量資料分布發生的變化，從而獲得更精確的百分位數測量值，

參考資料

1. Prometheus 官方檔案 ：https://prometheus.io/docs/introduction/overview/Prometheus
2. Go client library：https://github.com/prometheus/client_golang

【騰訊云原生】云說新品、云研新術、云游新活、云賞資訊，掃碼關注同名公眾號，及時獲取更多干貨！！

標籤：其他

上一篇：Union（聯合體）

下一篇：maxwell與simplorer聯合仿真問題