打造雲原生大型分佈式監控系統(四): Kvass+Thanos 監控超大規模容器集羣

時間 2020-12-08

標籤 git github 架構 app 負載均衡運維分佈式 ide 優化 lua 欄目系統架構简体版

原文原文鏈接

概述

繼上一篇 Thanos 部署與實踐發佈半年多以後，隨着技術的發展，本系列又迎來了一次更新。本文將介紹如何結合 Kvass 與 Thanos，來更好的實現大規模容器集羣場景下的監控。git

有 Thanos 不夠嗎 ?

有同窗可能會問，Thanos 不就是爲了解決 Prometheus 的分佈式問題麼，有了 Thanos 不就能夠實現大規模的 Prometheus 監控了嗎？爲何還須要個 Kvass？
Thanos 解決了 Prometheus 的分佈式存儲與查詢的問題，但沒有解決 Prometheus 分佈式採集的問題，若是採集的任務和數據過多，仍是會使 Prometheus 達到的瓶頸，不過對於這個問題，咱們在系列的第一篇大規模場景下 Prometheus 的優化手段中就講了一些優化方法:github

從服務維度拆分採集任務到不一樣 Prometheus 實例。
使用 Prometheus 自帶的 hashmod 對採集任務作分片。

可是，這些優化方法仍是存在一些缺點:架構

配置繁瑣，每一個 Prometheus 實例的採集配置都須要單獨配。
須要提早對數據規模作預估纔好配置。
不一樣 Prometheus 實例採集任務不一樣，負載極可能不太均衡，控制很差的話仍然可能存在部分實例負載太高的可能。
如需對 Prometheus 進行擴縮容，須要手動調整，沒法作到自動擴縮容。

Kvass 就是爲了解決這些問題而生，也是本文的重點。app

什麼是 Kvass ?

Kvass 項目是騰訊雲開源的輕量級 Prometheus 橫向擴縮容方案，其巧妙的將服務發現與採集過程分離，並用 Sidecar 動態給 Prometheus 生成配置文件，從而達到無需手工配置就能實現不一樣 Prometheus 採集不一樣任務的效果，而且可以將採集任務進行負載均衡，以免部分 Prometheus 實例負載太高，即便負載高了也能夠自動擴容，再配合 Thanos 的全局視圖，就能夠輕鬆構建只使用一份配置文件的超大規模集羣監控系統。下面是 Kvass+Thanos 的架構圖:負載均衡

更多關於 Kvass 的詳細介紹，請參考如何用 Prometheus 監控十萬 container 的 Kubernetes 集羣，文章中詳細介紹了原理和使用效果。運維

部署實踐

部署準備

首先下載 Kvass 的 repo 並進入 examples 目錄:分佈式

git clone https://github.com/tkestack/kvass.git
cd kvass/examples

在部署 Kvass 以前咱們須要有服務暴露指標以便採集，咱們提供了一個 metrics 數據生成器，能夠指定生成必定數量的 series，在本例子中，咱們將部署 6 個 metrics 生成器副本，每一個會生成 10045 series，將其一鍵部署到集羣:ide

kubectl create -f  metrics.yaml

部署 Kvass

接着咱們來部署 Kvass:優化

kubectl create -f kvass-rbac.yaml # Kvass 所需的 RBAC 配置
kubectl create -f config.yaml # Prometheus 配置文件
kubectl create -f coordinator.yaml # Kvass coordinator 部署配置

其中，config.yaml 的 Prometheus 配置文件，配了對剛纔部署的 metrics 生成器的採集:lua

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

coordinator.yaml 咱們給 Coordinator 的啓動參數中設置每一個分片的最大 head series 數目不超過 30000:

--shard.max-series=30000

而後部署 Prometheus 實例(包含 Thanos Sidecar 與 Kvass Sidecar)，一開始能夠只須要單個副本:

kubectl create -f prometheus-rep-0.yaml

若是須要將數據存儲到對象存儲，請參考上一篇 Thanos 部署與實踐對 Thanos Sidecar 的配置進行修改。

部署 thanos-query

爲了獲得全局數據，咱們須要部署一個 thanos-query:

kubectl create -f thanos-query.yaml

根據上述計算，監控目標總計 6 個 target, 60270 series，根據咱們設置每一個分片不能超過 30000 series，則預期須要 3 個分片。咱們發現，Coordinator 成功將 StatefulSet 的副本數改爲了 3。

$ kubectl get pods
NAME                                READY   STATUS    RESTARTS   AGE
kvass-coordinator-c68f445f6-g9q5z   2/2     Running   0          64s
metrics-5876dccf65-5cncw            1/1     Running   0          75s
metrics-5876dccf65-6tw4b            1/1     Running   0          75s
metrics-5876dccf65-dzj2c            1/1     Running   0          75s
metrics-5876dccf65-gz9qd            1/1     Running   0          75s
metrics-5876dccf65-r25db            1/1     Running   0          75s
metrics-5876dccf65-tdqd7            1/1     Running   0          75s
prometheus-rep-0-0                  3/3     Running   0          54s
prometheus-rep-0-1                  3/3     Running   0          45s
prometheus-rep-0-2                  3/3     Running   0          45s
thanos-query-69b9cb857-d2b45        1/1     Running   0          49s

咱們再經過 thanos-query 來查看全局數據，發現數據是完整的(其中 metrics0 爲指標生成器生成的指標名):

若是須要用 Grafana 面板查看監控數據，能夠添加 thanos-query 地址做爲 Prometheus 數據源: http://thanos-query.default.svc.cluster.local:9090。