Promethues 之 Thanos

Promethues簡介和原理

請看我以前寫的 Prometheus簡介,原理和安裝
http://www.javashuo.com/article/p-yozmouno-bd.html

官方架構問題

官方架構存在一個最大的問題數據量一上去須要儘快拆分，例如在使用中發現Es的Export會拉取大量metrics直接致使單機Prom不堪重負「io巨高」固然指標太多也不是好事這個會在最後討論下若是避免，因此須要拆分集羣「此處不討論官方的聯邦策略，這個擴展性並無那麼好，依然須要拆分多套聯邦集羣」

順着正常思路咱們必定是先拆分集羣，我也沒有逃出這個方法開始着手拆分，拆了歷史數據還在老集羣還要搬數據大量的Ops工做啊「哪怕寫了自動化腳本，回車仍是要人敲的吧」，拆完了看着不錯哦，可是另外的問題來了，要通知Dev咱們拆了地址變了，隨之而來的是大量的通知「心很累」。metrics仍是不少總不能沒事就拆吧，並且歷史保留時間咱們是7天慢慢發現用戶要查7天前的就再見了「沒法支持」。

固然咱們也有聯邦集羣，在聯合部署中，全局Prometheus服務器能夠在其餘Prometheus服務器上聚合數據，這些服務區可能分佈在多個數據中心。每臺服務器只能看到一部分度量指標。爲了處理每一個數據中心的負載，能夠在一個數據中心內運行多臺Prometheus服務器，並進行水平分片。在分片設置中，從服務器獲取數據的子集，並由主服務器對其進行聚合。在查詢特定的服務器時，須要查詢拼湊數據的特定從服務器。默認狀況下，Prometheus存儲15天的時間序列數據。爲了無限期存儲數據，Prometheus提供了一個遠程端點，用於將數據寫入另外一個數據存儲區。不過，在使用這種方法時，數據去重是個問題。其餘解決方案（如Cortex）提供了一個遠程寫入端點和兼容的查詢API，實現可伸縮的長期存儲。

綜上問題主要是：拆分之痛、全局查詢、數據去重、歷史數據查詢、AlertManager無高可用
**
業務發展快不是Ops推脫的理由，某天躺在牀上刷刷微信發現神器盡然已經有了「雖然還只是一個測試版本」Thanos，果斷開始調研發現能夠啊基本解決了上面說起的多個痛點。「團隊中也來兩個了新的小夥伴 Go專職研發、監控系統小達人、感謝兩位的幫助」心中無比激動，開始動手了。

Thanos是啥

Improbable團隊開源了Thanos，一組經過跨集羣聯合、跨集羣無限存儲和全局查詢爲Prometheus增長高可用性的組件。Improbable部署了一個大型的Prometheus來監控他們的幾十個Kubernetes集羣。默認的Prometheus設置在查詢歷史數據、經過單個API調用進行跨分佈式Prometheus服務器查詢以及合併多個Prometheus數據方面存在困難。

Thanos經過使用後端的對象存儲來解決數據保留問題。Prometheus在將數據寫入磁盤時，邊車的StoreAPI組件會檢測到，並將數據上傳到對象存儲器中。Store組件還能夠做爲一個基於gossip協議的檢索代理，讓Querier組件與它進行通訊以獲取數據。

Thanos還提供了時間序列數據的壓縮和降採樣（downsample）存儲。Prometheus提供了一個內置的壓縮模型，現有較小的數據塊被重寫爲較大的數據塊，並進行結構重組以提升查詢性能。Thanos在Compactor組件（做爲批次做業運行）中使用了相同的機制，並壓縮對象存儲數據。Płotka說，Compactor也對數據進行降採樣，「目前降採樣時間間隔不可配置，不過咱們選擇了一些合理的時間間隔——5分鐘和1小時」。壓縮也是其餘時間序列數據庫（如InfluxDB和OpenTSDB）的常見功能。

Thanos經過一種簡單的可無縫接入當前系統的方案解決這些問題。其主要功能點經過Sidecar、Querier、Store和Compactor來實現，這裏作一個簡單介紹。

+
Tenant's Premise | Provider Premise
                 |
                 |            +------------------------+
                 |            |                        |
                 |  +-------->+     Object Storage     |
                 |  |         |                        |
                 |  |         +-----------+------------+
                 |  |                     ^
                 |  | S3 API              | S3 API
                 |  |                     |
                 |  |         +-----------+------------+
                 |  |         |                        |       Store API
                 |  |         |  Thanos Store Gateway  +<-----------------------+
                 |  |         |                        |                        |
                 |  |         +------------------------+                        |
                 |  |                                                           |
                 |  +---------------------+                                     |
                 |                        |                                     |
+--------------+ |            +-----------+------------+              +---------+--------+
|              | | Remote     |                        |  Store API   |                  |
|  Prometheus  +------------->+     Thanos Receiver    +<-------------+  Thanos Querier  |
|              | | Write      |                        |              |                  |
+--------------+ |            +------------------------+              +---------+--------+
                 |                                                              ^
                 |                                                              |
