Promethues 之 Thanos
- 2021 年 1 月 15 日
- 筆記
- Prometheus, 監控
Promethues簡介和原理
請看我之前寫的 Prometheus簡介,原理和安裝
//www.cnblogs.com/you-men/p/12839535.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，規範最重要，生產線能流暢的運轉不是代碼寫的有多好「當然這個也很重要」，是各個接口之間的規範、文檔、代碼中的注釋、要不換了人擼你代碼、搞你系統的時候咋弄。意識習慣才是重要的，技術好壞是個人意識，習慣才是個人修養。
