Prometheus 四種metric型別

iqsing發表於2022-06-07

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

相關文章