Prometheus的四大指標類型

Prometheus有4大指標類型（Metrics Type），分別是Counter（計數(shù)器）、Gauge（儀表盤）、Histogram（直方圖）和Summary（摘要）。

這是在Prometheus客戶端（目前主要有Go、Java、Python、Ruby等語言版本）中提供的4種核心指標類型，但是Prometheus的服務端并不區(qū)分指標類型，而是簡單地把這些指標統(tǒng)一視為無類型的時間序列。

注意：

上面這句話應該這么理解，四個指標類型，實際上就是客戶端采集數(shù)據(jù)的四個維度，采集這四個維度的指標數(shù)據(jù)，但是最終匯總到服務端那里，則是對這四個維度無感的，只是簡單的作為時間序列存儲起來。

Counter

?計數(shù)器表示一種單調遞增的指標，除非發(fā)生重置的情況下下只增不減，其樣本值應該是不斷增大的。例如，可以使用Counter類型的指標來表示服務的請求數(shù)、已完成的任務數(shù)、錯誤發(fā)生的次數(shù)等。

?但是，計數(shù)器計算的總數(shù)對用戶來說大多沒有什么用，大家千萬不要將計數(shù)器類型應用于樣本數(shù)據(jù)非單調遞增的指標上，比如當前運行的進程數(shù)量、當前登錄的用戶數(shù)量等應該使用儀表盤類型。

為了能夠更直觀地表示樣本數(shù)據(jù)的變化情況，往往需要計算樣本的增長速率，這時候通常使用PromQL的rate、topk、increase和irate等函數(shù)，如下所示：


rate(http_requests_total[5m]) // 通過rate()函數(shù)獲取HTTP請求量的增長速率

topk(10, http_requests_total) // 查詢當前系統(tǒng)中訪問量排在前10的HTTP地址

如上所示，速率的輸出rate（v range-vector）也應該用儀表盤來承接結果。

在上面的案例中，如果有一個標簽是Device，那么在統(tǒng)計每臺機器每秒接受的HTTP請求數(shù)時，可以用如下的例子進行操作。


sum without(device)(rate(http_requests_total[5m]))

補充

PromQL要先執(zhí)行rate()再執(zhí)行sum()，不能執(zhí)行完sum()再執(zhí)行rate()。

?這背后與rate()的實現(xiàn)方式有關，rate()在設計上假定對應的指標是一個計數(shù)器，也就是只有incr（增加）和reset（歸零）兩種行為。而執(zhí)行了sum()或其他聚合操作之后，得到的就不再是一個計數(shù)器了。舉個例子，比如sum()的計算對象中有一個歸零了，那整體的和會下降，而不是歸零，這會影響rate()中判斷reset（歸零）的邏輯，從而導致錯誤的結果。

increase函數(shù)

?increase（v range-vector）函數(shù)傳遞的參數(shù)是一個區(qū)間向量，increase函數(shù)獲取區(qū)間向量中的第一個和最后一個樣本并返回其增長量。下面的例子可以查詢Counter類型指標的增長速率，可以獲取http_requests_total在最近5分鐘內的平均樣本，其中300代表300秒。


increase(http_requests_total[5m]) / 300

rate和increase函數(shù)的局限性

?rate和increase函數(shù)計算的增長速率容易陷入長尾效應中。比如在某一個由于訪問量或者其他問題導致CPU占用100%的情況中，通過計算在時間窗口內的平均增長速率是無法反映出該問題的。

?為什么監(jiān)控和性能測試中，我們更關注p95/p99位？就是因為長尾效應。由于個別請求的響應時間需要1秒或者更久，傳統(tǒng)的響應時間的平均值就體現(xiàn)不出響應時間中的尖刺了，去尖刺也是數(shù)據(jù)采集中一個很重要的工序，這就是所謂的長尾效應。p95/p99就是長尾效應的分割線，如表示99%的請求在XXX范圍內，或者是1%的請求在XXX范圍之外。99%是一個范圍，意思是99%的請求在某一延遲內，剩下的1%就在延遲之外了。只是正推與逆推而已，是一種概念的兩種不同描述。

