Prometheus 四種metric型別

iqsing發表於2022-06-07
Prometheus型別

Prometheus的4種metrics（指標）型別：

  • Counter
  • Gauge
  • Histogram
  • Summary

四種指標型別的資料物件都是數字，如果要監控文字類的資訊只能通過指標名稱或者 label 來呈現，在 zabbix 一類的監控中指標型別本身支援 Log 和文字，當然在這裡我們不是要討論 Prometheus 的侷限性，而是要看一看 Prometheus 是如何把數字玩出花活的。 Counter 與 Gauge 比較好理解，我們簡單的過一下 然後主要關注 Histogram 和 Summary

Counter 與 Gauge

Counter

單調遞增的計數器。

例如 Prometheus自身 中 metrics 的 http 請求總數

image-20220606153419440

Gauge

儀表，也可以認為是一種計數器，不過支援加和減。

例如 node 中的負載資料

image-20220606153138417

Histogram 與 Summary

Histogram

直方圖常用於請求持續時間或者響應大小取樣，然後將結果記錄到儲存桶（bucket）,每個桶為累加資料。

通過三個metrics名稱來完整暴露一組Histogram

  • 桶累積計數器，<basename>_bucket{le="<upper inclusive bound>"}
  • 所有觀察值的總和，<basename>_sum
  • 已觀察到的事件計數，<basename>_count與上述相同<basename>_bucket{le="+Inf"}）

例如K8s中pod啟動耗時：

kubelet_pod_start_duration_seconds_bucket
kubelet_pod_start_duration_seconds_count #進行過pod start的數量
kubelet_pod_start_duration_seconds_sum  # 總耗時

具體到某個節點中

image-20220607120006638

le:小於等於。例如le=”5“，即pod啟動耗時<=5s的有87次

+inf：無窮。當啟動耗時為無窮時，也就是節點下pod啟動過的數量，與kubelet_pod_start_duration_seconds_count相等

通過grafana 中 Bar gauge呈現桶的分佈如下：

image-20220607122058374

有了直方圖資料後我們可以做相應的比例計算：

計算pod啟動耗時大於1s，小於2.5s的次數

#kubelet_pod_start_duration_seconds_bucket{ instance="node4.**.com",le="2.5"} - ignoring(le) kubelet_pod_start_duration_seconds_bucket{ instance="node4.**.com",le="1"}
9

計算pod啟動耗時大於2.5s的比例

#kubelet_pod_start_duration_seconds_bucket{ instance="node4.**.com",le="2.5"} / ignoring(le) kubelet_pod_start_duration_seconds_bucket{ instance="node4.**.com",le="+Inf"}   
0.875

使用 PromQL 函式histogram_quantile計算百分位

#histogram_quantile(0.80,kubelet_pod_start_duration_seconds_bucket{ instance="node4.**.com"} )
1.3000000000000018

即80%的pod啟動次數中，耗時<=1.3s，histogram_quantile函式計算百分位得到是一個近似值。

通過histogram_quantile函式聚合

計算Prometheus http所有請求中80百分位的值

histogram_quantile(0.8, sum(rate(prometheus_http_request_duration_seconds_bucket[5m])) by (le))

image-20220607171310267

即80%的請求響應時間<=0.08s

通過histogram計算網站效能指標 - Apdex指數

Apdex 指數 =( 滿意數量 + 0.5 * 可容忍數量 ) / 總樣本數，假設請求滿意時間為0.3s，則可容忍時間為1.2s（4倍）

(
  sum(rate(http_request_duration_seconds_bucket{le="0.3"}[5m])) by (job)
+
  sum(rate(http_request_duration_seconds_bucket{le="1.2"}[5m])) by (job)
) / 2 / sum(rate(http_request_duration_seconds_count[5m])) by (job)
Summary

Summary與Histogram相似，也是通過三個metrics名稱來完整暴露一組Summary，不過Summary是直接在客戶端幫我們計算出了百分位數（Histogram 則使用上面提到的histogram_quantile函式計算）

  • φ 分位數(0 ≤ φ ≤ 1)，<basename>{quantile="<φ>"}
  • 所有觀察值的總和，<basename>_sum
  • 已觀察到的事件計數，<basename>_count

例如cgroup操作延遲：

kubelet_cgroup_manager_latency_microseconds
kubelet_cgroup_manager_latency_microseconds_sum
kubelet_cgroup_manager_latency_microseconds_count

image-20220607151157348

Summary和Histogram都可以使用rate函式計算平均數

計算cgroup update操作的平均延遲：

rate(kubelet_cgroup_manager_latency_microseconds_sum{ instance="node4.**.com",operation_type="update"}[10m]) / rate(kubelet_cgroup_manager_latency_microseconds_count{ instance="node4.**.com",operation_type="update"}[10m])

最後我們對比一下Summary與Histogram

Histogram Summary
配置要求 選擇符合預期觀測值範圍（le）的儲存桶 選擇所需的分位數φ和視窗範圍，其他φ無法再被計算
客戶端效能影響 低，僅需增加計數器 高，在客戶端計算分位數
服務端效能影響 高，服務端需計算分位數 服務端成本低
時間序列的數量（除了_sum和_count序列） 每新增一個儲存桶增加一個時間序列 每新增一個分位數φ 值增加一個時間序列
分位數誤差 受限於相關桶的寬度 誤差在 φ 值的限制
φ分位數和視窗範圍 取決於histogram_quantile函式中φ 由客戶端預先新增
聚合 histogram_quantile函式聚合 不聚合

通過部落格閱讀：iqsing.github.io

參考：

HISTOGRAMS AND SUMMARIES

Prometheus metric_types

相關文章