2.7 集群

2.7.1 聯邦

為了擴展單個 Prometheus 的采集能力和存儲能力，Prometheus 引入了“聯邦”的概念。

多個 Prometheus節點組成兩層聯邦結構，如圖2-16所示。上面一層是聯邦節點，負責定時從下面的Prometheus節點獲取數據并匯總，部署多個聯邦節點是為了實現高可用；下層的 Prometheus 節點又分別負責不同區域的數據采集，在多機房的事件部署中，下層的每個Prometheus節點都可以被部署到單獨的一個機房，充當代理。

這種架構不僅降低了單個Prometheus的采集負載，而且通過聯邦節點匯聚核心數據，也降低了本地存儲的壓力。為了避免下層Prometheus的單點故障，也可以部署多套 Prometheus 節點，只是在效率上會差很多，每個監控對象都會被重復采集，數據會被重復保存。

這種聯邦方案并不是最完善的解決方案，原因如下：

◎ 這種配置方式相對復雜，缺少統一的全局視圖；

◎ 對歷史數據的存儲問題仍未得到徹底解決，必須依賴第三方存儲，并且缺少針對歷史數據的降準采樣能力；

◎ Prometheus在設計之初的定位就是一款實時監控系統，這是根本原因。

2.7.2 Thanos

針對Prometheus這些不足，Improbable開源了他們的Prometheus高可用解決方案 Thanos。Thanos和 Prometheus無縫集成，并為 Prometheus帶來了全局視圖和不受限制的歷史數據存儲能力。

在 Thanos 產生前，在 Improbable 公司內部存在多套 Kubernetes 容器集群，每個集群都部署了一套獨立的 Prometheus，再通過 Grafana 之類的展現工具分別查看每個集群的資源，缺乏一個全局資源視圖；另一方面，Prometheus的高可用需要得到保證，需要一套數據備份方案及歷史數據存儲方案。在這種背景下，Thanos出現了。

1.Thanos的4個組件

Thanos的整體架構如圖2-17所示，它主要有4個組件：Querier、Sidercar、Store和Compactor。

每個 Prometheus節點都配置了一個 Sidercar組件，Prometheus通過 Kubernetes的部署，可以將 Sidercar容器和 Prometheus容器集成到一個 Pod中。Sidercar組件有兩個主要作用，一是用來代理 Querier 對 Prometheus 本地數據的讀取，二是將Prometheus本地監控數據通過對象存儲接口保存到對象存儲中。

Querier接收 HTTP的 PromQL查詢，組件負責數據查詢匯聚。當 Querier收到一個請求時，它會向相關Sidecar發送GRPC查詢請求，Sidercar再去調用Prometheus的 API 并返回獲取的監控數據，Querier 將這些數據聚合在一起，并對它們執行PromQL查詢。

為了持久化歷史數據，Sidercar 會監控 Prometheus 的本地存儲，如果發現有新的監控數據保存到磁盤，則將這些監控數據保存到S3對象存儲上；相應地，在查詢數據時，如果需要查詢歷史數據，則 Querier會調用 Store的接口，Store再通過 S3對象存儲接口獲取數據，Store會將S3的對象數據轉化為Querier所需的數據格式。

Compactor是一個批處理組件，主要負責針對S3的對象壓縮，可以將歷史的小對象（block，塊）合并壓縮成大文件對象，對齊數據并且刪除這些小文件，從而節省存儲占用。

2.節點發現

Querier會通過Store API獲取每一個Sidecar上的監控數據。為了讓Querier找到Sidecar節點，Thanos引入了Gossip。

Thanos的每個組件之間都通過Gossip通信，這樣不僅可以動態添加、刪除組件節點，還可以在每個節點之間共享元數據信息，但這是有代價的：

（1）Gossip本身比較復雜，維護成本較高；

（2）Gossip全互聯NN的方式沒有必要存在，因為對于Querier來說，它只需知道所有實現的Store API節點即可；

（3）Gossip底層采用UDP和TCP，如果在網絡中只有七層負載均衡，那么會非常尷尬。

所以，Thanos 正逐漸淘汰這種做法，而使用基于文件或者 DNS 的方式完成節點注冊和發現。

3.歷史數據存儲

Sidercar可以將本地數據保存到對象存儲中。這里簡單回顧Prometheus 2.0的數據存儲方式，Prometheus 將監控數據按照時間順序以 block 方式進行劃分并存儲到磁盤中，在每個block內部通過index索引chunks里面的監控數據，如圖2-18所示。

Thanos的 Sidecar目前只支持 Prometheus 2.0版本以后的數據格式，Sidecar每隔30s 讀取一次本地元數據，查看是否有新的監控數據落盤，如果有，則讀取本地數據塊并將其上傳到對象存儲，標記最新的讀取時間并且通過本地 JSON 文件保存已經上傳的塊，避免重復上傳。

4.歷史數據降準

對歷史數據的檢索通常需要通過降準方式進行：如果檢索一天的數據，則通常以h或者10min為準度；如果檢索一個月的數據，則通常以 d或者 h為準度；如果檢索一年的數據，則準度更低。

Thanos會將原始的監控數據降準匯聚，將初始以30s為周期采集的監控數據經過兩次壓縮后，匯聚成以1h為周期的數據，過程如圖2-19所示。

數據降準的方式比較簡單，需要匯聚 count（個數）、sum（總和）、min（最小值）和max（最大值），如下所述。

◎ count指將這個壓縮時間段內的監控指標個數求和。

◎ sum指對監控指標的數值求和。

◎ avg可以通過sum/count求取。

◎ min和max分別是這個時間段內監控的最大值和最小值。

Thanos方案本身對于Prometheus沒有任何侵入，可以很好地擴展，但其本身依賴對象存儲服務，這部分成本也是需要考慮的。