本文大綱：
• prometheus metrics的概念
• k/v的數據形式
• prometheus exporter的使⽤（pull形式采集數據）
• prometheus pushgateway的⼊門介紹（push形式采集數據）
1）prometheus metrics的概念
promethes監控中對於采集過來的數據統⼀稱為metrics數據
當我們需要為某個系統某個服務做監控、做統計，就需要⽤到Metrics。
metrics是⼀種對采樣數據的總稱（metrics 並不代表某⼀種具體的數據格式 是⼀種對於度量計算單位的抽象 ）
咱們來介紹⼀下 metrics 的⼏種主要的類型
Gauges
最簡單的度量指標，只有⼀個簡單的返回值，或者叫瞬時狀態，例如，我們想衡量⼀個待處理隊列中任務的個數、
⽤更簡單的⽅式舉個例⼦
例如 ： 如果我要監控硬盤容量或者內存的使⽤量，那么就應該使⽤Gauges的metrics格式來度量
因為硬盤的容量或者內存的使⽤量是隨着時間的推移不斷的瞬時沒有規則變化的
這種變化沒有規律，當前是多少，采集回來的就是多少 5:00 21%。5:01 25% ， 5:02 17%
既不能肯定是 ⼀只持續增⻓ 也不能肯定是⼀直降低
是多少 就是多少 這種就是Gauges使⽤類型的代表
如圖所示 CPU的上下浮動就是采集使⽤Gauge形式的 metrics數據 沒有規律 是多少就得到多少然后顯示出來 
Counters 類型metris
Counter就是計數器，從數據量0開始累積計算 在理想狀態下只能是永遠的增⻓不會降低
Counter => 數字 +++ 2:00 => 0 prometheus
舉個例⼦來說
⽐如對⽤戶訪問量的采樣數據
我們的產品被⽤戶訪問⼀次就是1 過了10分鍾后 積累到 100
過⼀天后 積累到 20000
⼀周后 積累到 100000-150000
如下圖展示的Counter數據 是從0開始⼀直不斷的積累，累加下去的 所以理想狀態下 不可能出現任何降低的狀況
最多只可能是 ⼀直保持不變（例如 ⽤戶不再訪問了，那么當前累積的總訪問量 會以⼀條水平線的狀態保持下去 直到 再被訪問）
如下圖展示的 就是⼀個counter類型的metrics數據采集。 采集的是 ⽤戶的訪問累積量 
Histograms
Histogram統計數據的分布情況。⽐如最⼩值，最⼤值，中間值，還有中位數，75百分位, 90百分位, 95百分位, 98百分位, 99百分位, 和 99.9百分位的值(percentiles)。
這是⼀種特殊的 metrics數據類型 ， 代表的是⼀種近似的百分⽐估算數值
⽐如我們在企業⼯作中 經常接觸這種數據
Http_response_time HTTP響應時間
代表的是 ⼀次⽤戶HTTP請求 在系統傳輸和執⾏過程中 總共花費的時間
nginx中的 也會記錄這⼀項數值 在⽇志中
那么問題來了
我們做⼀個假設
如果我們想通過監控的⽅式 抓取當天的nginx access_log ，並且想監控⽤戶的訪問時間
我們應該怎么做呢？
把⽇志每⾏的 http_response_time 數值統統采集下來啊 然后計算⼀下總的平均值即可
那么⼤⽶要問⼤家⼀句了 假如我們采集到 今天⼀天的訪問量 是100萬次
然后把這100萬次的 http_response_time 全都加⼀起 然后 除以100萬 最后得出來⼀個avg值
0.05秒 = 50毫秒
這個數據的意義⼤么？
假如 今天中午1:00的時候 發⽣了⼀次線上故障 系統整體的訪問變得⾮常緩慢 ⼤部分的⽤戶
請求時間都達到了 0.5～1秒作⽤
但是這⼀段時間 只持續了5分鍾， 總的⼀天的平均值並不能表現得出來 我們如何在1:00-
1:05的時候 實現報警呢？
在舉個例⼦：
就算我們⼀天下來 線上沒有發⽣故障 ⼤部分⽤戶的響應時間 都在 0.05秒（通過 總時間/總
次數得出）
但是我們不要忘了 任何系統中 都⼀定存在 慢請求 就是有⼀少部分的⽤戶 請求時間會⽐總
的平均值⼤很多 甚⾄接近 5秒 10秒的也有
（這種情況很普遍 因為各種因素 可能是軟件本⾝的bug 也可能是系統的原因 更有可能是少
部分⽤戶的使⽤途徑中出現了問題）
那么我們的監控需要 發現和報警 這種少部分的特殊狀況，⽤總平均能獲得嗎？
如果采⽤總平均的⽅式，那不管發⽣什么特殊情況，因為⼤部分的⽤戶響應都是正常的 你
永遠也發現不了少部分的問題
所以 Histogram的metrics類型 在這種時候就派上⽤場了
通過histogram類型（prometheus中 其實提供了⼀個 基於histogram算法的 函數 可以直接使
⽤）
可以分別統計出 全部⽤戶的響應時間中
~=0.05秒的 量有多少 0 ~ 0.05秒的有多少， > 2秒的有多少 >10秒的有多少 => 1%
我們就可以很清晰的看到 當前我們的系統中 處於基本正常狀態的有多少百分⽐的⽤戶（或
者是請求）
多少處於速度極快的⽤戶， 多少處於慢請求或者有問題的請求
metrics的類型其實還有另外的類型
但是在我們⼤⽶運維的課程中 我們最主要使⽤的 就是 counter ganga 和 histogram
2) k/v的數據形式
prometheus 的數據類型就是依賴於這種 metris的類型來計算的
⽽對於采集回來的數據類型再往細了說必須要以⼀種具體的數據格式供我們查看和使⽤
那么我們來看⼀下⼀個exporter 給我們采集來的 服務器上的k/v形式 metrics數據
當⼀個exporter(node_exporter) 被安裝和運⾏在 被監控的服務器上后
使⽤簡單的 curl命令 就可以看到 exporer幫我們采集到 metrics數據的樣⼦ ， 以 k / v 的形式展現和保存
curl localhost:9100/metrics 
如上圖所⽰ curl之后的結果輸出
prometheus_server
帶# 的⾏ 是注釋⾏ ⽤來解釋下⾯這⼀項 k / v 數值 是什么東東的采樣數據
⽽ 我們真正關⼼的 是這樣的 數據 
看到了沒有 就是⽤空格分開的 KEY / Value 數據
第⼀個代表的是 當前采集的 最⼤⽂件句柄數 是 65535
第⼆個代表的是 當前采集的 被打開的⽂件句柄數是： 10
這樣就⾮常好理解了
另外 我們在看下這⾥ 
第⼆⾏的 # 告訴我們了 這⼀項數據的metrics類型 屬於gauge
因為很簡單， ⽂件句柄數的使⽤ 是沒有規律的瞬時采樣數據 當前是多少就是多少
3） exporter的使⽤
官⽹提供了豐富的 成型 exportrs插件可以使⽤
舉⼏個例⼦ 
下載⾸頁 其實就已經提供了 很多 很常⽤的 exporters
這些exporters 分別使⽤不同的開發語⾔開發，有 go 有 Java 有python 有ruby 等等
我們不關⼼社區組織 ⽤什么語⾔做的開發
我們只要關⼼ 如何下載和正確安裝使⽤ 即可
⼤多數exporters 下載之后，就提供了啟動的命令 ⼀般直接運⾏ 帶上⼀定的參數就可以了
⽐如 最常⽤的 node_exporter =》 這個exporter⾮常強⼤，⼏乎可以把 Linux系統中 和系統⾃
⾝相關的監控數據 全抓出來了（很多參數 說真的 都沒聽說過 ⽐你想象的 學過的 多的多）
這⾥只給⼤家⼀個截圖 展⽰node_exporter⼀部分的 ⽀持的監控數據采集 
每⼀項 其實還有N多的⼦項， 該有的數據都有了，不該有的 不重要的 基本也有了 應有盡有
咱們還需要 ⾃⼰開發采集exporter嗎？ 其實不怎么需要了 直接⽤就好了
4） pushgateway 的概念介紹
之前說的 exporter 是⾸先安裝在被監控服務器上運⾏在后台
然后⾃動采集系統數據 ， 本⾝又是⼀個 HTTP_server 可以被prometheus服務器定時去HTTP GET取得數據
屬於pull的形式
如果把這個過程反過來
push的形式是把pushgateway安裝在客戶端或者服務端（其實裝哪⾥都⽆俗謂）
pushgateway本⾝也是⼀個http服務器
運維通過寫⾃⼰的腳本程序抓⾃⼰想要的監控數據然后推送到 pushgateway(HTTP) 再由pushgateway推送到 prometheus服務端
是⼀個反過來的被動模式
為什么已經有了那么強⼤的 pull 形式的node_exporter采集還需要⼀個pushgateway的形式呢？
其實對這個問題的回答是：
• exporter雖然采集類型已經很豐富了，但是我們依然需要很多⾃制的監控數據⾮規則化的⾃定制的
• exporter 由於數據類型采集量⼤，其實很多數據或者說⼤部分數據其實我們監控中真的⽤不到，⽤pushgateway是定義⼀項數據就采集着⼀種節省資源
• ⼀個新的⾃定義的pushgateway腳本開發遠遠⽐開發⼀個全新的exporter 簡單快速的多的多的多！ （exporter的開發需要使⽤真正的編程語⾔ ，shell這種快速腳本是不
⾏的⽽且需要了解很多 prometheus⾃定的編程格式才能開始制作⼯作量很⼤）
• exporter雖然已經很豐富了，但是依然有很多的我們需要的采集形式， exporter⽆法提供，或者說 現有的expoter還不⽀持，但是如果使⽤pushgateway的形式 就可以任意靈活，想做什么都可以做到⽽且極快
最后 ⽤⼀張圖 來⽴刻這兩種不同的 采集形式 