thanos

prometheus多集群監控方案

? 每個集群內部都部署一套單獨的prometheus，在通過grafana等展示工具分別查看每個集群的資源監控情況，如果保證資料的高可用，則每個集群還需要一套資料備份方案以及歷史資料存盤方案，

prometheus聯邦

聯邦實作

擴展單個prometheus的采集能力和存盤能力，多個prometheu組成聯邦，如下圖所示：

? 最上面一層prometheus是聯邦節點，負責從下面的prometheus中定時獲取資料并匯總，部署多個聯邦節點是為了實作高可用，下面一層的prometheus負責不同區域的資料采集，在多機房的部署架構中，每個prometheus又可以部署到單個機房，充當代理，
? 這種架構不僅降低了單個promtheus的采集壓力，而且通過聯邦匯聚核心資料，降低了本地存盤的壓力，為了避免下層prometheus的單點故障，可以部署多套prometheus節點，但是效率上會差很多，每個監控物件會被重復采集，資料會被重復保存，

聯邦方案的不足

1. 這種架構配置相對復雜，缺少統一的全域試圖
2. 對歷史存盤問題仍未得到解決，必須依賴第三方存盤，并且缺少針對歷史資料的降準采樣能力
3. Prometheus在設計之初就是一款實時的監控系統

Thanos

? Thanos是一組組件，可以組成具有長期存盤功能的高可用性Prometheus設定，其主要目標是簡化操作并保留Prometheus的可靠性，thanos依賴于prometheus,且僅支持prometheus2.0版本之后得資料格式，

Thanos的實作

Thanos架構圖如下圖所示，主要由四個組件組成：Querier、Slidercar、Store和Compactor，

Sidercar

每個prometheus節點都配置了一個Sidercar組件，通過K8S的部署可以將Prometheus和Sidercar容器集成到一個容器中，sidercar主要有兩個作用和一個后來新增的可選功能，一是用來代理Querier對Prometheus本地資料的讀取；二是將Prometheus本地的監控資料（一般是未壓縮的塊）通過物件存盤介面保存到物件存盤中，sidercar每30s讀取一次本地元資料，看是否有新的監控資料產生，如果有則讀取本地資料塊將其上傳到物件存盤，標記最新的讀取時間并且通過本地的JSON檔案保存相關資訊，包含塊的元資訊，例如統計資訊，時間范圍和壓碩訓別，避免重復上傳，還有一個可選功能，sidercar可以查看prometheus規則和配置，并在需要時解壓縮和替換環境變數，并ping prometheus以便重新加載規則和配置，

Querier

Querier是thanos實作多集群監控以及全域視圖的關鍵，
Querier接收HTTP的PromQL查詢，組件負責資料查詢匯聚，查詢流程如下圖：

簡而言之，就是從基礎StoreAPI收集評估查詢所需的資料，評估查詢并回傳結果，Querier是完全無狀態的并且可以水平擴展，Thanos Querier本質上允許在單個Prometheus Query端點下聚合和可選地對多個度量后端進行重復資料洗掉，
對于Querier來說，后端是實作gRPC StoreAPI的所有內容，因此我們可以從任意數量的不同存盤中聚合資料,例如：
* prometheus（需要包含sidercar）
* 物件存盤
* 記錄規則和警報規則
* 符合promtheus遠程讀寫的標準的資料庫
* 另外一個querier
* 非prometheus系統，例如OpenTSDB
querier不僅可以從多個后端獲取資料，將他們匯總還可以對其中的重復資料洗掉，必須為整個集群選擇固定的單 個或多個副本標簽，然后在啟動時將其傳遞給查詢節點，僅通過給定副本標簽區分的兩個或多個序列將合并為一個時間序列，這也掩蓋了單個資料源收集方面的差距，

Thanos公開的查詢API保證與Prometheus 2.x API兼容，但是，對于Prometheus之上的其他Thanos功能，Thanos添加了三個特色的功能：
* 部分反應行為
* 部分新增的引數欄位
* 自定義回應欄位，

1. 部分反應

