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

因?yàn)榕驼嬲\，有更多的客戶和我們聚集在一起，為了共同目標(biāo)，創(chuàng)新互聯(lián)在工作上密切配合，從創(chuàng)業(yè)型企業(yè)到如今不斷成長，要感謝客戶對(duì)我們的高要求，讓我們敢于面對(duì)挑戰(zhàn)，才有今天的進(jìn)步與發(fā)展。從網(wǎng)站到成都小程序開發(fā),軟件開發(fā),app軟件開發(fā),十年企業(yè)網(wǎng)站建設(shè)服務(wù)經(jīng)驗(yàn),為企業(yè)提供網(wǎng)站設(shè)計(jì),網(wǎng)站托管維護(hù)一條龍服務(wù).為企業(yè)提供成都全網(wǎng)營銷推廣,按需制作,原創(chuàng)設(shè)計(jì),十年品質(zhì),值得您的信賴.

從存儲(chǔ)上來講所有的監(jiān)控指標(biāo)metric都是相同的，但是在不同的場景下這些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ì)無限變大的。

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

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

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

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

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

rate(http_requests_total[5m])

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

topk(10, http_requests_total)

Gauge：可增可減的儀表盤

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

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

node_memory_MemFree

對(duì)于Gauge類型的監(jiān)控指標(biāo)，通過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ù)的變化趨勢進(jìn)行預(yù)測。例如，預(yù)測系統(tǒng)磁盤空間在4個(gè)小時(shí)之后的剩余情況：

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

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

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

在大多數(shù)情況下人們都傾向于使用某些量化指標(biāo)的平均值，例如CPU的平均使用率、頁面的平均響應(yīng)時(shí)間。這種方式的問題很明顯，以系統(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īng)時(shí)間落到中位數(shù)的情況，而這種現(xiàn)象被稱為長尾問題。

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

例如，指標(biāo)prometheus_tsdb_wal_fsync_duration_seconds的指標(biāo)類型為Summary。 它記錄了Prometheus Server中wal_fsync處理的處理時(shí)間，通過訪問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ù)中，我們還能找到類型為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類型的指標(biāo)相似之處在于Histogram類型的樣本同樣會(huì)反應(yīng)當(dāng)前指標(biāo)的記錄的總數(shù)(以_count作為后綴)以及其值的總量（以_sum作為后綴）。不同在于Histogram指標(biāo)直接反應(yīng)了在不同區(qū)間內(nèi)樣本的個(gè)數(shù)，區(qū)間通過標(biāo)簽len進(jìn)行定義。

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

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

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