prometheus-metrics類型的使用方法

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

從存儲上來講所有的監控指標metric都是相同的，但是在不同的場景下這些metric又有一些細微的差異。 例如，在Node Exporter返回的樣本中指標node_load1反應的是當前系統的負載狀態，隨著時間的變化這個指標返回的樣本數據是在不斷變化的。而指標node_cpu所獲取到的樣本數據卻不同，它是一個持續增大的值，因為其反應的是CPU的累積使用時間，從理論上講只要系統不關機，這個值是會無限變大的。

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

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

# HELP node_cpu Seconds the cpus spent in each mode.

# TYPE node_cpu counter

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

Counter：只增不減的計數器

Counter類型的指標其工作方式和計數器一樣，只增不減（除非系統發生重置）。常見的監控指標，如http_requests_total，node_cpu都是Counter類型的監控指標。 一般在定義Counter類型指標的名稱時推薦使用_total作為后綴。

Counter是一個簡單但有強大的工具，例如我們可以在應用程序中記錄某些事件發生的次數，通過以時序的形式存儲這些數據，我們可以輕松的了解該事件產生速率的變化。 PromQL內置的聚合操作和函數可以讓用戶對這些數據進行進一步的分析：

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

rate(http_requests_total[5m])

查詢當前系統中，訪問量前10的HTTP地址：

topk(10, http_requests_total)

Gauge：可增可減的儀表盤

與Counter不同，Gauge類型的指標側重于反應系統的當前狀態。因此這類指標的樣本數據可增可減。常見指標如：node_memory_MemFree（主機當前空閑的內容大小）、node_memory_MemAvailable（可用內存大小）都是Gauge類型的監控指標。

通過Gauge指標，用戶可以直接查看系統的當前狀態：

node_memory_MemFree

對于Gauge類型的監控指標，通過PromQL內置函數delta()可以獲取樣本在一段時間返回內的變化情況。例如，計算CPU溫度在兩個小時內的差異：

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

還可以使用deriv()計算樣本的線性回歸模型，甚至是直接使用predict_linear()對數據的變化趨勢進行預測。例如，預測系統磁盤空間在4個小時之后的剩余情況：

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

使用Histogram和Summary分析數據分布情況

除了Counter和Gauge類型的監控指標以外，Prometheus還定義了Histogram和Summary的指標類型。Histogram和Summary主用用于統計和分析樣本的分布情況。

在大多數情況下人們都傾向于使用某些量化指標的平均值，例如CPU的平均使用率、頁面的平均響應時間。這種方式的問題很明顯，以系統API調用的平均響應時間為例：如果大多數API請求都維持在100ms的響應時間范圍內，而個別請求的響應時間需要5s，那么就會導致某些WEB頁面的響應時間落到中位數的情況，而這種現象被稱為長尾問題。

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

例如，指標prometheus_tsdb_wal_fsync_duration_seconds的指標類型為Summary。 它記錄了Prometheus Server中wal_fsync處理的處理時間，通過訪問Prometheus Server的/metrics地址，可以獲取到以下監控樣本數據：

# 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。

在Prometheus Server自身返回的樣本數據中，我們還能找到類型為Histogram的監控指標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類型的指標相似之處在于Histogram類型的樣本同樣會反應當前指標的記錄的總數(以_count作為后綴)以及其值的總量（以_sum作為后綴）。不同在于Histogram指標直接反應了在不同區間內樣本的個數，區間通過標簽len進行定義。

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

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

到此，關于“prometheus-metrics類型的使用方法”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！