Metrics類型
根據不同監控指標之間的差異，Prometheus定義了4中不同的指標類型(metric type)：Counter（計數器）、Gauge（儀表盤）、Histogram（直方圖）、Summary（摘要）。
最常用的兩種數據類型:
- counter：此類型的指標其工作方式和計數器一樣，只增不減（除非系統發生重置）。例如 node_cpu_seconds_total{mode="idle"} cpu空閑時間。
- Gauge：用於反應該樣本的當前狀態，該樣本數可增可減。例如可用內存大小。
較難理解的兩種數據類型: - Histogram與Summary：都是比例型的數值，統計數據的分布情況，如最小值，最大值，中間值，中位數，75百分位，90百分位，95百分位，98百分位，99百分位和99.9百分位（percentiles），近似於百分比估算數值。兩種區別在於summary分位數是客戶端計算上報，histogram中位數涉及服務端計算。
此處Http_response_time來解釋此類型數據:
http請求響應時間：一次用戶http請求在系統傳輸和執行過程中總共花費的時間，nginx的access_log有一列就為此時間。
需求:抓取某個業務當天access_log，並監控用戶的訪問時間，如何操作？
方案1：所有請求訪問時間總和求平均值 假如當天100w次訪問平均值為0.05s
情景1： 假如當天發生線上故障：中午1:00 - 1:05,整體用戶請求響應時間0.5-1s。此種方案無法反映此段故障。
情景2： 慢請求，有一小部分用戶由於程序bug，或系統或其他原因，請求響應時間比平均值大很多，甚至5s，10s 。此種方案也無法反應此情況。
方案2：基於Histogram的metrics類型（prometheus提供了一個基於Histogram算法的函數可供直接使用）分別統計出各段響應時間的用戶:
~=0.0.5s 的請求數 ， 0~0.05s的請求數 ，>2s的請求數 ，>10s的請求數
函數介紹
以下兩個函數都用於counter類型數據
increase( )
eg:某一分鍾cpu使用時間 increase()[1m]=該分鍾末cpu使用時間-該分鍾初cpu使用時間
rate(）
eg:某一分鍾cpu使用率 rate()[1m]=某一分鍾cpu使用時間/60s
即 rate()=increase( )/60s
topk(3,rate(監控項(表達式))) 可用於監控單核cpu使用率前3 > xxx告警
sum() by ()
將某表達式查出的所有數據相加即為sum(), 再將相加的值通過某個特性進行分組，即為 sum() by()
例如監控某台主機（非單核）的cpu使用率
count()
對於滿足某個表達式的監控項進行計數
eg: cpu使用率大於80%的服務器超過30台告警
_over_time()
以下函數允許聚合給定范圍向量的每個系列隨時間的變化並返回具有每系列聚合結果的即時向量：
avg_over_time(range-vector): 范圍向量內每個度量指標的平均值。
min_over_time(range-vector): 范圍向量內每個度量指標的最小值。
max_over_time(range-vector): 范圍向量內每個度量指標的最大值。
sum_over_time(range-vector): 范圍向量內每個度量指標的求和值。
count_over_time(range-vector): 范圍向量內每個度量指標的樣本數據個數。
quantile_over_time(scalar, range-vector): 范圍向量內每個度量指標的樣本數據值分位數，φ-quantile (0 ≤ φ ≤ 1)
stddev_over_time(range-vector): 范圍向量內每個度量指標的總體標准偏差。
`stdvar_over_time(range-vector): 范圍向量內每個度量指標的總體標准方差。
eg：
該主機1天內node_load5的最大值
max_over_time (node_load5{instance="1.1.1.1:9100"}[24h])
1h內的內存使用率 100 * (1 - ((avg_over_time(node_memory_MemFree_bytes[1h]) + avg_over_time(node_memory_Cached_bytes[1h]) + avg_over_time(node_memory_Buffers_bytes[1h])) / avg_over_time(node_memory_MemTotal_bytes[1h])))