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會把服務發現剝離出來用一個組件來單獨做。
Kubernetes實戰培訓
Kubernetes實戰培訓將於2020年12月25日在深圳開課，3天時間帶你係統掌握Kubernetes，學習效果不好可以繼續學習。本次培訓包括：雲原生介紹、微服務；Docker基礎、Docker工作原理、鏡像、網絡、存儲、數據卷、安全；Kubernetes架構、核心組件、常用對象、網絡、存儲、認證、服務發現、調度和服務質量保證、日誌、監控、告警、Helm、實踐案例等，點擊下方圖片或者閱讀原文鏈接查看詳情。