?irate（v range-vector）是PromQL針對長尾效應專門提供的靈敏度更高的函數(shù)。irate同樣用于計算區(qū)間向量的增長速率，但是其反映出的是瞬時增長速率。irate函數(shù)是通過區(qū)間向量中最后兩個樣本數(shù)據(jù)來計算區(qū)間向量的增長速率的。這種方式可以避免在時間窗口范圍內的“長尾問題”，并且體現(xiàn)出更好的靈敏度。通過irate函數(shù)繪制的圖標能夠更好地反映樣本數(shù)據(jù)的瞬時變化狀態(tài)。irate的調用命令如下所示。


irate(http_requests_total[5m])

?irate函數(shù)相比于rate函數(shù)提供了更高的靈敏度，不過分析長期趨勢時或者在告警規(guī)則中，irate的這種靈敏度反而容易造成干擾。因此，在長期趨勢分析或者告警中更推薦使用rate函數(shù)。

Gauge

?儀表盤類型代表一種樣本數(shù)據(jù)可以任意變化的指標，即可增可減。它可以理解為狀態(tài)的快照，Gauge通常用于表示溫度或者內存使用率這種指標數(shù)據(jù)，也可以表示能隨時增加或減少的“總數(shù)”，例如當前并發(fā)請求的數(shù)量node_memory_MemFree（主機當前空閑的內容大?。?、node_memory_MemAvailable（可用內存大?。┑取Ｔ谑褂肎auge時，用戶往往希望使用它們求和、取平均值、最小值、最大值等。

?以Prometheus經(jīng)典的Node Exporter的指標node_filesystem_size_bytes為例，它可以報告從node_filesystem_size_bytes采集來的文件系統(tǒng)大小，包含device、fstype和mountpoint等標簽。如果想要對每一臺機器上的總文件系統(tǒng)大小求和（sum），可以使用如下PromQL語句。


sum without(device, fstype, mountpoint)(node_filesystem_size_bytes)

?without可以讓sum指令根據(jù)相同的標簽進行求和，但是忽略without涵蓋的標簽。如果在實際工作中需要忽略更多標簽，可以根據(jù)實際情況在without里傳遞更多指標。

補充：

node_filesystem_size_bytes指標查詢

image.png

device, fstype, mountpoint都是他的標簽。

sum without(device, fstype, mountpoint)(node_filesystem_size_bytes)查詢

image.png

?如果要根據(jù)Node Exporter的指標node_filesystem_size_bytes計算每臺機器上最大的文件安裝系統(tǒng)大小，只需要將上述案例中的sum函數(shù)改為max函數(shù)，如下所示。


max without(device, fstype, mountpoint)(node_filesystem_size_bytes)

image.png

?除了求和、求最大值等，利用Gauge的函數(shù)求最小值和平均值等原理是類似的。除了基本的操作外，Gauge經(jīng)常結合PromQL的predict_linear和delta函數(shù)使用。

?predict_linear（v range-vector，t scalar）函數(shù)可以預測時間序列v在t秒后的值，就是使用線性回歸的方式，預測樣本數(shù)據(jù)的Gauge變化趨勢。例如，基于2小時的樣本數(shù)據(jù)，預測未來24小時內磁盤是否會滿，如下所示：


predict_linear(node_filesystem_free[2h],24*3600)<0

image.png

PromQL還有一個內置函數(shù)delta()，它可以獲取樣本在一段時間內的變化情況，也通常作用于Gauge。例如，計算磁盤空間在2小時內的差異，如下所示。


delta(node_filesystem_free_bytes{}[2h])

image.png

Histogram

Histogram是一個對數(shù)據(jù)分布情況的圖形表示，由一系列高度不等的長條圖（bar）或線段表示，用于展示單個測度得知的分布。

它一般用橫軸表示某個指標維度的數(shù)據(jù)取值區(qū)間,用縱軸表示樣本統(tǒng)計的頻率或頻數(shù),從而能夠以二維圖的形式展現(xiàn)數(shù)值的分布狀況
為了構建Histogram,首先需要將值的范圍進行分段,即將所有值的整個可用范圍分成一系列連續(xù)、相鄰(相鄰處可以是等同值)但不重疊的間隔,而后統(tǒng)計每個間隔中有多少值。
從統(tǒng)計學的角度看,分位數(shù)不能被聚合,也不能進行算術運算;

