Prometheus 四種metric型別
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
參考：