奇技指南隨著Openstack集群規模越來越大，監控數據呈現指數級增長，給后期計算、存儲資源擴容帶來了極大的考驗。如何穩定、永久存儲監控數據、快速查詢熱數據與歷史數據一直是大規模云計算集群存在的問題，當然Openstack社區的Ceilom

奇技指南

隨著 Openstack 集群規模越來越大，監控數據呈現指數級增長，給后期計算、存儲資源擴容帶來了極大的考驗。如何穩定、永久存儲監控數據、快速查詢熱數據與歷史數據一直是大規模云計算集群存在的問題，當然Openstack 社區的 Ceilometer 、Gnocchi、Aodh項目也未能很好解決我們目前存在的問題，在這里作者將介紹CNCF大殺器， Thanos + Prometheus TP組合（PS：并不是銀彈）在Openstack與ceph集群中的概念和使用，將對以上問題作出有效的答復。

Thanos 是什么

英國游戲技術公司 Improbable 開源了他們的Prometheus 高可用解決方案。主頁上簡單易懂一段英文介紹如下：Open source, highly available Prometheus setup with long term storage capabilities。開源，高可用性的Prometheus 設置，并提供長期存儲能力。

Thanos 有哪些特點

1. 跨Prometheus 服務并提供統一的查詢接口。
2. 無限期的存儲監控指標。目前支持S3、微軟Azure、騰訊COS、Google GCP、Openstack Swift 等對象存儲系統。
3. 兼容現有的Prometheus API 接口 ，例如 Grafana 或者支持 Pormetheus Query API 等工具。
4. 提供數據壓縮功能和降準采樣，提升查詢速度。
5. 重復數據刪除和合并，并從Pormetheus HA 集群中收集指標。

Thanos 架構

Thanos 架構中的組件

Compact

Compac提供數據降準和壓縮功能，主要負責針對S3存儲中的對象進行壓縮，可以將歷史數據中的Block合并壓縮成大文件對象。實際上降準壓縮并未節省任何空間，而且會在原始的Block增加2個塊，但是在查詢歷史數據時會提升查詢速度。最后注意的是，由于進程運行時對中間數據進行處理，故本地需要足夠的磁盤空間，隨著數據增多空間需求越來越大，目前我們預留300GB 本地空間用作壓縮中間數據的處理，并每三天進行一次壓縮。

Querier

查詢組件通過實現Pormetheus HTTP v1 API功能，組件接收到HTTP的PromSQL 查詢請求后負責將數據查詢和匯集。它是一個無狀態的服務，支持水平擴展。

SideCar

此組件需要和Pormetheus 實例一起部署，它主要起到兩個作用，第一代理Querier 組件對本地Prometheus數據讀取；第二是將Prometheus 本地監控數據通過對象存儲接口上傳到對象存儲中。最后sidecar 會監視Prometheus的本地存儲，若發現有新的監控數據保存到磁盤，會將這些監控數據上傳至對象存儲。

Store

Store 主要提供查詢歷史數據功能，當Querier組件調用Stroe 接口，Stroe 再通過對象存儲接口獲取數據，并將存儲數據轉換成Querier所需的數據格式。

Bucket

用于檢查對象存儲中的數據命令，通常作為獨立命令運行并幫助我們進行故障排查，支持通過Web UI 查看目前Buket的數量。

Check

通過Thanos check 可以檢查和驗證Pormetheus Rules 是否正確，實現函數如下。

//定義檢查Rules函數 func checkRules(logger log.Logger, filename string) (int, errors.MultiError) {   //記錄日志，返回檢測的文件名稱和詳細的日志信息     level.Info(logger).Log("msg", "checking", "filename", filename)    checkErrors := errors.MultiError{}    b, err :=     //讀取Rules文件      ioutil.ReadFile(filename)    if err != nil {             checkErrors.Add(err)      return 0, checkErrors  }   //由于rules 格式需要純Yaml格式，需要驗證Yaml 格式是否正確     var rgs ThanosRuleGroups   if err := yaml.UnmarshalStrict(b, &rgs); err != nil {      checkErrors.Add(err)        return 0, checkErrors    }   // We need to convert Thanos rules to Prometheus rules so we can use their validation.    promRgs := thanosRuleGroupsToPromRuleGroups(rgs)     if errs := promRgs.Validate(); errs != nil {         for _, e := range errs {             checkErrors.Add(e)       }         return 0, checkErrors   }        numRules := 0    for _, rg := range rgs.Groups {      numRules += len(rg.Rules)    }   //函數結尾返回檢查的rules 數量和錯誤的數量及錯誤信息    return numRules, checkErrors }

Thanos 實踐中我們遇到的問題

由于Thanos Store 啟動時會加載可以訪問的數據，他會在本地磁盤或者內存中加載少量的對象存儲的塊信息，隨著時間的推移會造成本地磁盤和內存的爆滿，導致集群異常，并引入如下多個問題。大量查詢緩慢導致內存暴增并出現Store OOM。前期我們使用POD 方式部署Thanos集群，由于POD改變后IP發生變化，導致集群腦裂并崩潰，最后無法查詢歷史數據?？紤]到Stroe組件比較消耗資源，我們將其轉移到物理機上，Sidecar 和Pormetheus放入POD 當中。由于早期的版本性能比較差，我們將版本也進行了升級，并啟用壓縮功能。

啟用壓縮功能后：

9月28日至11月07日產生的監控數據量：

目前集成監控場景如下：

1. Ceph / Cephfs 、Lvs、Openstack、Etcd、K8s 、Istio 、Openstack 虛機監控。
2. 提供API 查詢接口與StackStorm 聯動處理指定事件信息。

總結

Thanos 方案本身對于Prometheus 沒有任何強勢侵入，并增強了Prometheus的短板。最后Thanos 依賴于對象存儲系統，這部分的資源盡量要考慮。目前線上包含了約40+套 Openstack，70+ 套的Ceph集群，約10000 +的OSD 節點數量，每天約產生約50G 監控數據。

Thanos 幫忙解決了哪些問題

1. 由于存儲大小的限制，歷史數據存儲的時間的問題 First Blood。
2. 集群數量越來越多，Prometheus 查詢性能出現卡頓 double kill。
3. Openstack 、ceph 集群數量比較多，無法通過統一的接口去查詢數據和告警 triple kill。

關于360技術：360技術是360技術團隊打造的技術分享公眾號，每天推送技術干貨內容，更多技術信息歡迎關注“360技術”微信公眾號