Prometheus的4種metrics(指標)型別:
- Counter
- Gauge
- Histogram
- Summary
四種指標型別的資料物件都是數字,如果要監控文字類的資訊只能通過指標名稱或者 label 來呈現,在 zabbix 一類的監控中指標型別本身支援 Log 和文字,當然在這裡我們不是要討論 Prometheus 的侷限性,而是要看一看 Prometheus 是如何把數字玩出花活的。 Counter 與 Gauge 比較好理解,我們簡單的過一下 然後主要關注 Histogram 和 Summary
Counter 與 Gauge
Counter
單調遞增的計數器。
例如 Prometheus自身 中 metrics 的 http 請求總數
Gauge
儀表,也可以認為是一種計數器,不過支援加和減。
例如 node 中的負載資料
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 # 總耗時
具體到某個節點中
le:小於等於。例如le=”5“,即pod啟動耗時<=5s的有87次
+inf:無窮。當啟動耗時為無窮時,也就是節點下pod啟動過的數量,與kubelet_pod_start_duration_seconds_count
相等
通過grafana 中 Bar gauge呈現桶的分佈如下:
有了直方圖資料後我們可以做相應的比例計算:
計算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))
即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
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
參考: