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

一、簡介

Prometheus是古希臘神話裡泰坦族的一名神明，名字的意思是“先見之明”，下圖中是Prometheus被宙斯懲罰，飽受肝臟日食夜長之苦。

下面就是我們CRUD Boy所瞭解的Prometheus，下面是其官網封面圖引導語： From metrics to insight ，從指標到洞察力，透過指標去洞察你的系統，為我們的系統提供指標收集和監控的開源解決方案。

也就是說，Prometheus是一個資料監控的解決方案，讓我們能隨時掌握系統執行的狀態，快速定位問題和排除故障。

Prometheus發展速度很快，12年開發完成，16年加入CNCF，成為繼K8s 之後第二個CNCF託管的專案，目前Github 42k的?，而且社群很活躍，維護頻率很高，基本穩定在1個月1個小版本的迭代速度。

二、整體生態

Prometheus提供了從指標暴露，到指標抓取、儲存和視覺化，以及最後的監控告警等一系列元件。

（一）指標暴露

每一個被Prometheus監控的服務都是一個Job，Prometheus為這些Job 提供了官方的SDK ，利用這個SDK可以自定義並匯出自己的業務指標，也可以使用Prometheus官方提供的各種常用元件和中介軟體的Exporter（比如常用的MySQL，Consul等等）。

對於短時間執行的指令碼任務或者不好直接 Pull指標的服務，Prometheus提供了PushGateWay閘道器給這些任務將服務指標主動推Push到閘道器，Prometheus再從這個閘道器裡Pull指標。

（二）指標抓取

上面提到了Push和Pull，其實這是兩種指標抓取模型。

Pull模型： 監控服務主動拉取被監控服務的指標。

被監控服務一般透過主動暴露 metrics 埠或者透過 Exporter 的方式暴露指標，監控服務依賴服務發現模組發現被監控服務，從而去定期的抓取指標。

Push模型： 被監控服務主動將指標推送到監控服務，可能需要對指標做協議適配，必須得符合監控服務要求的指標格式。

對於 Prometheus中的指標抓取，採用的是Pull模型，預設是一分鐘去拉取一次指標，透過 Prometheus.yaml配置檔案中的 scrape_interval配置項配置， Prometheus對外都是用的Pull模型，一個是 Pull Exporter的暴露的指標，一個是 Pull PushGateway暴露的指標。

（三）指標儲存和查詢

指標抓取後會儲存在內建的時序資料庫中， Prometheus也提供了PromQL 查詢語言給我們做指標的查詢，我們可以在 Prometheus的WebUI上透過 PromQL，視覺化查詢我們的指標，也可以很方便的接入第三方的視覺化工具，例如 grafana。

（四）監控告警

prometheus提供了 alertmanageer基於promql來做系統的監控告警，當promql查詢出來的指標超過我們定義的閾值時， prometheus會傳送一條告警資訊到 alertmanager，manager會將告警下發到配置好的郵箱或者微信。

三、工作原理

Prometheus的從被監控服務的註冊到指標抓取到指標查詢的流程分為五個步驟：

（一）服務註冊

被監控服務在 Prometheus中是一個Job存在，被監控服務的所有例項在 Prometheus中是一個target的存在，所以被監控服務的註冊就是在 Prometheus中註冊一個Job和其所有的target，這個註冊分為： 靜態註冊和動態註冊。

靜態註冊： 靜態的將服務的IP和抓取指標的埠號配置在 Prometheus yaml檔案的 scrape_configs配置下:

以上就是註冊了一個名為 prometheus 的服務，這個服務下有一個例項，暴露的抓取地址是 localhost:9090 。

動態註冊： 動態註冊就是在 Prometheus yaml檔案的 scrape_configs配置下配置服務發現的地址和服務名， Prometheus會去該地址，根據你提供的服務名動態發現例項列表，在 Prometheus中，支援consul，DNS，檔案，K8s等多種服務發現機制。基於consul的服務發現：我們consul的地址就是： localhost:8500 ，服務名是 node_exporter ，在這個服務下有一個 exporter 例項： localhost:9600 。

注意：如果是動態註冊，最好加上這兩配置，靜態註冊指標拉取的路徑會預設的幫我們指定為 metrics_path:/metrics，所以如果暴露的指標抓取路徑不同或者是動態的服務註冊，最好加上這兩個配置。

不然會報錯 “INVALID“ is not a valid start token，演示下，百度了一下，這裡可能是資料格式不統一導致。

最後可以在webUI中檢視發現的例項：

目前， Prometheus 支援多達二十多種服務發現協議：

（二）配置更新

在更新完 Prometheus的配置檔案後，我們需要更新我們的配置到程式記憶體裡，這裡的更新方式有兩種，第一種簡單粗暴，就是重啟 Prometheus，第二種是動態更新的方式。如何實現動態的更新Prometheus配置。

第一步：首先要保證啟動 Prometheus的時候帶上啟動引數： --web.enable-lifecycle 第二步：去更新我們的 Prometheus 配置:

