prometheus的summary和histogram指標是什么意思

本篇內容主要講解“prometheus的summary和histogram指標是什么意思”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“prometheus的summary和histogram指標是什么意思”吧!

prometheus的客戶端與服務端
客戶端是提供監控指標數據的一端（如寫的exporter）。prometheus提供了各種語言的客戶端庫，需要通過Prometheus客戶端庫把監控的代碼放在被監控的服務代碼中。當Prometheus獲取客戶端的HTTP端點時，客戶端庫發送所有跟蹤的度量指標數據到服務器上。詳情見客戶庫
服務端是指prometheus server，拉取、存儲和查詢各種各種指標數據。
histogram
histogram是柱狀圖，在Prometheus系統中的查詢語言中，有三種作用：
對每個采樣點進行統計（并不是一段時間的統計），打到各個桶(bucket)中
對每個采樣點值累計和(sum)
對采樣點的次數累計和(count)
度量指標名稱: [basename]的柱狀圖, 上面三類的作用度量指標名稱

[basename]_bucket{le=“上邊界”}, 這個值為小于等于上邊界的所有采樣點數量
[basename]_sum
[basename]_count
histogram例子

如上表，設置bucket=[1,5,10]，當實際采樣數據如是采樣點所示, Observe表示采樣點落在該bucket中的數量，即落在[-,1]的樣點數為2，即落在[1,5]的樣點數為3，即落在[5,10]的樣點數為1，write是得到的最終結果（histogram的最終結果bucket計數是向下包含的）：
[basename]_bucket{le=“1”} = 2
[basename]_bucket{le=“5”} =3
[basename]_bucket{le=“10”} =6
[basename]_bucket{le="+Inf"} = 6
[basename]_count =6
[basename]_sum =18.8378745

histogram并不會保存數據采樣點值，每個bucket只有個記錄樣本數的counter（float64），即histogram存儲的是區間的樣本數統計值，因此客戶端性能開銷相比 Counter 和 Gauge 而言沒有明顯改變，適合高并發的數據收集。

histogram_quantile()函數在服務端獲取summary分為數
Histogram 常使用 histogram_quantile 執行數據分析， histogram_quantile 函數通過分段線性近似模型逼近采樣數據分布的 UpperBound（如下圖），誤差是比較大的，其中紅色曲線為實際的采樣分布（正態分布），而實心圓點是 Histogram 的 bucket的分為數分別被計算為0.01 0.25 0.50 0.75 0.95，這是是依據bucket和sum來計算的。當求解 0.9 quantile 的采樣值時會用 (0.75, 0.95) 兩個相鄰的的 bucket 來線性近似。

但是如果自己知道數據的分布情況，設置適合的bucket也會得到相對精確的分為數。

summary
因為histogram在客戶端就是簡單的分桶和分桶計數，在prometheus服務端基于這么有限的數據做百分位估算，所以的確不是很準確，summary就是解決百分位準確的問題而來的。summary直接存儲了 quantile 數據，而不是根據統計區間計算出來的。
Prometheus的分為數稱為quantile，其實叫percentile更準確。百分位數是指小于某個特定數值的采樣點達到一定的百分比

summary是采樣點分位圖統計。 它也有三種作用：
在客戶端對于一段時間內（默認是10分鐘）的每個采樣點進行統計，并形成分位圖。（如：正態分布一樣，統計低于60分不及格的同學比例，統計低于80分的同學比例，統計低于95分的同學比例）
統計班上所有同學的總成績(sum)
統計班上同學的考試總人數(count)
帶有度量指標的[basename]的summary 在抓取時間序列數據展示。

觀察時間的φ-quantiles (0 ≤ φ ≤ 1), 顯示為[basename]{分位數="[φ]"}
[basename]_sum， 是指所有觀察值的總和
[basename]_count, 是指已觀察到的事件計數值
summary對quantile的計算是依賴第三方庫perk實現的：
github.com/beorn7/perks/quantile

summary例子
設置quantile={0.5: 0.05, 0.9: 0.01, 0.99: 0.001}

# HELP prometheus_tsdb_wal_fsync_duration_seconds Duration of WAL fsync.
# TYPE prometheus_tsdb_wal_fsync_duration_seconds summary
prometheus_tsdb_wal_fsync_duration_seconds{quantile="0.5"} 0.012352463
prometheus_tsdb_wal_fsync_duration_seconds{quantile="0.9"} 0.014458005
prometheus_tsdb_wal_fsync_duration_seconds{quantile="0.99"} 0.017316173
prometheus_tsdb_wal_fsync_duration_seconds_sum 2.888716127000002
prometheus_tsdb_wal_fsync_duration_seconds_count 216
1
2
3
4
5
6
7
從上面的樣本中可以得知當前Prometheus Server進行wal_fsync操作的總次數為216次，耗時2.888716127000002s。其中中位數（quantile=0.5）的耗時為0.012352463，9分位數（quantile=0.9）的耗時為0.014458005s，90%的數據都小于等于0.014458005s。

設置每個quantile后面還有一個數，0.5-quantile后面是0.05，0.9-quantile后面是0.01，而0.99后面是0.001。這些是我們設置的能容忍的誤差。0.5-quantile: 0.05意思是允許最后的誤差不超過0.05。假設某個0.5-quantile的值為120，由于設置的誤差為0.05，所以120代表的真實quantile是(0.45, 0.55)范圍內的某個值。注意quantile誤差值很小，但實際得到的分為數可能誤差很大。

查看分位數時summary和histogram的選擇
清楚幾點限制：

Summary 結構有頻繁的全局鎖操作，對高并發程序性能存在一定影響。histogram僅僅是給每個桶做一個原子變量的計數就可以了，而summary要每次執行算法計算出最新的X分位value是多少，算法需要并發保護。會占用客戶端的cpu和內存。
不能對Summary產生的quantile值進行aggregation運算（例如sum, avg等）。例如有兩個實例同時運行，都對外提供服務，分別統計各自的響應時間。最后分別計算出的0.5-quantile的值為60和80，這時如果簡單的求平均(60+80)/2，認為是總體的0.5-quantile值，那么就錯了。
summary的百分位是提前在客戶端里指定的，在服務端觀測指標數據時不能獲取未指定的分為數。而histogram則可以通過promql隨便指定，雖然計算的不如summary準確，但帶來了靈活性。
histogram不能得到精確的分為數，設置的bucket不合理的話，誤差會非常大。會消耗服務端的計算資源。
兩條經驗
如果需要聚合（aggregate），選擇histograms。
如果比較清楚要觀測的指標的范圍和分布情況，選擇histograms。如果需要精確的分為數選擇summary。
參考
Prometheus 原理和源碼分析
度量指標類型
HISTOGRAMS AND SUMMARIES

到此，相信大家對“prometheus的summary和histogram指標是什么意思”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！