熱門搜索 Zabbix技術資料 Zabbix常見問、答討論 成功案例 Zabbix交流區 Prometheus交流區
Prometheus作為新生代的開源監控系統，慢慢成為了云原生體系的監控事實標準，也證明了其設計得到業界認可。但在多集群，大集群等場景下，Prometheus由于沒有分片能力和多集群支持，還有Prometheus不支持長期存儲、不能自動水平縮、大范圍監控指標查詢會導致Prometheus服務內存突增等。本文從Prometheus的單集群監控開始，介紹包括Prometheus的基本概念，基于聯邦架構的多集群監控，基于Thanos的多集群監控等內容。
Prometheus的工作流程核心是，以主動拉取pull的方式搜集被監控對象的metrics數據（監控指標數據），并將這些metrics數據存儲到一個內存TSDB（時間序列數據庫）中，并定期將內存中的指標同步到本地硬盤。
基本架構如下圖所示
圖可能有點復雜，簡單總結如下：
從配置文件加載采集配置
周期性得往抓取對象發起抓取請求，得到數據
將數據寫入本地盤或者寫往遠端存儲
alertmanager從監控數據中發現異常數據做出報警
如果我們現在有多個集群，并希望他們的監控數據存儲到一起，可以進行聚合查詢，用上述部署方案顯然是不夠的，因為上述方案中的Prometheus只能識別出本集群內的被監控目標。另外就是網絡限制，多個集群之間的網絡有可能是不通的，這就使得即使在某個集群中知道另一個集群的地址，也沒法去抓取數據，要解決這些問題那就得用高可用方案。
HA：即兩套 Prometheus 采集完全一樣的數據，外邊掛負載均衡
HA + 遠程存儲：Prometheus通過 Remote write 寫入到遠程存儲
聯邦集群：即 Federation，按照功能進行分區，不同的 Shard 采集不同的數據，由 Global 節點來統一存放，解決監控數據規模的問題。
使用官方建議的多副本 + 聯邦仍然會遇到一些問題，本質原因是 Prometheus 的本地存儲沒有數據同步能力，要在保證可用性的前提下再保持數據一致性是比較困難的，基本的多副本 Proxy 滿足不了要求，比如：
1.Prometheus 集群的后端有 A 和 B 兩個實例，A 和 B 之間沒有數據同步。A 宕機一段時間，丟失了一部分數據，如果負載均衡正常輪詢，請求打到A 上時，數據就會異常。
2.如果A和B的啟動時間不同，時鐘不同，那么采集同樣的數據時間戳也不同，就多副本的數據不相同
3.就算用了遠程存儲，A 和 B 不能推送到同一個 TSDB，如果每人推送自己的 TSDB，數據查詢走哪邊就是問題
4.官方建議數據做 Shard，然后通過 Federation 來實現高可用，但是邊緣節點和 Global 節點依然是單點，需要自行決定是否每一層都要使用雙節點重復采集進行保活。也就是仍然會有單機瓶頸。
1.長期存儲：1 個月左右的數據存儲，每天可能新增幾十G，希望存儲的維護成本足夠小，有容災和遷移。最好是存放在云上的 TSDB 或者對象存儲、文件存儲上。
2.無限拓展：我們有上百集群，幾千節點，上萬個服務，單機 Prometheus 無法滿足，且為了隔離性，最好按功能做 Shard，如 Node機器監控與 K8S POD 資源等業務監控分開、主機監控與日志監控也分開，者按業務類型分開。
3.全局視圖：按類型分開之后，雖然數據分散了，但監控視圖需要整合在一起，一個Grafana 里n個面板就可以看到所有地域+集群的監控數據，操作更方便，不用多個Grafana的Dashboard 切來切去。
4.無侵入性：不會因為增加監控業務而重新加載Prometheus配置，因為重新加載Prometheus配置對Prometheus穩定是有風險的。
按照實例進行功能分區
從圖中看出，新增一臺機器上報的metrics只需在zookeeper注冊上報信息，prometheus自動發現新增的metrics，不需要重啟prometheus或者重新加載prometheus配置。
數據上報和查詢
Prometheus會以固定頻率去請求每個服務所提供的http url來獲取數據，每2小時為一個時間單位，首先會存儲到內存中，當到達2小時后，會自動寫入磁盤中，prometheus采用的存儲方式稱為“時間分片”，每個block都是一個獨立的數據庫。
thanos sidecar監控prometheus本地block的chunks文件，當chunks文件有增加時thanos sidecar會將chunks數據通過grpc上傳到thanos store，thanos store將接收到的數據落入S3云存儲。
grafana向thanos query發起查詢請求，thanos query從各個thanos sidecar拉取本地數據，并且通過thanos store從S3云存儲上拉取歷史數據，最后數據在thanos query進行匯總和去重返回給grafana。
如何保證架構穩定性
從數據上報和查詢流程圖中可以看到數據拉取和數據查詢是分開的，prometheus只負責部分機器的數據拉取，當grafana有歷史查詢的需求的時候（比如查詢三個月或者半年的數據），thanos query聚合后的數據存儲在內存返回給grafana，當數據比較大時，thanos query服務器內存會寫滿導致服務不可用，但是prometheus還在以固定頻率拉取metrics數據，這時候只需要重新恢復thanos query服務即可，不會對metrics數據連續性有任何影響。
Sidecar
Sidecar作為一個單獨的進程和已有的Prometheus實例運行在一個server上，互不影響。Sidecar可以視為一個Proxy組件，所有對Prometheus的訪問都通過Sidecar來代理進行。通過Sidecar還可以將采集到的數據直接備份到云端對象存儲服務器。
Query
所有的Sidecar與Query直連，同時Query實現了一套Prometheus官方的HTTP API從而保證對外提供與Prometheus一致的數據源接口，Grafana可以通過同一個查詢接口請求不同集群的數據，Query負責找到對應的集群并通過Sidecar獲取數據。Query本身也是水平可擴展的，因而可以實現高可部署，而且Query可以實現對高可部署的Prometheus的數據進行合并從而保證多次查詢結果的一致性，從而解決全局視圖和高可用的問題。
Store
Store實現了一套和Sidecar完全一致的API提供給Query用于查詢Sidecar備份到云端對象存儲的數據。因為Sidecar在完成數據備份后，Prometheus會清理掉本地數據保證本地空間可用。所以當監控人員需要調取歷史數據時只能去對象存儲空間獲取，而Store就提供了這樣一個接口。
Comactor
由于我們有數據長期存儲的能力，也就可以實現查詢較大時間范圍的監控數據，當時間范圍很大時，查詢的數據量也會很大，這會導致查詢速度非常慢。通常在查看較大時間范圍的監控數據時，我們并不需要那么詳細的數據，只需要看到大致就行。Thanos Compact 這個組件應運而生，它讀取對象存儲的數據，對其進行壓縮以及降采樣再上傳到對象存儲，這樣在查詢大時間范圍數據時就可以只讀取壓縮和降采樣后的數據，極大地減少了查詢的數據量，從而加速查詢。
可靠性
thanos sidecar 會記錄已經拉取過的prometheus chunk文件，在prometheus新生成chunk文件的時候thanos sidecar會通過thanos store同步chunk數據到S3云存儲，實現了metrics數據無限期保留，保證了數據的可靠性。
穩定性
Prometheus數據拉取和數據查詢拆分，不會因為大查詢導致Prometheus內存暴增后服務掛掉，影響數據拉取，出現metrics數據斷層。
可維護性
運維和開發人員不用修改prometheus配置，所有操作通過業務控制臺維護zookeeper數據完成。
可伸縮性
一臺Prometheus node節點只拉取幾十臺服務器的metrics數據，隨著業務規模的變化靈活調整Prometheus node節點的數量。
目前開源社區和市面上有很多Prometheus高可用方案，但是都不能完全滿足需求，隨著我們的集群規模越來越大，監控數據的種類和數量也越來越多。更多prometheus相關技術資料，請持續關注尊龍時凱社區和prometheus技術分享。
尊龍時凱項目團隊對客戶IT資源狀況進行梳理，確定項目所涉及的監控對象包括主機、網絡設備、數據庫、中間件、應用、業務系統、存儲、虛擬化等，決定為客戶打造以...
View details
尊龍時凱官網