第三步：更新完配置後，我們可以透過Post請求的方式，動態更新配置：

原理：

Prometheus在web模組中，註冊了一個 handler：透過 h.reload 這個 handler 方法實現：這個 handler 就是往一個 channle 中傳送一個訊號：

在main函式中會去監聽這個channel，只要有監聽到訊號，就會做配置的reload，重新將新配置載入到記憶體中。

（三）指標抓取和儲存

Prometheus對指標的抓取採取主動Pull的方式，即週期性的請求被監控服務暴露的 metrics介面或者是 PushGateway，從而獲取到 Metrics指標，預設時間是15s抓取一次，配置項如下：抓取到的指標會被以時間序列的形式儲存在記憶體中，並且定時刷到磁碟上，預設是兩個小時回刷一次。並且為了防止 Prometheus 發生崩潰或重啟時能夠恢復資料， Prometheus 也提供了類似MySQL中binlog一樣的預寫日誌，當 Prometheus 崩潰重啟時，會讀這個預寫日誌來恢復資料。

四、Metric指標

（一）資料模型

Prometheus採集的所有指標都是以時間序列的形式進行儲存，每一個時間序列有三部分組成：

指標名和指標標籤集合： metric_name{<label1=v1>,<label2=v2>....}，指標名：表示這個指標是監控哪一方面的狀態，比如 http_request_total表示：請求數量；指標標籤，描述這個指標有哪些維度，比如 http_request_total這個指標，有請求狀態碼 code= 200/400/500，請求方式： method=get/post等，實際上指標名稱實際上是以標籤的形式儲存，這個標籤是name，即： name=。
時間戳：描述當前時間序列的時間，單位：毫秒。
樣本值：當前監控指標的具體數值，比如 http_request_total的值就是請求數是多少。

可以透過檢視 Prometheus的 metrics介面檢視所有上報的指標：

所有的指標也都是透過如下所示的格式來標識的：

（二）指標型別

Prometheus底層儲存上其實並沒有對指標做型別的區分，都是以時間序列的形式儲存，但是為了方便使用者的使用和理解不同監控指標之間的差異， Prometheus定義了4種不同的指標型別：計數器 counter，儀表盤 gauge，直方圖 histogram，摘要 summary。

Counter計數器：

Counter型別和redis的自增命令一樣，只增不減，透過Counter指標可以統計Http請求數量，請求錯誤數，介面呼叫次數等單調遞增的資料。同時可以結合 increase和rate等函式統計變化速率，後續我們會提到這些內建函式。

Gauge儀表盤：

和 Counter不同，Gauge是可增可減的，可以反映一些動態變化的資料，例如當前記憶體佔用，CPU利用，Gc次數等動態可上升可下降的資料，在 Prometheus上透過Gauge，可以不用經過內建函式直觀的反映資料的變化情況，如下圖表示堆可分配的空間大小：

上面兩種是數值指標，代表資料的變化情況， Histogram和 Summary是統計型別的指標，表示資料的分佈情況。

Histogram直方圖：

Histogram是一種直方圖型別，可以觀察到指標在各個不同的區間範圍的分佈情況，如下圖所示：可以觀察到請求耗時在各個桶的分佈。

有一點要注意的是， Histogram是累計直方圖，即每一個桶的是隻有上區間，例如下圖表示小於0.1毫秒（ le=“0.1”）的請求數量是18173個，小於 0.2毫秒（ le=“0.2”)的請求是 18182 個，在 le=“0.2”這個桶中是包含了 le=“0.1”這個桶的資料，如果我們要拿到0.1毫秒到0.2毫秒的請求數量，可以透過兩個桶想減得到。在直方圖中，還可以透過 histogram_quantile 函式求出百分位數，比如 P50，P90，P99等資料。

Summary摘要

Summary也是用來做統計分析的，和 Histogram區別在於， Summary直接儲存的就是百分位數，如下所示：可以直觀的觀察到樣本的中位數，P90和P99。 Summary 的百分位數是客戶端計算好直接讓 Prometheus 抓取的，不需要 Prometheus 計算，直方圖是透過內建函式 histogram_quantile 在 Prometheus 服務端計算求出。

（三）指標匯出

指標匯出有兩種方式，一種是使用 Prometheus社群提供的定製好的 Exporter對一些元件諸如MySQL，Kafka等的指標作匯出，也可以利用社群提供的 Client來自定義指標匯出。

自定義 Prometheus exporter：訪問：，即可看到匯出的指標，這裡我們沒有自定義任何的指標，但是能看到一些內建的Go的執行時指標和promhttp相關的指標，這個Client預設為我們暴露的指標， go_ ：以 go_ 為字首的指標是關於Go執行時相關的指標，比如垃圾回收時間、 goroutine 數量等，這些都是Go客戶端庫特有的，其他語言的客戶端庫可能會暴露各自語言的其他執行時指標。 promhttp_ ：來自 promhttp 工具包的相關指標，用於跟蹤對指標請求的處理。