Prometheus 的重要性和流行度已經無需多言。直入主題，本文對 Prometheus 監控平臺的各個元件做深度講解，希望能幫助讀者更好地理解 Prometheus。
監控系統的核心邏輯
對於一套監控系統而言，核心就是採集資料並儲存，然後做告警判定、資料展示分析，這個 專欄文章 詳細講解了這個資料流架構，整個流程圖如下：
Prometheus 有多個元件（或者說多個程序），協同工作。下面我們逐個元件做一概述：
- https://github.com/prometheus/prometheus：這是 prometheus 程序的程式碼倉庫，功能包括抓取遠端監控指標、儲存時序資料、暴露查詢介面支援資料查詢、支援告警規則配置並做告警判定
- https://github.com/prometheus/alertmanager：這是 alertmanager 程序的程式碼倉庫，功能包括接收 prometheus 產生的告警事件，對事件做去重、分組、路由、通知等操作
我把監控系統的流程圖給變換一下顏色：
- prometheus 程序承接了圖中藍色功能，即：採集器、時序庫、告警判定引擎
- alertmanager 程序負責告警事件分發，即圖中紅色部分
- 資料展示分析，橙色部分，Prometheus 做的比較少，Prometheus 確實有一個簡單的 Web UI，不過比較簡陋，一般使用更為強大的 Grafana 來做資料展示分析
大家可能還聽過各類 Exporter，難道這些 Exporter 就沒有一席之地了麼？Exporter 也是很重要的，可以看做是一個介面卡，把監控目標的指標暴露出來，讓 Prometheus 來抓取。或者把 Exporter 看做是採集器的一部分也行，無傷大雅，理解整個資料流就可以，無需在詞彙上糾結。
想象一下，假設你有一個 Application，一個 Go 程式或者 Java Spring Boot 程式，Application 把自身的執行狀態指標透過 /metrics 介面暴露出來，Prometheus 直接抓取即可，這裡不需要什麼 Exporter。但是一些成熟的資料庫、中介軟體，比如 MySQL，Redis，這些軟體沒有直接暴露 Prometheus 格式的指標，Prometheus 沒法直接來抓取，怎麼辦呢？當然，可以完善 Prometheus 的抓取器，讓他不僅可以抓取 HTTP 協議的 /metrics 資料，也可以抓取 MySQL、Redis 等的資料，但是這樣的話，Prometheus 程式碼會變得臃腫，不利於維護。所以，Prometheus 採用了 Exporter 的設計，Exporter 就是一個介面卡，使用 Exporter 去抓取這些監控目標的指標，然後暴露為 Prometheus 格式的指標，Prometheus 再去抓取這些 Exporter 暴露的指標。這樣做的好處是，Prometheus 程式碼保持簡潔，Exporter 程式碼可以獨立維護，提升整體可維護性。而且 Exporter 可以發動全網力量，讓大家共建，一舉多得。
但是，Exporter 會有很多不同的程序，水平參差不齊，從部署的角度可能略麻煩，所以市面上也有一些開源專案，把眾多 Exporter 整合在一起變成一個程序，比如 Grafana-agent、Cprobe，當然，還有大名鼎鼎的 OpenTelemetry 也是這個思路。
瞭解了上述知識，我們再來看 Prometheus 官網的架構圖。
Prometheus 架構
- Prometheus Server：是 prometheus 程序的一部分功能，負責資料的抓取、儲存、HTTP 介面查詢
- Retrieval：資料抓取，從監控目標那裡拉取監控指標，Prometheus 定義了一個標準協議，只要監控目標支援這個協議，Prometheus 就可以抓取
- TSDB：時序庫，Prometheus 會把抓取到的監控指標儲存在本地，單點的。如果想要高可用，可以使用 Thanos、VictoriaMetrics 等
- HTTP server：Prometheus 會暴露 HTTP 介面，供外部查詢監控指標
- Service Discovery：服務發現，是 prometheus 程序的一部分功能，Prometheus 會定期去服務發現元件那裡拉取監控目標的列表，省去了手動配置的繁瑣，當然，前提是這些監控目標得註冊到服務發現元件上
- Kubernetes SD：基於 Kubernetes 的服務發現機制，比如透過 apiserver 拉取 pod 列表、service 列表作為監控目標
- File SD：基於檔案的服務發現機制，從配置檔案中讀取監控目標列表
- HTTP SD：基於 HTTP 的服務發現機制，從 HTTP 介面中讀取監控目標列表
- Consul SD：基於 Consul 的服務發現機制，從 Consul 中讀取監控目標列表
- 等等
- Pushgateway：是一個單獨的程序，用於接收短生命週期的監控指標，比如批處理任務的監控指標，因為批處理任務通常不會暴露 HTTP 介面，Prometheus 就沒法拉取了，所以批處理任務需要主動推送監控指標到 Pushgateway，Prometheus 再去拉取 Pushgateway 的監控指標
- Alertmanager：負責接收 prometheus 產生的告警事件，對事件做去重、分組、路由、通知等操作。如果想要更高階的收斂、降噪、排班、認領、升級等功能，可以把 Alertmanager 和一些第三方工具結合使用，比如 PagerDuty、FlashDuty、OpsGenie 等
- Prometheus web UI：prometheus 程序啟動之後，會暴露一個簡單的 Web UI，可以檢視監控指標，但是功能比較簡陋，一般使用 Grafana 來做資料展示分析
- Grafana：是一個獨立的程序，不屬於 Prometheus 專案的一部分，不過可以和 Prometheus 整合。用於資料展示分析，功能非常強大，支援多種資料來源，比如 Prometheus、Elasticsearch、Loki 等，支援多種圖表型別，比如折線圖、柱狀圖、餅圖、熱力圖等
Prometheus 架構的問題
主要問題的容量擴充套件問題。Prometheus 一個程序幹了很多事情，部署非常簡單，弊端就是單點沒法擴充套件，比如告警引擎是單點、儲存是單點、採集是單點，如果體量很大或者對穩定性要求比較高，就需要透過其他手段來解決了。
比如 VictoriaMetrics 專案，就是完全相容 Prometheus 生態的協議和介面，但是提供了分散式能力。儲存使用 vmstorage 程序，查詢使用 vmselect 程序，資料接收使用 vminsert，告警使用 vmalert，資料抓取使用 vmagent，元件確實多了，但是每個元件都可以部署多個例項組成叢集，提升了整體的可用性和容量。VictoriaMetrics 專案的架構圖如下：
或者還有一個辦法，就是直接部署多套 Prometheus，比如 DBA 自己用一個 Prometheus，Hadoop 團隊自己用一個 Prometheus，這樣可以解決容量問題，沒法解決資料單點儲存問題。如何解決單點問題？雙寫！比如 DBA 團隊，部署兩個 Prometheus，採集相同的資料，兩個 Prometheus 資料相同，規則相同，告警也會產生兩份，可以透過 Alertmanager 做告警去重，這樣就解決了單點問題。
Prometheus 規則管理問題
最後一個問題，簡單聊聊 Prometheus 的規則管理問題。Prometheus 的規則是透過配置檔案定義的，這個配置檔案是一個 yaml 檔案，裡面定義了監控規則、告警規則等。如果一個公司有很多套 Prometheus，規則分散在多個 yaml 中不方便管理，希望能有一套易用的、許可權隔離的 UI，把監控能力開放給全公司各個團隊並讓他們自服務，別啥事都來找監控團隊，這個時候就需要一個規則管理系統，比如夜鶯（Nightingale）。如果有這方面的痛點可以去了解一下，如果 Prometheus 自身的玩法就感覺夠用了，那更好，不用再引入新的元件。
小結
文字詳細介紹了 Prometheus 監控平臺的各個元件，希望能幫助讀者更好地理解 Prometheus。使用任何一個開源專案，都要了解其原理，這樣才能瞭解其最佳實踐，出了問題也能有排查思路。切莫只是解決一些表面問題，得過且過，這樣是不會有長進的，35歲之後，容易被幹。