監控神器：Prometheus 輕鬆入門，真香！（下篇）

導語 ：Prometheus是一個開源的完整監控解決方案，本文將從指標抓取到查詢及視覺化展示，以及最後的監控告警，對Prometheus做一個基本的認識。

監控神器：Prometheus 輕鬆入門，真香！（上篇）_ITPUB部落格 (知識點：一至四)

五、PromQL

剛剛提到了Prometheus中指標有哪些型別以及如何匯出我們的指標，現在指標匯出到Prometheus了，利用其提供的PromQL可以查詢我們匯出的指標。

PromQL是Prometheus為我們提供的函式式的查詢語言，查詢表示式有四種型別：

• 字串：只作為某些內建函式的引數出現；
• 標量：單一的數字值，可以是函式引數，也可以是函式的返回結果；
• 瞬時向量：某一時刻的時序資料；
• 區間向量：某一時間區間內的時序資料集合。

（一）瞬時查詢

直接透過指標名即可進行查詢，查詢結果是當前指標最新的時間序列，比如查詢Gc累積消耗的時間：

我們可以看到查詢出來有多個同名指標結果 可以用 {}做標籤過濾查詢：比如我們想查指定例項的指標： 而且也支援則表示式，透過 =~ 指定正規表示式，如下所示：查詢所有 instance 是 localhost 開頭的指標。

（二）範圍查詢

範圍查詢的結果集就是區間向量，可以透過[]指定時間來做範圍查詢，查詢5分鐘內的Gc累積消耗時間：

注意：這裡範圍查詢第一個點並不一定精確到剛剛好5分鐘前的那個時序樣本點，他是以5分鐘作為一個區間，尋找這個區間的第一個點到最後一個樣本點。

時間單位：

同樣支援類似SQL中的offset查詢，如下：查詢一天前當前5分鐘前的時序資料集：

（三）內建函式

Prometheus內建了很多函式，這裡主要記錄下常用的幾個函式的使用：

rate和irate函式：rate函式可以用來求指標的平均變化速率。

一般rate函式可以用來求某個時間區間內的請求速率，也就是我們常說的QPS。

但是rate函式只是算出來了某個時間區間內的平均速率，沒辦法反映突發變化，假設在一分鐘的時間區間裡，前50秒的請求量都是0到10左右，但是最後10秒的請求量暴增到100以上，這時候算出來的值可能無法很好的反映這個峰值變化。

這個問題可以透過irate函式解決，irate函式求出來的就是瞬時變化率。

可以透過影像看下兩者的區別：irate函式的影像峰值變化大，rate函式變化較為平緩。

rate函式

irate函式

聚合函式：Sum() by() without()

也是上邊的例子，我們在求指定介面的QPS的時候，可能會出現多個例項的QPS的計算結果，如下是存在多個介面，三個服務的QPS。

利用sum函式可以將三個QPS聚合，即可得到整個服務該介面的QPS：其實Sum就是將指標值做相加。

但是這樣直接的相加太籠統抽象了，可以配合by和without函式在sum的時候，基於某些標籤分組，類似SQL中的 group by

例如，我可以根據請求介面標籤分組：這樣拿到的就是具體介面的QPS：

也可以不根據介面路徑分組：透過without指定：

可以透過 histogram_quantile函式做資料統計：可以用來統計百分位數：第一個引數是百分位，第二個histogram指標，這樣計算出來的就是中位數，即P50。

分享之前和同事一起發現的坑：

在剛剛寫的自定義 exporter上新增幾個 histogram的樣本點：

histogram的桶設定：

如果這樣的話，所有指標都會直接進入到第一個桶，即0到2.5這個桶，如果我要計算中位數，那麼這個中位數按照數學公式來算的話，肯定是在0到2.之間的，而且肯定是0.3到0.5之間。

我用 histogram_quantile函式計算下：計算結果是1.25，其實已經不對了。

我在計算下P99，等於2.475：

我的指標都是不大於1的，為啥算出來的P50和P99都這麼離譜呢？

這是因為 Prometheus他是不儲存你具體的指標數值的，他會幫你把指標放到具體的桶，但是他不會儲存你指標的值，計算的分位數是一個預估的值，怎麼預估呢？

就是假設每個桶內的樣本分佈是均勻的，線性分佈來計算的，比如剛剛的P50，其實就是算排在第50%位置的樣本值，因為剛剛所有的資料都落在了第一個桶，那麼他在計算的時候就會假定這個 50%值在第一個桶的中點，他就會假定這個數就是0.5_ 2.5，P99就是第一個桶的99%的位置，他就會假定這個數就是 0.99 _ 2.5。

導致這個誤差較大的原因就是我們的bucket設定的不合理。

重新定義桶：

上報資料：

重新計算 P50，P99：

桶設定的越合理，計算的誤差越小。

六、Grafana視覺化

除了可以利用 Prometheus提供的webUI視覺化我們的指標外，還可以接入 Grafana來做指標的視覺化。

第一步，對接資料來源：

配置好 prometheus的地址：

第二步：建立儀表盤

編輯儀表盤：

在 metrics處編寫PromQL即可完成查詢和視覺化：

儀表盤編輯完後，可以匯出對應的 json 檔案，方便下次匯入同樣的儀表盤：

以上是我之前搭建的儀表盤：

七、監控告警

AlertManager是 prometheus提供的告警資訊下發元件，包含了對告警資訊的分組，下發，靜默等策略。配置完成後可以在webui上看到對應的告警策略資訊。告警規則也是基於PromQL進行定製的。

編寫告警配置：當 Http_srv這個服務掛了， Prometheus採集不到指標，並且持續時間1分鐘，就會觸發告警。

在 prometheus.yml中配置告警配置檔案，需要配置上 alertmanager的地址和告警檔案的地址。

配置告警資訊，例如告警傳送地址，告警內容模版，分組策略等都在 alertmanager的配置檔案中配置：

當我kill程式：

prometheus已經觸發告警：

在等待1分鐘，如果持續還是符合告警策略，則狀態為從 pending變為 FIRING會傳送郵件到我的郵箱

此時我的郵箱收到了一條告警訊息：

alertmanager也支援對告警進行靜默，在 alertmanager的 WEBUI中配置即可：

間隔了4分鐘，沒有收到告警，靜默生效：

一個小時沒有收到告警資訊：

參考資料：