+--------------+ |                                                              |
|              | |                PromQL                                        |
|    User      +----------------------------------------------------------------+
|              | |
+--------------+ |
                 +

把Prometheus的數據弄一份存到Min io, Prometheus裏面默認保存24小時

Sidecar

Sidecar做爲一個單獨的進程和已有的Prometheus實例運行在一個server上，互不影響。Sidecar能夠視爲一個Proxy組件，全部對Prometheus的訪問都經過Sidecar來代理進行。經過Sidecar還能夠將採集到的數據直接備份到雲端對象存儲服務器。「會消耗原有實例所在集羣的資源，上線前能夠先把原有server機器升配下」

Querier

全部的Sidecar與Querier直連，同時Querier實現了一套Prometheus官方的HTTP API從而保證對外提供與Prometheus一致的數據源接口，Grafana能夠經過同一個查詢接口請求不一樣集羣的數據，Querier負責找到對應的集羣並經過Sidecar獲取數據。Querier自己也是水平可擴展的，於是能夠實現高可部署，並且Querier能夠實現對高可部署的Prometheus的數據進行合併從而保證屢次查詢結果的一致性，從而解決全局視圖和高可用的問題。「配合雲的AutoScaling」

Store

Store實現了一套和Sidecar徹底一致的API提供給Querier用於查詢Sidecar備份到雲端對象存儲的數據。由於Sidecar在完成數據備份後，Prometheus會清理掉本地數據保證本地空間可用。因此當監控人員須要調取歷史數據時只能去對象存儲空間獲取，而Store就提供了這樣一個接口。Store Gateway只會緩存對象存儲的基本信息，例如存儲塊的索引，從而保證明現快速查詢的同時佔用較少本地空間。

Comactor

Compactor主要用於對採集到的數據進行壓縮，實現將數據存儲至對象存儲時節省空間。

Ruler

Ruler主要是管理多個AlertManager告警規則配置統一管理的問題「推薦使用集羣版本的AlertManager，多個AlertManager以前放一個SLB便可」

Thanos優勢

優勢

對比官方的解決方案，這個東西能夠支持跨集羣查詢、數據去重、歷史數據查詢、告警規則統一管理，固然還有別的你們本身腦補。

Thanos問題

store開始只能查詢8次還不記得多少次就不行了，還有查詢實例時間長了也不行了，須要注意「讓研發哥哥解決了，如何解決的回頭再放出來，最近官方新發布，貌似修改的這個問題，須要測試下。」使用的是Ceph「其實s3和oss也是能夠的，只要支持s3協議便可」，ceph也有坑「這個我不懂了，有專人盯着的這邊不討論」，sidecar組件若是啓動在原有就很忙的Prometheus邊上以前須要謹慎「把原有OOM過一次」，建議仍是先拆了再搞。此組件已經引發官方關注，預祝早日合併到官方去。

容器外&容器內

大機率的不少同窗確定存在容器外面與容器內部兩套環境、或者多容器環境。這邊寫下不成熟的小建議系統給到各位幫助，實現方法有兩種「應該還有更多」，Thanos使用的是Gossip進行自動發現其實在容器內外發現上面仍是有點麻煩的。

**前提: **Thanos在容器裏面MacVlan模式，Pod分配固定IP，漂移時保持IP不變。「容器網絡不懂的，你們本身Google下」

SLB

經過k8s api定時判斷thanos所在pod狀況，若是發生變化調用雲的api進行slb更新。「笨辦法」

Cousul

萬物揭註冊原則，所有註冊到cousul上面去「其實仍是要本身寫一個小東西去完成註冊」

指標過多

這個問題其實很糾結，Export吐那麼多真的都能看的過來嗎，目測不可能，須要在Pull那邊作相應的控制，只看本身須要的其實對於Dev要求變高了。本身吐的麼更是要精準，我是一個DBA吧不少時候面試都會問我你看那些指標啊，CPU、內存、IO、鏈接數還不夠你看嗎，指標不是越多越好誰沒事都看一遍「閒得慌嗎，存着不是浪費計算資源嗎，DevOps的大環境下是否是Dev仍是須要一些基本看監控能力呢，不要變成只會打字的研發，不淘汰你淘汰誰呢……」

規範

依然要老生常談規範這個事情，不要一上來就喊着要秒級監控「真的不必 誰看啊」，定義到各個指標的命名規範其實比這套東西更爲重要 ，讓研發去理解其實很難的，你們都被業務壓的喘不過氣來，還有誰會去接受Ops的東西。

運維平臺竟可能融合這套東西中最麻煩的幾項好比，添加監控、添加告警儘量傻瓜式。定義到接口是Pull仍是Push，規範最重要，生產線能流暢的運轉不是代碼寫的有多好「固然這個也很重要」，是各個接口之間的規範、文檔、代碼中的註釋、要不換了人擼你代碼、搞你係統的時候咋弄。意識習慣纔是重要的，技術好壞是我的意識，習慣纔是我的修養。