共計 10120 個字符，預計需要花費 26 分鐘才能閱讀完成。
這篇文章主要講解了“怎么用 Prometheus 監控十萬 container 的 Kubernetes 集群”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著丸趣 TV 小編的思路慢慢深入，一起來研究和學習“怎么用 Prometheus 監控十萬 container 的 Kubernetes 集群”吧！
Prometheus
Prometheus 依靠其強勁的單機性能，靈活的 PromSQL，活躍的社區生態，逐漸成為云原生時代最核心的監控組件，被全球各大產商用于監控他們的核心業務。
然而，面對大規模監控目標（數千萬 series）時，由于原生 Prometheus 只有單機版本，不提供集群化功能，開發人員不得不通過不斷增加機器的配置來滿足 Prometheus 不斷上漲的內存。
單機性能瓶頸
我們對單機 Prometheus 進行的壓測，用以探測單個 Prometheus 分片的合理負載，壓測的目標有兩個。
確定 target 數目對 Prometheus 負載的關系
確定 series 數目和 Prometheus 負載的關系
target 相關性
我們保持總 series 為 100 萬不變，通過改變 target 個數，觀察 Prometheus 負載變動。壓測結果
target 數量 CPU (core)mem (GB)1000.174.65000.194.210000.163.950000.34.6
從表中我們發現 target 數目的改動對 Prometheus 負載的影響并不是強相關的。在 target 數目增長 50 倍的情況下，CPU 消耗有小量增長，但是內存幾乎不變。
series 相關性
我們保持 target 數目不變，通過改變總 series 數，觀察 Prometheus 的負載變動。
壓測結果
series 數量 (萬)CPU (core)mem (GB) 查詢 1000 series 15m 數據 (s)1000.1913.150.23000.93920.141.65002.02630.571.5
從表中，Prometheus 的負載受到 series 的影響較大，series 越多，資源消耗越大。
當 series 數據超過 300 萬時，Prometheus 內存增長較為明顯，需要使用較大內存的機器來運行。
壓測過程中，我們使用了工具去生成預期數目的 series，工具生成的 series 每個 label 的長度及值的長度都較小，固定為 10 個字符左右。我們的目的是觀察相對負載變化，實際生產中由于 label 長度不同，服務發現機制的消耗不同，相同的 series 數目所消耗的負載會比壓測中高不少。
現有集群化方案
針對單機 Prometheus 在大規模數據監控時的性能瓶頸問題，社區目前已經存在一些分片化方案，主要包括以下幾種。
hash_mod
Prometheus 官方支持通過 Relabel 機制，在配置文件中，對采集上來的數據進行 hash，通過在不同 Prometheus 實例的配置文件中指定不同的 moduleID 來進行分片化，然后通過聯邦，Thanos 等方式將數據進行統一匯總，如下圖所示，讀者也可以直接參考【官方文檔】。
配置文件分割
還有一種方法是根據業務進行 job 層面的分割，不同 Prometheus 使用完全獨立的采集配置，其中包含了不同的 job，。
上述方案存在的問題
無論是 hash_mod 的方式，還是配置文件分割的方式，其本質都是將數據切分到多個采集配置中，由不同 Prometheus 進行采集。兩者都存在以下幾個缺點。
** 對預監控數據要有所了解：** 使用上述方法的前提是使用者必須對監控對象會上報的數據有所了解，例如必須知道監控對象會上報某個用于 hash_mod 的 label，或者必須知道不同 job 的整體規模，才能對 job 進行劃分。
** 實例負載不均衡：** 雖然上述方案預期都是希望將數據打散到不同 Prometheus 實例上，但實際上通過某些 label 的值進行 hash_mod 的，或者干脆按 job 進行劃分的方式并不能保證每個實例最終所采集的 series 數是均衡的，實例依舊存在內存占用過高的風險。
** 配置文件有侵入：** 使用者必須對原配置文件進行改造，加入 Relabel 相關配置，或者將一份配置文件劃分成多份，由于配置文件不再單一，新增，修改配置難度大大增加。
** 無法動態擴縮容：** 上述方案中的由于配置是根據實際監控目標的數據規模來特殊制定的，并沒有一種統一的擴縮容方案，可以在數據規模增長時增加 Prometheus 個數。當然，用戶如果針對自己業務實際情況編寫擴縮容的工具確實是可以的，但是這種方式并不能在不同業務間復用。
** 部分 API 不再正常：** 上述方案將數據打散到了不同實例中，然后通過聯邦或者 Thanos 進行匯總，得到全局監控數據，但是在不額外處理的情況下會導致部分 Prometheus 原生 API 無法得到正確的值，最典型的是 /api/v1/targets，上述方案下無法得到全局 targets 值。
Kvass 的原理設計目標
針對上述問題，我們希望設計一種無侵入的集群化方案，它對使用者表現出來的，是一個與原生 Prometheus 配置文件一致，API 兼容，可擴縮容的虛擬 Prometheus。具體而言，我們有以下設計目標。
** 無侵入，單配置文件：** 我們希望使用者看到的，修改的都是一份原生的配置文件，不用加任何特殊的配置。
無需感知監控對象：我們希望使用者不再需要預先了解采集對象，不參與集群化的過程。
** 實例負載盡可能均衡：** 我們希望能根據監控目標的實際負載來劃分采集任務，讓實例盡可能均衡。
** 動態擴縮容：** 我們希望系統能夠根據采集對象規模的變化進行動態擴縮容，過程中數據不斷點，不缺失。
** 兼容核心 PrometheusAPI：** 我們希望一些較為核心的 API，如上邊提到的 /api/v1/target 接口是正常的。
架構
Kvass 由多個組件構成，下圖給出了 Kvass 的架構圖，我們在架構圖中使用了 Thanos，實際上 Kvass 并不強依賴于 Thanos，可以換成其他 TSDB。
Kvass sidecar: 用于接收 Coordinator 下發的采集任務，生成新的配置文件給 Prometheus，也服務維護 target 負載情況。
Kvass coordinator: 該組件是集群的中心控制器，負責服務發現，負載探測，targets 下發等。
Thanos 組件: 圖中只使用了 Thanos sidecar 與 Thanos query，用于對分片的數據進行匯總，得到統一的數據視圖。
Coordinator
Kvass coordinaor 首先會代替 Prometheus 對采集目標做服務發現，實時獲得需要采集的 target 列表。
針對這些 target，Kvass coordinaor 會負責對其做負載探測，評估每個 target 的 series 數，一旦 target 負載被探測成功，Kvass coordinaor 就會在下個計算周期將 target 分配給某個負載在閾值以下的分片。
Kvass coordinaor 還負責對分片集群做擴縮容。
服務發現
Kvass coordinaor 引用了原生 Prometheus 的服務發現代碼，用于實現與 Prometheus 100% 兼容的服務發現能力，針對服務發現得到的待抓取 targets，Coordinaor 會對其應用配置文件中的 relabel_configs 進行處理，得到處理之后的 targets 及其 label 集合。服務發現后得到的 target 被送往負載探測模塊進行負載探測。
負載探測
負載探測模塊從服務發現模塊獲得處理之后的 targets，結合配置文件中的抓取配置（如 proxy，證書等）對目標進行抓取，隨后解析計算抓取結果，獲得 target 的 series 規模。
負載探測模塊并不存儲任何抓取到的指標數據，只記錄 target 的負載，負載探測只對 target 探測一次，不維護后續 target 的負載變化，長期運行的 target 的負載信息由 Sidecar 維護，我們將在后面章節介紹。
target 分配與擴容
在 Prometheus 單機性能瓶頸那一節，我們介紹過 Prometheus 的內存和 series 相關，確切來說，Prometheus 的內存和其 head series 直接相關。Prometheus 會將最近（默認為 2 小時）采集到的數據的 series 信息緩存在內存中，我們如果能控制好每個分片內存中 head series 的數目，就能有效控制每個分片的內存使用量，而控制 head series 實際就是控制分片當前采集的 target 列表。
基于上邊的思路，Kvass coordinaor 會周期性的對每個分片當前采集的 target 列表進行管理：分配新 target，刪除無效 target。
在每個周期，Coordinaor 會首先從所有分片獲得當前運行狀態，其中包括分片當前內存中的 series 數目及當前正在抓取的 target 列表。隨后針對從服務發現模塊得到的全局 target 信息進行以下處理
如果該 target 已經被某個分片抓取，則繼續分配給他，分片的 series 數不變。
如果該 target 沒有任何分片抓取，則從負載探測模塊獲得其 series（如果還未探測完則跳過，下個周期繼續），從分片中挑一個目前內存中 series 加上該 target 的 series 后依然比閾值低的，分配給他。
如果當前所有分片沒法容納所有待分配的 targets，則進行擴容，擴容數量與全局 series 總量成正比。
target 遷移和縮容
在系統運行過程中，target 有可能會被刪除，如果某個分片的 target 被刪除且超過 2 小時，則該分片中的 head series 就會降低，也就是出現了部分空閑，因為 target 分配到了不同分片，如果有大量 target 被刪除，則會出現很多分片的內存占用都很低的情況，這種情況下，系統的資源利用率很低，我們需要對系統進行縮容。
當出現這種情時，Coordinaor 會對 target 進行遷移，即將序號更大的分片（分片會從 0 進行編號）中的 target 轉移到序號更低的分片中，最終讓序號低的分片負載變高，讓序號高的分片完全空閑出來。如果存儲使用了 thanos，并會將數據存儲到 cos 中，則空閑分片在經過 2 小時候會刪除（確保數據已被傳到 cos 中）。
多副本
Kvass 的分片當前只支持以 StatefulSet 方式部署。
Coordinator 將通過 label selector 來獲得所有分片 StatefulSet，每個 StatefulSet 被認為是一個副本，StatefulSet 中編號相同的 Pod 會被認為是同一個分片組，相同分片組的 Pod 將被分配相同的 target 并預期有相同的負載。
/api/v1/targets 接口
上文提到 Coordinator 根據配置文件做了服務發現，得到了 target 列表，所以 Coordinator 實際上可以得到 /api/v1/targets 接口所需要的返回結果集合，但是由于 Coordinator 只做了服務發現，并不進行實際采集，所以 target 的采集狀態（例如健康狀態，上一次采集時間等）都無法直接得知。
當 Coordinator 接收到 /api/v1/targets 請求時，他會基于服務發現得到的 target 集合，結合向 Sidecar（如果 target 已分配）或向探測模塊（target 還未分配）詢問 target 采集狀態，綜合后將正確的 /api/v1/targets 結果返回。
Sidecar
上一節介紹了 Kvass coordinaor 的基本功能，要想系統正常運行，還需要 Kvass sidecar 的配合，其核心思想是將配置文件中所有服務發現模式全部改成 static_configs 并直接將已經 relabel 過的 target 信息寫入配置中，來達到消除分片服務發現和 relabel 行為，只采集部分 target 的效果。
每個分片都會有一個 Kvass sidecar，其核心功能包括從 Kvass coordinator 接受本分片負責的 target 列表，生成新的配置文件給該分片的 Prometheus 使用。另外，Kvass sidecar 還會劫持抓取請求，維護 target 最新負載。Kvass sidecar 還作為 PrometheusAPI 的網關，修正部分請求結果。
配置文件生成
Coordinaor 經過服務發現，relabel 及負載探測后，會將 target 分配給某個分片，并將 target 信息下發給 Sidecar，包括
target 的地址，
target 預估的 series 值
target 的 hash 值
處理完 relabel 之后的 label 集合。
Sidecar 根據從 Coordinator 得到的 target 信息，結合原始配置文件，生成一個新的配置文件給 Prometheus 使用，這個新的配置文件做了如下改動。
將所有服務發現機制改為 static_configs 模式，并直接寫入 target 列表，每個 target 包含經過 relabel 之后的 label 值
由于現在 target 已經 relabel 過了，所以刪除 job 配置中的 relabel_configs 項，但是依舊保留 metrics_rebale_configs
將 target 的 label 中的 scheme 字段全部替換成 http，并將原 schme 以請求參數的形式加入到 label 集合中
將 target 的 job_name 以請求參數的形式加入到 label 集合中 * 注入 proxy_url 將所有抓取請求代理到 Sidecar
我們來看一個例子，假如原來的配置是一個 kubelet 的采集配置
global:
evaluation_interval: 30s
scrape_interval: 15s
scrape_configs:
- job_name: kubelet
honor_timestamps: true
metrics_path: /metrics
scheme: https
kubernetes_sd_configs:
- role: node
bearer_token: xxx
tls_config:
insecure_skip_verify: true
relabel_configs:
- separator: ;
regex: __meta_kubernetes_node_label_(.+)
replacement: $1
action: labelmap通過注入將生成一個新的配置文件
global:
evaluation_interval: 30s
scrape_interval: 15s
scrape_configs:
- job_name: kubelet
honor_timestamps: true
metrics_path: /metrics
scheme: https
proxy_url: http://127.0.0.1:8008 # 所有抓取請求代理到 Sidecar
static_configs:
- targets:
- 111.111.111.111:10250
labels:
__address__: 111.111.111.111:10250
__metrics_path__: /metrics
__param__hash: 15696628886240206341
__param__jobName: kubelet
__param__scheme: https # 保存原始的 scheme
__scheme__: http # 設置新的 scheme，這將使得代理到 Sidecar 的抓取請求都是 http 請求
# 以下是經過 relabel_configs 處理之后得到的 label 集合
beta_kubernetes_io_arch: amd64
beta_kubernetes_io_instance_type: QCLOUD
beta_kubernetes_io_os: linux
cloud_tencent_com_auto_scaling_group_id: asg-b4pwdxq5
cloud_tencent_com_node_instance_id: ins-q0toknxf
failure_domain_beta_kubernetes_io_region: sh
failure_domain_beta_kubernetes_io_zone: 200003
instance: 172.18.1.106
job: kubelet
kubernetes_io_arch: amd64
kubernetes_io_hostname: 172.18.1.106
kubernetes_io_os: linux上邊新生成的配置文件是 Prometheus 真正使用的配置文件，Sidecar 通過 Coordinator 下發的 target 列表來生成配置，就可以讓 Prometheus 有選擇性得進行采集。
抓取劫持
在上邊的配置生成中，我們會將 proxy 注入到 job 的配置中，并且 target 的 label 中，scheme 會被設置成 http，所以 Prometheus 所有的抓取請求都會被代理到 Sidecar，之所以要這么做，是因為 Sidecar 需要維護每個 target 新的 series 規模，用于 Coordinator 查閱后作為 target 遷移的參考。
從上邊配置生成我們可以看到，有以下幾個額外的請求參數會被一并發送到 Sidecar
hash：target 的 hash 值，用于 Sidecar 識別是哪個 target 的抓取請求，hash 值由 Coordinator 根據 target 的 label 集合進行計算獲得并傳遞給 Sidecar。
jobName：是哪個 job 下的抓取請求，用于 Sidecar 根據原配置文件中 job 的請求配置（如原 proxy_url，證書等）對抓取目標發起真正的請求。
scheme：這里的 scheme 是 target 通過 relabel 操作之后最終得到的協議值，雖然在 job 配置文件中已經有 scheme 字段，但 Prometheus 配置文件依舊支持通過 relabel 指定某個 target 的請求協議。在上述生成新配置過程中，我們將真實的 scheme 保存到這個參數里，然后將 scheme 全部設置成 http。
有了上述幾個參數，Sidecar 就可以對抓取目標發起正確的請求，并得到監控數據，在統計的 target 這次抓取的 series 規模后，Sidecar 會將監控數據拷貝一份給 Prometheus。
API 代理
由于 Sidecar 的存在，部分發往 Prometheus 的 API 請求需要被特殊處理，包括
/-/reload：由于 Prometheus 真正使用的配置文件由 Sidecar 生成，針對該接口，需要由 Sidecar 去處理并在處理成功后調用 Prometheus 的 /-/reload 接口。
/api/v1/status/config：該接口需要由 Sidecar 處理并把原配置文件返回。
其他接口直接發往 Prometheus。
全局數據視圖
由于我們將采集目標分散到了不同分片中，導致每個分片的數據都只是全局數據的一部分，所以我們需要使用額外的組件來將所有數據進行匯總并去重（多副本的情況下），得到全局數據視圖。
以 thanos 為例
thanos 是一個非常好的方案，通過加入 thanos 組件，可以很方便得得到 kvass 集群的全局數據視圖。當然我們也可以通過加入 remote writer 配置來使用其他 TSDB 方案，例如 influxdb，M3 等等。
使用例子
這一節我們通過一個部署例子，來直觀感受一下 Kvass 的效果，相關 yaml 文件可以在這里找到 https://github.com/tkestack/kvass/tree/master/examples 讀者可以將項目 clone 到本地，并進入 examples。
git clone https://github.com/tkestack/kvass.git
cd kvass/examples
部署數據生成器
我們提供了一個 metrics 數據生成器，可以指定生成一定數量的 series，在本例子中，我們將部署 6 個 metrics 生成器副本，每個會生成 10045 series (其中 45 series 為 golang 的 metrics)。
kubectl create -f metrics.yaml部署 kvass
現在我們部署基于 Kvass 的 Prometheus 集群，用以采集這 6 個 metrics 生成器的指標。
首先我們部署 rbac 相關配置
kubectl create -f kvass-rbac.yaml接著部署一個 Prometheus config 文件，這個文件就是我們的原始配置，我們在這個配置文件中，使用 kubernetes_sd 來做服務發現
kubectl create -f config.yaml配置如下
global:
scrape_interval: 15s
evaluation_interval: 15s
external_labels:
cluster: custom
scrape_configs:
- job_name: metrics-test
kubernetes_sd_configs:
- role: pod
relabel_configs:
- source_labels: [__meta_kubernetes_pod_label_app_kubernetes_io_name]
regex: metrics
action: keep
- source_labels: [__meta_kubernetes_pod_ip]
action: replace
regex: (.*)
replacement: ${1}:9091
target_label: __address__
- source_labels:
- __meta_kubernetes_pod_name
target_label: pod現在我們來部署 Kvass coordinator
kubectl create -f coordinator.yaml我們在 Coordinator 的啟動參數中設置每個分片的最大 head series 數目不超過 30000
–shard.max-series=30000
我們現在就可以部署帶有 Kvass sidecar 的 Prometheus 了，這里我們只部署單個副本
kubectl create -f prometheus-rep-0.yaml部署 thanos-query
為了得到全局數據，我們需要部署一個 thanos-query
kubectl create -f thanos-query.yaml查看結果
根據上述計算，監控目標總計 6 個 target, 60270 series，根據我們設置每個分片不能超過 30000 series，則預期需要 3 個分片。
我們發現，Coordinator 成功將 StatefulSet 的副本數改成了 3。
我們看下單個分片內存中的 series 數目，發現只有 2 個 target 的量 
我們再通過 thanos-query 來查看全局數據，發現數據是完整的（其中 metrics0 為指標生成器生成的指標名）
云原生監控
騰訊云容器團隊在 Kvass 的設計思想上進一步優化，構建了高性能支持多集群云原生監控服務，產品目前已正式公測。
大集群監控
這一節我們就直接使用云原生監控服務來監控一個規模較大的真實集群，測試一下 Kvass 監控大集群的能力。
集群規模
我們關聯的集群規模大致如下
1060 個節點
64000+ Pod
96000+ container
采集配置
我們直接使用云原生監控服務在關聯集群默認添加的采集配置，目前已包含了社區主流的監控指標：
kube-state-metrics
node-exporer
kubelet
cadvisor
kube-apiserver
kube-scheduler
kube-controler-manager
測試結果
總計 3400+target, 2700+ 萬 series
總計擴容了 17 個分片
每個分片 series 穩定在 200w 以下
每個分片消耗內存在 6 -10G 左右
云原生監控所提供的默認 Grafana 面板也能正常拉取 
targets 列表也能正常拉取 
多集群監控
值得一提的是，云原生監控服務不僅支持監控單個大規模集群，還可以用同個實例監控多個集群，并支持采集和告警模板功能，可一鍵將采集告警模板下發至各地域各個集群，徹底告別了每個集群重復添加配置的問題。
感謝各位的閱讀，以上就是“怎么用 Prometheus 監控十萬 container 的 Kubernetes 集群”的內容了，經過本文的學習后，相信大家對怎么用 Prometheus 監控十萬 container 的 Kubernetes 集群這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是丸趣 TV，丸趣 TV 小編將為大家推送更多相關知識點的文章，歡迎關注！
