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

成都創(chuàng)新互聯(lián)專注于平陰網(wǎng)站建設(shè)服務(wù)及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗。 熱誠為您提供平陰營銷型網(wǎng)站建設(shè)，平陰網(wǎng)站制作、平陰網(wǎng)頁設(shè)計、平陰網(wǎng)站官網(wǎng)定制、成都微信小程序服務(wù)，打造平陰網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供平陰網(wǎng)站排名全網(wǎng)營銷落地服務(wù)。

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

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

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

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

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

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

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

觀察時間的φ-quantiles (0 ≤ φ ≤ 1), 顯示為[basename]{分位數(shù)="[φ]"}
[basename]_sum， 是指所有觀察值的總和
[basename]_count, 是指已觀察到的事件計數(shù)值
summary對quantile的計算是依賴第三方庫perk實現(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
從上面的樣本中可以得知當前Prometheus Server進行wal_fsync操作的總次數(shù)為216次，耗時2.888716127000002s。其中中位數(shù)（quantile=0.5）的耗時為0.012352463，9分位數(shù)（quantile=0.9）的耗時為0.014458005s，90%的數(shù)據(jù)都小于等于0.014458005s。

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

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

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

到此，相信大家對“prometheus的summary和histogram指標是什么意思”有了更深的了解，不妨來實際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進入相關(guān)頻道進行查詢，關(guān)注我們，繼續(xù)學習！