prometheus-metrics類(lèi)型的使用方法

這篇文章主要介紹“prometheus-metrics類(lèi)型的使用方法”，在日常操作中，相信很多人在prometheus-metrics類(lèi)型的使用方法問(wèn)題上存在疑惑，小編查閱了各式資料，整理出簡(jiǎn)單好用的操作方法，希望對(duì)大家解答”prometheus-metrics類(lèi)型的使用方法”的疑惑有所幫助！接下來(lái)，請(qǐng)跟著小編一起來(lái)學(xué)習(xí)吧！

從存儲(chǔ)上來(lái)講所有的監(jiān)控指標(biāo)metric都是相同的，但是在不同的場(chǎng)景下這些metric又有一些細(xì)微的差異。 例如，在Node Exporter返回的樣本中指標(biāo)node_load1反應(yīng)的是當(dāng)前系統(tǒng)的負(fù)載狀態(tài)，隨著時(shí)間的變化這個(gè)指標(biāo)返回的樣本數(shù)據(jù)是在不斷變化的。而指標(biāo)node_cpu所獲取到的樣本數(shù)據(jù)卻不同，它是一個(gè)持續(xù)增大的值，因?yàn)槠浞磻?yīng)的是CPU的累積使用時(shí)間，從理論上講只要系統(tǒng)不關(guān)機(jī)，這個(gè)值是會(huì)無(wú)限變大的。

為了能夠幫助用戶(hù)理解和區(qū)分這些不同監(jiān)控指標(biāo)之間的差異，Prometheus定義了4中不同的指標(biāo)類(lèi)型(metric type)：Counter（計(jì)數(shù)器）、Gauge（儀表盤(pán)）、Histogram（直方圖）、Summary（摘要）。

在Exporter返回的樣本數(shù)據(jù)中，其注釋中也包含了該樣本的類(lèi)型。例如：

# HELP node_cpu Seconds the cpus spent in each mode.

# TYPE node_cpu counter

node_cpu{cpu="cpu0",mode="idle"} 362812.7890625

Counter：只增不減的計(jì)數(shù)器

Counter類(lèi)型的指標(biāo)其工作方式和計(jì)數(shù)器一樣，只增不減（除非系統(tǒng)發(fā)生重置）。常見(jiàn)的監(jiān)控指標(biāo)，如http_requests_total，node_cpu都是Counter類(lèi)型的監(jiān)控指標(biāo)。 一般在定義Counter類(lèi)型指標(biāo)的名稱(chēng)時(shí)推薦使用_total作為后綴。

Counter是一個(gè)簡(jiǎn)單但有強(qiáng)大的工具，例如我們可以在應(yīng)用程序中記錄某些事件發(fā)生的次數(shù)，通過(guò)以時(shí)序的形式存儲(chǔ)這些數(shù)據(jù)，我們可以輕松的了解該事件產(chǎn)生速率的變化。 PromQL內(nèi)置的聚合操作和函數(shù)可以讓用戶(hù)對(duì)這些數(shù)據(jù)進(jìn)行進(jìn)一步的分析：

例如，通過(guò)rate()函數(shù)獲取HTTP請(qǐng)求量的增長(zhǎng)率：

rate(http_requests_total[5m])

查詢(xún)當(dāng)前系統(tǒng)中，訪問(wèn)量前10的HTTP地址：

topk(10, http_requests_total)

Gauge：可增可減的儀表盤(pán)

與Counter不同，Gauge類(lèi)型的指標(biāo)側(cè)重于反應(yīng)系統(tǒng)的當(dāng)前狀態(tài)。因此這類(lèi)指標(biāo)的樣本數(shù)據(jù)可增可減。常見(jiàn)指標(biāo)如：node_memory_MemFree（主機(jī)當(dāng)前空閑的內(nèi)容大?。?、node_memory_MemAvailable（可用內(nèi)存大小）都是Gauge類(lèi)型的監(jiān)控指標(biāo)。

通過(guò)Gauge指標(biāo)，用戶(hù)可以直接查看系統(tǒng)的當(dāng)前狀態(tài)：

node_memory_MemFree

對(duì)于Gauge類(lèi)型的監(jiān)控指標(biāo)，通過(guò)PromQL內(nèi)置函數(shù)delta()可以獲取樣本在一段時(shí)間返回內(nèi)的變化情況。例如，計(jì)算CPU溫度在兩個(gè)小時(shí)內(nèi)的差異：

delta(cpu_temp_celsius{host="zeus"}[2h])

還可以使用deriv()計(jì)算樣本的線性回歸模型，甚至是直接使用predict_linear()對(duì)數(shù)據(jù)的變化趨勢(shì)進(jìn)行預(yù)測(cè)。例如，預(yù)測(cè)系統(tǒng)磁盤(pán)空間在4個(gè)小時(shí)之后的剩余情況：

predict_linear(node_filesystem_free{job="node"}[1h], 4 * 3600)

使用Histogram和Summary分析數(shù)據(jù)分布情況

