prometheus的summary和histogram指標的簡單理解

prometheus的客戶端與服務端

• 客戶端是提供監控指標數據的一端（如寫的exporter）。prometheus提供了各種語言的客戶端庫，需要通過Prometheus客戶端庫把監控的代碼放在被監控的服務代碼中。當Prometheus獲取客戶端的HTTP端點時，客戶端庫發送所有跟蹤的度量指標數據到服務器上。詳情見客戶庫
• 服務端是指prometheus server，拉取、存儲和查詢各種各種指標數據。

histogram

histogram是柱狀圖，在Prometheus系統中的查詢語言中，有三種作用：

1. 對每個採樣點進行統計，打到各個分類值中(bucket)
2. 對每個採樣點值累計和(sum)
3. 對採樣點的次數累計和(count)

度量指標名稱: [basename]的柱狀圖, 上面三類的作用度量指標名稱

1. [basename]_bucket{le=“上邊界”}, 這個值爲小於等於上邊界的所有采樣點數量
2. [basename]_sum
3. [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是採樣點分位圖統計。 它也有三種作用：

1. 在客戶端對於一段時間內的每個採樣點進行統計，並形成分位圖。（如：正態分佈一樣，統計低於60分不及格的同學比例，統計低於80分的同學比例，統計低於95分的同學比例）
2. 統計班上所有同學的總成績(sum)
3. 統計班上同學的考試總人數(count)

帶有度量指標的[basename]的summary 在抓取時間序列數據展示。

1. 觀察時間的φ-quantiles (0 ≤ φ ≤ 1), 顯示爲[basename]{分位數="[φ]"}
2. [basename]_sum， 是指所有觀察值的總和
3. [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

從上面的樣本中可以得知當前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的選擇

清楚幾點限制：

1. Summary 結構有頻繁的全局鎖操作，對高併發程序性能存在一定影響。histogram僅僅是給每個桶做一個原子變量的計數就可以了，而summary要每次執行算法計算出最新的X分位value是多少，算法需要併發保護。會佔用客戶端的cpu和內存。
2. 不能對Summary產生的quantile值進行aggregation運算（例如sum, avg等）。例如有兩個實例同時運行，都對外提供服務，分別統計各自的響應時間。最後分別計算出的0.5-quantile的值爲60和80，這時如果簡單的求平均(60+80)/2，認爲是總體的0.5-quantile值，那麼就錯了。
3. summary的百分位是提前在客戶端裏指定的，在服務端觀測指標數據時不能獲取未指定的分爲數。而histogram則可以通過promql隨便指定，雖然計算的不如summary準確，但帶來了靈活性。
4. histogram不能得到精確的分爲數，設置的bucket不合理的話，誤差會非常大。會消耗服務端的計算資源。

兩條經驗

1. 如果需要聚合（aggregate），選擇histograms。
2. 如果比較清楚要觀測的指標的範圍和分佈情況，選擇histograms。如果需要精確的分爲數選擇summary。

參考

Prometheus 原理和源碼分析
度量指標類型
HISTOGRAMS AND SUMMARIES