prometheus的summary和histogram指標(biāo)是什么意思

本篇內(nèi)容主要講解“prometheus的summary和histogram指標(biāo)是什么意思”，感興趣的朋友不妨來看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“prometheus的summary和histogram指標(biāo)是什么意思”吧!

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

[basename]_bucket{le=“上邊界”}, 這個(gè)值為小于等于上邊界的所有采樣點(diǎn)數(shù)量
[basename]_sum
[basename]_count
histogram例子

如上表，設(shè)置bucket=[1,5,10]，當(dāng)實(shí)際采樣數(shù)據(jù)如是采樣點(diǎn)所示, Observe表示采樣點(diǎn)落在該bucket中的數(shù)量，即落在[-,1]的樣點(diǎn)數(shù)為2，即落在[1,5]的樣點(diǎn)數(shù)為3，即落在[5,10]的樣點(diǎn)數(shù)為1，write是得到的最終結(jié)果（histogram的最終結(jié)果bucket計(jì)數(shù)是向下包含的）：
[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并不會(huì)保存數(shù)據(jù)采樣點(diǎn)值，每個(gè)bucket只有個(gè)記錄樣本數(shù)的counter（float64），即histogram存儲(chǔ)的是區(qū)間的樣本數(shù)統(tǒng)計(jì)值，因此客戶端性能開銷相比 Counter 和 Gauge 而言沒有明顯改變，適合高并發(fā)的數(shù)據(jù)收集。

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

但是如果自己知道數(shù)據(jù)的分布情況，設(shè)置適合的bucket也會(huì)得到相對(duì)精確的分為數(shù)。

summary
因?yàn)閔istogram在客戶端就是簡(jiǎn)單的分桶和分桶計(jì)數(shù)，在prometheus服務(wù)端基于這么有限的數(shù)據(jù)做百分位估算，所以的確不是很準(zhǔn)確，summary就是解決百分位準(zhǔn)確的問題而來的。summary直接存儲(chǔ)了 quantile 數(shù)據(jù)，而不是根據(jù)統(tǒng)計(jì)區(qū)間計(jì)算出來的。
Prometheus的分為數(shù)稱為quantile，其實(shí)叫percentile更準(zhǔn)確。百分位數(shù)是指小于某個(gè)特定數(shù)值的采樣點(diǎn)達(dá)到一定的百分比

summary是采樣點(diǎn)分位圖統(tǒng)計(jì)。 它也有三種作用：
在客戶端對(duì)于一段時(shí)間內(nèi)（默認(rèn)是10分鐘）的每個(gè)采樣點(diǎn)進(jìn)行統(tǒng)計(jì)，并形成分位圖。（如：正態(tài)分布一樣，統(tǒng)計(jì)低于60分不及格的同學(xué)比例，統(tǒng)計(jì)低于80分的同學(xué)比例，統(tǒng)計(jì)低于95分的同學(xué)比例）
統(tǒng)計(jì)班上所有同學(xué)的總成績(jī)(sum)
統(tǒng)計(jì)班上同學(xué)的考試總?cè)藬?shù)(count)
帶有度量指標(biāo)的[basename]的summary 在抓取時(shí)間序列數(shù)據(jù)展示。

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

summary例子
設(shè)置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
從上面的樣本中可以得知當(dāng)前Prometheus Server進(jìn)行wal_fsync操作的總次數(shù)為216次，耗時(shí)2.888716127000002s。其中中位數(shù)（quantile=0.5）的耗時(shí)為0.012352463，9分位數(shù)（quantile=0.9）的耗時(shí)為0.014458005s，90%的數(shù)據(jù)都小于等于0.014458005s。

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

查看分位數(shù)時(shí)summary和histogram的選擇
清楚幾點(diǎn)限制：

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

到此，相信大家對(duì)“prometheus的summary和histogram指標(biāo)是什么意思”有了更深的了解，不妨來實(shí)際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！