Prometheus作為雲原生時代最流行的監控元件，已然成為社群監控的實際標準，擁有活躍的社群和豐富的周邊專案。但在多叢集，大叢集等場景下，Prometheus由於沒有分片能力和多叢集支援，難以滿足生產需求。本文從Prometheus的單叢集監控開始，介紹包括Prometheus的基本概念，基本原理，基於聯邦架構的多叢集監控，基於Thanos的多叢集監控，及基於Kvass的大叢集監控等內容。
另外本文中的Kvass（https：//github。com/tkestack/kvass）專案是我們團隊近期開源的Prometheus分片技術，目前已被Thanos社群作為Thanos推薦的使用案例加入到官網文件中。歡迎大家給專案點贊，參與開發，或者提Issue給我們。
Prometheus基本原理
簡介
大家應該對Prometheus或多或少有點了解，這裡簡單介紹一下，Prometheus是當前最流行的開源多維監控解決方案，集採集，儲存，查詢，告警於一身。其擁有強大的PromSQL語句，可進行非常複雜的監控資料聚合計算，甚至支援關係型聚合。其基本架構如下圖所示。
圖可能有點複雜，我簡單總結如下：
從配置檔案載入採集配置
透過服務發現探測有哪些需要抓取的物件
週期性得往抓取物件發起抓取請求，得到資料
將資料寫入本地盤或者寫往遠端儲存
基本概念
為了大家閱讀後面的內容，這裡介紹一些基本的概念術語。
Job：Prometheus的採集任務由配置檔案中一個個的Job組成，一個Job裡包含該Job下的所有監控目標的公共配置，比如使用哪種服務發現去獲取監控目標，比如抓取時使用的證書配置，請求引數配置等等。
Target：一個監控目標就是一個Target，一個Job透過服務發現會得到多個需要監控的Target，其包含一些label用於描述Target的一些屬性。
relabel_configs：每個Job都可以配置一個或多個relabel_config，relabel_config會對Target的label集合進行處理，可以根據label過濾一些Target或者修改，增加，刪除一些label。relabel_config過程發生在Target開始進行採集之前，針對的是透過服務發現得到的label集合。
metrics_relabel_configs： 每個Job還可以配置一個或者多個metrics_relabel_config，其配置方式和relabel_configs一模一樣，但是其用於處理的是從Target採集到的資料中的label。
Series：一個Series就是指標名 label集合，在面板中，表現為一條曲線。
head series： Prometheus會將近2小時的Series快取在內測中，稱為head series。
特別注意relable和metrics_relable的區別，前者在抓取前進行，是Target的屬性。
基本原理
有些小夥伴可能對Prometheus原理不太瞭解，這節簡單介紹其核心原理。
服務發現：Prometheus週期性得以pull的形式對target進行指標採集，而監控目標集合是透過配置檔案中所定義的服務發現機制來動態生成的。
relabel：當服務發現得到所有target後，Prometheus會根據job中的relabel_configs配置對target進行relabel操作，得到target最終的label集合。
採集：進行完上述操作後，Prometheus為這些target建立採集迴圈，按配置檔案裡配置的採集間隔進行週期性拉取，採集到的資料根據Job中的metrics_relabel_configs進行relabel，然後再加入上邊得到的target最終label集合，綜合後得到最終的資料。
儲存： Prometheus不會將採集到的資料直接落盤，而是會將近2小時的series快取在內測中，2小時後，Prometheus會進行一次資料壓縮，將記憶體中的資料落盤。
服務發現 ==> targets ==> relabel ==> 抓取 ==> metrics_relabel ==> 快取 ==> 2小時落盤。
單叢集監控方案
我們先從單個小叢集的監控方案開始，這也是絕大多數Prometheus的使用場景。
主流的指標
對於單個叢集，社群主流的指標來源於以下幾個元件，Prometheus將從他們獲取資料。
Kube-state-metrics：這個元件用於監控Kubernetes資源的狀態，比如Pod的狀態。原理是將Kubernetes中的資源，轉換成Prometheus的指標，讓Prometheus來採集。比如Pod的基本資訊，Serivce的基本資訊。
Node-exporter：用於監控Kubernetes節點的基本狀態，這個元件以DeamonSet的方式部署，每個節點一個，用於提供節點相關的指標，比如節點的cpu使用率，記憶體使用率等等。
cAdvisor：這個元件目前已經整合到kubelet中了，它提供的是每個容器的執行時指標，比如一個容器的CPU使用率，記憶體使用率等等。
Kubernetes相關元件： 比如apiserver，controller-manager，scheduler，kubelet等，主要提供每個元件核心功能相關的指標，比如QPS等等。
部署架構
單叢集架構非常簡單，如圖所示。使用這種方式，就可以將叢集的節點，元件，資源狀態，容器執行時狀態都給監控起來。
多叢集場景的特點
如果我們現在有多個叢集，並希望他們的監控資料儲存到一起，可以進行聚合查詢，用上述部署方案顯然是不夠的，因為上述方案中的Prometheus只能識別出本叢集內的被監控目標，即服務發現無法跨叢集。另外就是網路限制，多個叢集之間的網路有可能是不通的，這就使得即使在某個叢集中知道另一個叢集的Target地址，也沒法去抓取資料。總結多叢集的特點主要有：
服務發現隔離
網路隔離
只用Prometheus能解決嗎？
答案其實是能，用聯邦。
Prometheus支援拉取其他Prometheus的資料到本地，稱為聯邦機制。這樣我們就可以在每個叢集內部署一個Prometheus，再在他們之上部署一個Top Prometheus，用於拉取各個叢集內部的Prometheus資料進行彙總。
聯邦的問題在哪?
聯邦的方案也是社群所認可的，在叢集規模普遍較小，整體資料量不大的情況下，聯邦的方案部署簡單，理解成本低，沒有其他元件的引入，是一個很不錯的選擇。
但是聯邦也有其問題。由於所有資料最終都由Top Prometheus進行儲存，當總資料量較大的時候，Top Prometheus的壓力將增大，甚至難抗重負，另外，每個叢集中的Prometheus實際上也會儲存資料（Prometheus2。x 不支援關閉本地儲存），所以實際上出現了資料無意義冗餘。總結而言，聯邦的問題主要是：
Top Prometheus壓力大
資料有無意義冗餘
使用Thanos實現多叢集監控
Thanos簡介
Thanos是一款開源的Prometheus 高可用解決方案，其支援從多個Prometheus中查詢資料並進行彙總和去重，並支援將Prometheus本地資料傳送到雲上物件儲存進行長期儲存。官方架構圖太複雜，不便於理解，這裡給一個簡化版本。
Query：Query代理Prometheus作為查詢入口，它會去所有Prometheus，Store以及Ruler查詢資料，彙總並去重。
Sidecar：將資料上傳到物件儲存，也負責接收Thanos Query的查詢請求。
Ruler：進行資料的預聚合及告警。
Store： 負責從物件儲存中查詢資料。
部署方案
使用Thanos來替代聯邦方案，我們只需要將上圖中的Prometheus和Thanos sidecar部署到Kubernetes叢集中，將Thano Query等元件部署在原來Top Prometheus的位置即可。
相比聯邦的優勢
使用Thanos相比於之前使用聯邦，擁有一些較為明顯的優勢：
由於資料不再儲存在單個Prometheus中，所以整體能承載的資料規模比聯邦大。
資料不再有不必要的冗餘。
由於Thanos有去重能力，實際上可以每個叢集中部署兩個Prometheus來做資料多副本。
可以將資料儲存到物件儲存中，相比儲存在本地，能支援更長久的儲存。
大叢集場景的特點
上邊我們介紹了基於Thanos的監控系統，那如果不是多叢集，而是單個大叢集的場景怎麼辦？
大叢集場景的特點很明顯，那就是資料規模大，無論是target的規模，還是資料量，都是一個Prometheus無法採集的，得分片。
只用Thanos能解決嗎
答案還是能，用hasmod。
Prometheus支援在配置檔案中加入hashmod，透過某個label的值來進行hash，讓每個Prometheus只採集部分target，例如按target的地址進行hashmod，讓target採集任務分散到3個Prometheus中。這樣每個Prometheus就只會採集部分target，從而達到分片效果。由於每個分片的hashmod取值不一樣，所以每個分片需要使用單獨的配置檔案。
hashmod的方案有什麼問題
雖然使用hashmod的方式在一定程度上可以將負載分散到多個Prometheus中，但是其至少存在以下問題：
配置管理複雜：由於每個分片都要有單獨的配置檔案，需要維護多份配置檔案
配置項有侵入：需要為每個Job考慮hashmod的方式，而且需要清楚所採集資料根據那個label來hash才可能平均，對使用者相當不友好。
可能出現熱點：hashmod是不保證負載一定均衡的，因為如果多個數據規模較大的target被hashmod到一個分片，這個分片就有可能OOM。
Thanos沒解決的問題
雖然Thanos提供了統一查詢和高可用的支援，但是其並沒有提供Prometheus分片方案，而是由使用者自行分片，例如使用上邊介紹的hashmod。
那能不能只使用一個配置檔案還不需要hashmod呢，這就需要使用Kvass專案提供的能力。
加入Kvass實現大叢集監控
Kvass簡介
Kvass是一個Prometheus橫向擴縮容解決方案，他使用Sidecar動態得根據Coordinator分配下來的target列表來為每個Prometheus生成只含特定target的配置檔案，從而將採集任務分散到各個Prometheus分片。Coordinator用於服務發現，target分配和分片擴縮容管理。Thanos（或者其他TSDB）用來將分片資料彙總成全域性資料是官方文件中Thanos的典型用法：https：//thanos。io/tip/operating/use-cases。md/
簡單來說，就是由獨立元件（Coordinator）做服務發現，並把target集合及資料規模提前探測出來，直接分配給幾個Prometheus去抓，分片不再進行服務發現了。
部署方案
我們在Thanos方案中加入Kvass，就可以使用原來的配置檔案去監控大叢集，而不需要加入任何hashmod相關的東西嗎，配置檔案也不需要多個。
相比hashmod的優勢
使用Kvass方案，相比於hashmod有明顯的優勢：
配置管理簡單：無需針對配置檔案做任何特殊工作，單一小叢集時候怎麼用，現在就怎麼用。
負載可控：由於Kvass在向分片配置target的時候，會根據target的實際規模來，而不是透過hashmod來，所以每個分片的總負載會被控制在一個閾值以下，不會出現某個分片OOM的情況。
自動擴縮容：Kvass會根據當前叢集的規模，動態調整分片個數。
總結
剛才我們首先介紹了Prometheus的基本原理，並介紹了最為常用的使用Prometheus監控單一小叢集的方案。
隨後，針對多叢集場景，我們還談了聯邦方式與Thanos方式各有什麼優缺點。
面對大叢集場景時，我們談了Thanos未解決的問題，並介紹如何用hashmod的方案來監控大叢集。最後，我們使用Kvass彌補了Thanos的不足，不需要hashmod就能將Prometheus進行了分片。
Q&A
Q：資料是怎麼儲存的？
A：近期資料我們是使用雲上CBS進行儲存，長期資料用了雲上物件儲存。
Q：如果想將Prometheus用於生產環境，基於Prometheus封裝自己的圖形化配置工具是否有必要（比如阿里雲的Prometheus服務），還是讓運維學會自己手動配置檔案？（純內網環境）
A：我覺得這兩個不衝突。但是還是建議先學會手動配檔案，這樣對原生的配置會更加了解，圖形化配置工具我理解價值在於簡化具體監控物件的配置，比如直接選擇一個Service的EP進行監控，而不需要配置複雜的服務發現。
Q：如何解決high cardinality問題？
A：這個問題是由於資料來源資料不合理導致，系統層面會透過限制series總數來處理，不過這次分享的架構中，不包含多組戶隔離的部分哦。
Q：您在Prometheus遠端儲存這塊兒有什麼推薦嗎，目前就覺得InfluxDB合適，但是InfluxDB開源的只有單機版本。
A：InfluxDB確實只有單機版本，但是實際上你可以加個Proxy做分片的，或者直接使用其他DB如M3。
Q：Kubernetes中deployment的自定義label標籤透傳給cAdvisor，然後由Prometheus採集Metric時帶入到採集項中？
A：cAdvisor中不包含deployment上的label，這個需要透過PromSQL來將cAdvisor的指標和kube-state-metrics提供的相關指標聚合來獲得。
Q：Prometheus磁碟空間依靠什麼特性來監控？在搭一套麼？
A：這個可以自監控（但不推薦），如果有比較完善的基礎設施（即Prometheus執行在其之上），就可以用基礎設施的監控，如果沒有，確實需要根據實際情況去搭建一個。
Q：現在監控指標數是什麼量級？查詢透過什麼來做，Thanos嗎？查詢的速度如何？網路方向除了Node/Container的網路流量監控外，還應該關注哪些監控指標？
A：我們有多個叢集，目前其中一個大概2000w series左右規模，也不是最大的一個，用的Thanos Query，查詢速度得看查詢的資料規模，基本上排障沒問題。網路的具體指標這個不好意思我不太清楚。
Q：如何處理Pod漂移問題？
A：我們使用的是彈性容器來部署監控元件，沒有Pod漂移問題哦。如果擔心有Pod漂移，建議部署2副本。
Q：Job的數量會影響prom的記憶體消耗嗎？發現多個Job配置服務發現時記憶體有暴漲的現象。
A：會的，在Prometheus的實現裡，每個Job服務發現是獨立的，而且其實服務發現挺佔記憶體，這就是為什麼Kvass會把服務發現剝離出來用一個元件來單獨做。
Q：多個Job都使用了服務發現，Prometheus記憶體是否增長？
A：會的，在Prometheus的實現裡，每個Job服務發現是獨立的，而且其實服務發現挺佔記憶體，這就是為什麼Kvass會把服務發現剝離出來用一個元件來單獨做。
原文地址：https：//www。sohu。com/a/437544685_198222