[圖片上傳失敗...(image-3e55f2-1622153155462)]

上邊界、樣本值總和、樣本總數(shù)

例子


prometheus_http_request_duration_seconds_bucket{handler="/targets",instance="192.168.16.134:9090",job="prometheus"}

prometheus_http_request_duration_seconds_count{handler="/targets",instance="192.168.16.134:9090",job="prometheus"}

prometheus_http_request_duration_seconds_sum{handler="/targets",instance="192.168.16.134:9090",job="prometheus"}

這三個查詢一起看

上邊界

image.png

樣本的值分布在Bucket中的數(shù)量，命名為<basename>_bucket{le="<上邊界>"}。這個值表示指標值小于等于上邊界的所有樣本數(shù)量。上述案例中的prometheus_http_request_duration_seconds_bucket{handler="/targets",instance="192.168.16.134:9090",job="prometheus",le="0.1"}12 就代表在總共的11次請求中，HTTP請求響應時間≤0.1s的請求一共是11次。

樣本值總和

image.png

所有樣本值的總和，命名為<basename>_sum。

prometheus_http_request_duration_seconds_sum{handler="/targets",instance="192.168.16.134:9090",job="prometheus"}0.405075955 表示12 次http請求的總響應時間是0.405075955

樣本總數(shù)

命名為<basename>_count，其值和<basename>_bucket{le="+Inf"}相同（所有）。

image.png

prometheus_http_request_duration_seconds_count{handler="/targets",instance="192.168.16.134:9090",job="prometheus"}12 表示總共發(fā)生了12次請求

?sum函數(shù)和count函數(shù)相除，可以得到一些平均值，比如Prometheus一天內的平均壓縮時間，可由查詢結果除以instance標簽數(shù)量得到，如下所示。


sum without(instance)(rate(prometheus_tsdb_compaction_duration_sum[1d])) 

/ 

sum without(instance)(rate(prometheus_tsdb_compaction_duration_count[1d]))

?除了Prometheus內置的壓縮時間，prometheus_local_storage_series_chunks_persisted表示Prometheus中每個時序需要存儲的chunk數(shù)量，也可以用于計算待持久化的數(shù)據(jù)的分位數(shù)。

?Histogram可以用于觀察樣本數(shù)據(jù)的分布情況。Histogram的分位數(shù)計算需要通過histogram_quantile（φfloat，b instant-vector）函數(shù)進行計算，但是histogram_quantile計算所得并非精確值。其中，φ（0<φ<1）表示需要計算的分位數(shù)（這個值主要是通過prometheus_http_request_duration_seconds_bucket和prometheus_http_request_duration_seconds_sum兩個指標得到的，是一個近似值）。

例子如下。


histogram_quantile(0.1, prometheus_http_request_duration_seconds_bucket)

Summary

?與Histogram類型類似，摘要用于表示一段時間內的數(shù)據(jù)采樣的結果（通常是請求持續(xù)時間或響應大小等），但它直接存儲了分位數(shù)（通過客戶端計算，然后展示出來），而非通過區(qū)間來計算（Histogram的分位數(shù)需要通過histogram_quantile（φfloat，b instant-vector）函數(shù)計算得到）。因此，對于分位數(shù)的計算，Summary在通過PromQL進行查詢時有更好的性能表現(xiàn)，而Histogram則會消耗更多的資源。反之，對于客戶端而言，Histogram消耗的資源更少。在選擇這兩種方式時，用戶應該根據(jù)自己的實際場景選擇。

Histogram是在服務端計算的，Summary是在客戶端計算的。

?安裝并啟動Prometheus后，在訪問http://localhost:9090/metrics時可以看到Prometheus自帶的一些Summary信息，這些信息和Histogram一樣在注釋中（#HELP和#TYPE）也會顯示，如下所示。


# HELP go_gc_duration_seconds A summary of the GC invocation durations.