querier可以從多個后端查詢資料，當其中的一個StoreAPI回傳錯誤或者超時，另兩個回傳成功結果（很可能出現），并不意味丟失資料，可能是因為出問題的StoreAPI沒有查詢到資料，則會匯聚有資料的查詢回傳，
如果發生部分回應，則StoreAPI會回傳可讀的警告，現在支持兩種策略：

• warn
• abort(默認)

如果可用性比準確性更重要，可以配置嚴苛的超視規則：

--query.timeout
--store.response-timeout

2. 新增的部分引數

Deduplication replica labels.

這將覆寫query.replica-label cli標志，以允許在查詢時使用動態副本標簽，

Deduplication Enabled

這控制是否應使用副本標簽對查詢結果進行重復資料洗掉，

Auto downsampling

最大源解析度是我們要用于查詢資料的最大解析度（以秒為單位）， This means that for value:

• 0 -> we will use only raw data.
• 5m -> we will use max 5m downsampling.
• 1h -> we will use max 1h downsampling.

Partial Response Strategy

// TODO(bwplotka): Update. This will change to “strategy” soon as PartialResponseStrategy enum here

如果為true，則所有將不可用的storeAPI（因此不回傳任何資料）將不會導致查詢失敗，而是回傳警告，

3. 自定義回應資料結構

type queryData struct {
	ResultType promql.ValueType `json:"resultType"`
	Result     promql.Value     `json:"result"`

	// Additional Thanos Response field.
	Warnings   []error          `json:"warnings,omitempty"`
}

Store

Store在物件存盤中的歷史資料之上實作StoreAPI,使物件存盤中的資料可以作為querier查詢的后端，Store主要有兩個作用，一個在物件存盤中資料實作StoreAPI,使物件存盤中的資料可以被查詢，二是充當一個API網關，可以負責所有storeAPI的服務發現，因此Store不需要大量的本地磁盤空間，它在啟動的時候加入thanos集群，并發布它可以安全訪問的資料，他在本地磁盤上保留有關所有遠程塊的少量資訊，并使它與桶同步，
通常，物件存盤桶中存盤的每個TSDB塊平均需要6 MB的本地磁盤空間，但是對于帶有大標簽集的高基數塊，它甚至可以增加到30MB甚至更多，它用于預先計算的索引，其中包括符號和發布偏移量以及元資料JSON

Store查詢物件存盤的歷史資料時，查看物件存盤中的所有資料，并根據查詢的時間范圍將其回傳，將物件存盤的資料轉化為Querier所需的資料格式，并且Thanos Store --min-time，–max-time標志使您可以基于恒定時間或相對于當前時間的持續時間對Thanos Store進行分片，
Thanos Store Gateway可能不會立即獲取新塊，因為時間劃分部分是在異步塊同步作業中完成的，默認情況下每3分鐘完成一次，此外，某些物件存盤實作還提供了最終的寫后讀一致性，這意味著Thanos Store可能不會立即獲得新創建和上載的塊，
建議與Thanos Sidecar和其他Thanos Store網關有重疊的時間范圍，因為這將提高您的故障應變能力，

Thanos Store Gateway支持索引快取，以加快從TSDB塊索引進行發布和系列查找的速度，支持兩種型別的快取：

• in-memory（默認）
• memcached

Compactor

Compator是一個批處理組件，主要針對物件存盤的資料壓縮，可以將歷史的小物件（block,塊）合并壓縮成大檔案物件，對其資料并且洗掉這些小檔案，從而節省存盤占用，通常，它在不是并發安全的，必須針對存盤桶以單例方式進行部署，并且由于沒有針對所有物件存盤提供的安全鎖定機制，因此，您現在需要自己確保只有單個Compactor針對單個存盤桶中的單個塊流運行，

Compator是thanos實作無限存盤的關鍵組件，

Compator主要有兩個作用，一個是負責對資料的壓縮，另一個是負責歷史資料的降準，

• 資料壓縮

