利用Prometheus 打造企業分佈式監控平臺(3)--遠程讀寫之戰

Prometheus遠程讀寫存儲是一個熱門話題，已經存在了數個系統（Cortex，M3DB，InfluxDB），而且在過去的幾個月中已經誕生了一些系統（Thanos，VictoriaMetrics）。每一個系統都有本身的架構和不一樣的使用場景。

一句話：成也Prometheus，敗也Prometheus。

Prometheus生態和體系太過優秀，致使拋開Prometheus，另起爐竈，從新建立一個輪子的難度很是之大。而正如第一篇文章所述，Prometheus自己tsdb的劣勢，又給了諸多系統機會。

至於這場戰爭，誰會笑到最後，目前來看不得而知。

目前Prometheus已經支持如下第三方系統的對接：

不過參差不齊，不少是一些實驗性的適配器。固然若是你剛好運行在公有云上，並且能承受監控存儲所帶來的成本，那麼使用公有云的時序存儲，是一個高枕無憂的方案。

接下來，我會重點介紹一下目前已經存在的，比較優秀的開源系統。這些系統均提供瞭如下的功能：

• 長期保存，任意保留。
• 從多個Prometheus實例收集的數據的全局查詢視圖。
• 水平可伸縮性。

Thanos

Thanos 也是一個CNCF基金會下管理的項目。Thanos利用Prometheus 2.0存儲格式以經濟高效的方式將歷史指標數據存儲在任何對象存儲中，同時保留快速查詢延遲;此外，它還提供了全部Prometheus安裝的全局查詢視圖，而且能夠即時合併Prometheus HA對中的數據。

Thanos 包括了以下的組件：

• Sidecar -- 它將與每一個Prometheus實例一塊兒部署並執行如下任務：1）將早於2小時的Prometheus數據上傳到對象存儲（例如Amazon S3或Google Cloud Storage）； 2）將對最近添加的數據的查詢處理到本地Prometheus（小於2小時）。
• Store gateway -- 處理對存儲在對象存儲（例如S3或GCS）中的數據的查詢。
• Query -- 實現Prometheus查詢API並針對從Sidecars和Stores得到的數據提供全局查詢視圖。
• Compact -- 默認狀況下，Sidecar將數據以2小時的塊上傳到對象存儲中，Compactor會逐漸將這些塊合併爲更大的塊，以提升查詢效率並減少所需的存儲大小。
• Rule -- 對從Query（又稱全局查詢視圖）得到的數據執行Prometheus記錄規則和警報規則。因爲Query及其底層組件的可靠性低，規則組件的故障率一般較高。
• Receiver -- 實驗性組件，能夠經過remote_write API接收來自Prometheus的數據。從Thanos v0.5.0開始，該組件還沒有準備就緒。

總體架構圖以下：

我的感受，Thanos 組件比較複雜，維護成本比較高，若是你在一些非雲的環境中，須要本身提供一套對象存儲。固然Minio（社區辦S3）多是你一個不錯的選擇。社區比較活躍。

Cortex

Cortex有是cncf基金會下管理的項目，Cortex由Weaveworks建立，是一個用於應用程序和微服務的開源時間序列數據庫和監視系統，基於Prometheus，Cortex增長了水平縮放和幾乎無限的數據保留。

• 它開箱即用地支持四個長期存儲系統：AWS DynamoDB，AWS S3，Apache Cassandra和Google Cloud Bigtable。
• 它提供了Prometheus時間序列數據的全局視圖，其中包括長期存儲的數據，從而大大擴展了PromQL用於分析目的的用途。
• 它的核心部份內置了多租戶。全部經過Cortex的Prometheus指標都與特定租戶相關聯。

Cortex包含的組件很是多，此處不一一介紹，你們能夠看下圖：

總體架構圖以下：

關於Cortex，是爲數很少的支持多租戶的TSDB。社區也比較活躍，不過其開發者已經跳槽到了grafana公司，開發了Loki日誌處理系統。此外Cortex的組件比Thanos都複雜。

M3

Uber開發了指標平臺M3和分佈式時間序列數據庫M3DB。來解決Uber在發展過程當中遇到的問題：使用開源軟件後，因爲可靠性，成本等問題，在操做密集型方面沒法大規模使用這些開源軟件。因此Uber逐步構建了本身的指標平臺。咱們利用經驗來幫助咱們構建本地分佈式時間序列數據庫，高度動態和高性能的聚合服務，查詢引擎以及其餘支持基礎架構。

M3包括了以下的組件：

• M3DB -- M3db是一個使用TSDB（時間數據庫），保存全部Prometheus指標，M3db是分佈式，高可用性和複製的數據庫，它使用Etcd做爲共識算法。
• M3Coordinator -- 是Prometheus實例與M3db之間的適配器，它公開了Prometheus用來從數據庫中推送和提取數據的讀/寫端點。
• M3Query -- 衆所周知，Prometheus努力處理顯示大量數據的查詢，而不是從Prometheus提取數據，M3Query實現了相同的PromQL並能夠響應此類請求。
• M3Aggregator -- 可選但很重要，此服務將下降指標的採樣率，爲長期存儲作好準備。

總體架構圖以下：

關於M3，咱們目前積累了一些生產實踐。目前的問題是，社區不夠活躍，文檔也不夠豐富。不少時候遇到問題，只能去研究代碼。M3query對PromSql支持的不夠，因此M3query並不能生產環境使用。

VictoriaMetrics

VictoriaMetrics是一種快速，經濟高效且可擴展的時間序列數據庫，可用做Prometheus的長期遠程存儲。

VictoriaMetrics 包括了以下的組件：

• vmstorage -- 存儲數據。
• vminsert -- 經過remote_write API接收來自Prometheus的數據並將其分佈在可用的vmstorage節點上。
• vmselect -- 經過從vmstorage節點獲取併合並所需數據，經過Prometheus查詢API執行傳入查詢。

每一個組件可使用最合適的硬件配置獨立擴展到多個節點。

總體架構圖以下：

上圖中與負載平衡器框一塊兒的VictoriaMetrics集羣框能夠在Kubernetes中運行，而且能夠經過Helm圖表進行管理。

該系統的優點是架構簡單，性能也比較高，依賴於塊存儲。可是數據沒有副本，有丟失數據的可能。爲此，爲你們提供了vmbackup和vmrestore組件。

若是咱們認爲咱們的監控數據是能夠容許丟失一部分，那麼這種VictoriaMetrics將很是值得投入。

總結

本文簡單介紹了Prometheus遠程讀寫存儲，並詳細介紹了幾種開源的遠程存儲方案。接下來，會專門介紹一下M3，介紹一下咱們實際生產中運行的實踐。