# TYPE go_gc_duration_seconds summary

go_gc_duration_seconds{quantile="0"} 1.1666e-05

go_gc_duration_seconds{quantile="0.25"} 2.6265e-05

go_gc_duration_seconds{quantile="0.5"} 4.8366e-05

go_gc_duration_seconds{quantile="0.75"} 7.8298e-05

go_gc_duration_seconds{quantile="1"} 0.000280123

go_gc_duration_seconds_sum 0.193642882

go_gc_duration_seconds_count 1907

?在上述例子中，可以看到基于Go語言編寫的Prometheus的gc總次數(shù)是1907，耗時0.193642882s，其中中位數(shù)（quantile=0.5）計算的耗時為4.8366e-05s，代表1907次中50%的次數(shù)是小于4.8366e-05s的。

Summary類型的樣本也會提供3種指標，假設指標名稱為<basename>。

樣本值的分位數(shù)分布情況，命名為<basename>{quantile="<φ>"}，屬于計數(shù)器類型。
所有樣本值的大小總和，命名為<basenamesum，屬于計數(shù)器類型。
樣本總數(shù)，命名為<basename>_count，屬于計數(shù)器類型。

Summary和Histogram的異同

它們都包含了<basename>_sum和<basename>_count指標。
Histogram需要通過<basename_bucket來計算分位數(shù)，而Summary則直接存儲了分位數(shù)的值。
如果需要匯總或者了解要觀察的值的范圍和分布，建議使用Histogram；如果并不在乎要觀察的值的范圍和分布，僅需要精確的quantile值，那么建議使用Summary。

Summary的強大之處就是可以利用除法去計算時間的平均值。如果要從Histogram和Summary中計算最近5分鐘內的平均請求持續(xù)時間http_request_duration_seconds，可以用如下表達式進行。


rate(http_request_duration_seconds_sum[5m])/rate(http_request_duration_seconds_

    count[5m])

count本質上是一個計數(shù)器，sum通常情況下也會像計數(shù)器那樣工作。但是Summary和Histogram可能觀察到負值，比如溫度（-20℃），這種情況下會導致觀察的總量下降，無法再使用rate函數(shù)。

比如下面的例子就可以計算過去5分鐘內每次響應中返回的平均字節(jié)數(shù)。


sum without(handler)(rate(http_response_size_bytes_sum[5m])) 

/ 

sum without(handler)(rate(http_response_size_bytes_count[5m]))

關于這個例子，我們需要注意幾點。

·因為http_response_size_bytes_count和http_response_size_bytes_sum是計數(shù)器類型，所以必須在計算前先使用rate等函數(shù)。

·因為Prometheus的API會有很多handler，所以可以使用without過濾掉handler的返回值。

·PromQL要先執(zhí)行rate()再執(zhí)行sum()，不能先執(zhí)行sum()再執(zhí)行rate()。

·在統(tǒng)計學上，尤其是計算平均值時，要先進行sum等求和運算再做除法。對一個平均值再求平均是不正確的，如下所示。


// 合法

sum without(instance)(

    sum without(handler)(rate(http_response_size_bytes_sum[5m]))

  )

/

sum without(instance)(

    sum without(handler)(rate(http_response_size_bytes_count[5m]))

  )

// 非法

avg without(instance)(

    sum without(handler)(rate(http_response_size_bytes_sum[5m]))

  /

    sum without(handler)(rate(http_response_size_bytes_count[5m]))

)

// 非法

avg(http_request_duration_seconds{quantile="0.95"})

count的例子

案例一：計算所有的實例CPU核心數(shù)。

count by (instance) ( count by (instance,cpu) (node_cpu_seconds_total{mode=

"system"}) )

案例二：計算單個實例192.168.1.1的CPU核心數(shù)。

count by (instance) ( count by (instance,cpu) (node_cpu_seconds_total{mode="system",

instance="192.168.1.1"})

色偷偷精品伊人,欧洲久久精品,欧美综合婷婷骚逼,国产AV主播,国产最新探花在线,九色在线视频一区,伊人大交九欧美,1769亚洲,黄色成人av

Prometheus的四大指標類型