1  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)

2 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)

3 使用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消耗的資源更少。在選擇這兩種方式時使用者應該按照自己的實際