除了Counter和Gauge類(lèi)型的監(jiān)控指標(biāo)以外，Prometheus還定義了Histogram和Summary的指標(biāo)類(lèi)型。Histogram和Summary主用用于統(tǒng)計(jì)和分析樣本的分布情況。

在大多數(shù)情況下人們都傾向于使用某些量化指標(biāo)的平均值，例如CPU的平均使用率、頁(yè)面的平均響應(yīng)時(shí)間。這種方式的問(wèn)題很明顯，以系統(tǒng)API調(diào)用的平均響應(yīng)時(shí)間為例：如果大多數(shù)API請(qǐng)求都維持在100ms的響應(yīng)時(shí)間范圍內(nèi)，而個(gè)別請(qǐng)求的響應(yīng)時(shí)間需要5s，那么就會(huì)導(dǎo)致某些WEB頁(yè)面的響應(yīng)時(shí)間落到中位數(shù)的情況，而這種現(xiàn)象被稱(chēng)為長(zhǎng)尾問(wèn)題。

為了區(qū)分是平均的慢還是長(zhǎng)尾的慢，最簡(jiǎn)單的方式就是按照請(qǐng)求延遲的范圍進(jìn)行分組。例如，統(tǒng)計(jì)延遲在0~10ms之間的請(qǐng)求數(shù)有多少而10~20ms之間的請(qǐng)求數(shù)又有多少。通過(guò)這種方式可以快速分析系統(tǒng)慢的原因。Histogram和Summary都是為了能夠解決這樣問(wèn)題的存在，通過(guò)Histogram和Summary類(lèi)型的監(jiān)控指標(biāo)，我們可以快速了解監(jiān)控樣本的分布情況。

例如，指標(biāo)prometheus_tsdb_wal_fsync_duration_seconds的指標(biāo)類(lèi)型為Summary。 它記錄了Prometheus Server中wal_fsync處理的處理時(shí)間，通過(guò)訪問(wèn)Prometheus Server的/metrics地址，可以獲取到以下監(jiān)控樣本數(shù)據(jù)：

# 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

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

在Prometheus Server自身返回的樣本數(shù)據(jù)中，我們還能找到類(lèi)型為Histogram的監(jiān)控指標(biāo)prometheus_tsdb_compaction_chunk_range_bucket。

# HELP prometheus_tsdb_compaction_chunk_range Final time range of chunks on their first compaction

# TYPE prometheus_tsdb_compaction_chunk_range histogram

prometheus_tsdb_compaction_chunk_range_bucket{le="100"} 0

prometheus_tsdb_compaction_chunk_range_bucket{le="400"} 0

prometheus_tsdb_compaction_chunk_range_bucket{le="1600"} 0

prometheus_tsdb_compaction_chunk_range_bucket{le="6400"} 0

prometheus_tsdb_compaction_chunk_range_bucket{le="25600"} 0

prometheus_tsdb_compaction_chunk_range_bucket{le="102400"} 0

prometheus_tsdb_compaction_chunk_range_bucket{le="409600"} 0

prometheus_tsdb_compaction_chunk_range_bucket{le="1.6384e+06"} 260

prometheus_tsdb_compaction_chunk_range_bucket{le="6.5536e+06"} 780

prometheus_tsdb_compaction_chunk_range_bucket{le="2.62144e+07"} 780

prometheus_tsdb_compaction_chunk_range_bucket{le="+Inf"} 780

prometheus_tsdb_compaction_chunk_range_sum 1.1540798e+09

prometheus_tsdb_compaction_chunk_range_count 780

與Summary類(lèi)型的指標(biāo)相似之處在于Histogram類(lèi)型的樣本同樣會(huì)反應(yīng)當(dāng)前指標(biāo)的記錄的總數(shù)(以_count作為后綴)以及其值的總量（以_sum作為后綴）。不同在于Histogram指標(biāo)直接反應(yīng)了在不同區(qū)間內(nèi)樣本的個(gè)數(shù)，區(qū)間通過(guò)標(biāo)簽len進(jìn)行定義。

同時(shí)對(duì)于Histogram的指標(biāo)，我們還可以通過(guò)histogram_quantile()函數(shù)計(jì)算出其值的分位數(shù)。不同在于Histogram通過(guò)histogram_quantile函數(shù)是在服務(wù)器端計(jì)算的分位數(shù)。 而Sumamry的分位數(shù)則是直接在客戶(hù)端計(jì)算完成。因此對(duì)于分位數(shù)的計(jì)算而言，Summary在通過(guò)PromQL進(jìn)行查詢(xún)時(shí)有更好的性能表現(xiàn)，而Histogram則會(huì)消耗更多的資源。反之對(duì)于客戶(hù)端而言Histogram消耗的資源更少。在選擇這兩種方式時(shí)用戶(hù)應(yīng)該按照自己的實(shí)際場(chǎng)景進(jìn)行選擇。

https://blog.csdn.net/polo2044/article/details/83277299

到此，關(guān)于“prometheus-metrics類(lèi)型的使用方法”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注億速云網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)?lái)更多實(shí)用的文章！