Metric类型
Metric類型
在上一小節中我們帶領讀者了解了Prometheus的底層數據模型，在Prometheus的存儲實現上所有的監控樣本都是以time-series的形式保存在Prometheus內存的TSDB（時序數據庫）中，而time-series所對應的監控指標(metric)也是通過labelset進行唯一命名的。
從存儲上來講所有的監控指標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消耗的資源更少。在選擇這兩種方式時用戶應該按照自己的實際場景進行選擇。
總結
- 上一篇： 美的空调e4代号故障怎么修复
- 下一篇： Snort