Compator負責將多個塊壓縮成一個，跟prometheus中進行的減少塊數和壓縮索引的程序實一樣的，根據時間以及資料量的不斷增長，Compator將sidercar上傳的資料壓縮成2h的塊，然后在對歷史資料再進行壓縮，根據設定的步長倍數遞增，如果步數為3、步長為3，則會塊的大小分別為2h、6h、18h，資料量繼續增長，Compator會將小的block合成一個大的block從而節約空間，也便于對資料進行檢索，

• 資料降準

對歷史資料的檢索需要用降準的方式進行：如果檢索一天的資料，則通常以h或者10min中為維度；如果檢索一個月的資料，則通常以d或者h為準度，因為，在瀏覽器渲染資料的時候，如果檢索時間很長，維度很小，則代表著會有大量的資料，甚至會超過螢屏的像素顯示上限，從而失去意義，且網路的IO消耗，介面回應時間也會很高，所以需要將資料進行降準，
Thanos會將原始的監控資料降準匯聚，將初始30s為周期的監控資料講過兩次壓縮后，匯聚成以1h為周期的資料，第一次從30s進行10倍壓縮到5m，在進行12倍壓縮到1h，資料的降準比較簡單，需要匯聚 count(個數)、sum、min和max，

Compator對資源的要求比較高，尤其是記憶體
CPU：提供壓縮組時要使用的goroutine數的核數
記憶體：
記憶體使用情況取決于物件存盤中的塊大小和壓縮并發，
通常，最大記憶體利用率與用于壓縮程序的Prometheus完全相同：

對于考慮進行壓縮的每個源塊：
所有塊符號的1/32
所有塊的過帳偏移量的1/32
具有所有標簽和所有塊的單個系列，
您需要將此乘以X，其中X是–compaction.concurrency（所需要的goroutine數量，默認情況下為1），
通常，對于中型存盤桶，限制為10GB的記憶體足以保持其正常作業，

網路:
Compator是對物件存盤使用網路最多的組件，因此最好將其放在存盤桶的區域附近，他必須要下載壓縮/降準采樣所需要的每個塊，并在每次執行上傳壓縮/降準采樣完成的塊，還會經常重繪存盤桶的狀態，
磁盤
Compator需要本地磁盤空間來存盤中間資料以進行處理,以及對存盤桶狀態快取，通常，對于中型存盤桶，隨著壓縮時間范圍隨著時間的增長，大約100GB應該足以繼續作業，但是，這在很大程度上取決于塊的大小，在最壞的情況下，壓實機必須有足夠的空間來容納2個星期（如果您的最大壓實級別為2周）的2倍的較小塊來進行壓實，首先，下載所有這些源代碼塊，其次是基于由較小的源代碼組成的2周塊的磁盤輸出，

您需要將此乘以X，其中X是–compaction.concurrency（默認情況下為1）

thanos的服務發現

thanos的querier會通過StoreAPI獲取每一個sidercar的資料，那么首先需要發現sidercar，thanos引入了Gossip，現在已經不推薦使用，現在推薦使用的有三種：

• 靜態配置：配置在組件的組態檔中
• 檔案發現：將sidercar的資訊寫道檔案中，json或者yaml格式,然后通過監視檔案串列中的檔案變化，在發生更改時，將動態加載新配置，所有檔案重新讀取的間隔為5分鐘
• DNS服務發現（推薦）：DNS服務發現是用于查找可以與靜態標志或檔案SD結合使用的組件的另一種機制，使用DNS 服務發現，可以指定一個域名，并將定期查詢該域名以發現IP串列，

thanos支持的物件存盤串列

thanos實作無限存盤的主要資源物件，就是物件存盤，最好單例物件存盤，thanos將所有的歷史資料都存盤在物件存盤中，減少prometheus使用的本地存盤，使prometheus僅保存最近時間的資料，這樣既節省了資源的消耗，也提高了prometheus的效率，
目前thanos支持的物件存盤有：

相關參考

thanos的參考視頻：https://www.youtube.com/watch?v=qQN0N14HXPM&t=714s
thanos的專案地址：https://github.com/thanos-io/thanos
thanos官網：https://thanos.io/tip/thanos/design.md