关于腾讯云:打造云原生大型分布式监控系统四-KvassThanos-监控超大规模容器集群

42次阅读

共计 2935 个字符,预计需要花费 8 分钟才能阅读完成。

概述

继上一篇 Thanos 部署与实际 公布半年多之后,随着技术的倒退,本系列又迎来了一次更新。本文将介绍如何联合 Kvass 与 Thanos,来更好的实现大规模容器集群场景下的监控。

有 Thanos 不够吗 ?

有同学可能会问,Thanos 不就是为了解决 Prometheus 的分布式问题么,有了 Thanos 不就能够实现大规模的 Prometheus 监控了吗?为什么还须要个 Kvass?
Thanos 解决了 Prometheus 的分布式存储与查问的问题,但没有解决 Prometheus 分布式采集的问题,如果采集的工作和数据过多,还是会使 Prometheus 达到的瓶颈,不过对于这个问题,咱们在系列的第一篇 大规模场景下 Prometheus 的优化伎俩 中就讲了一些优化办法:

  1. 从服务维度拆分采集工作到不同 Prometheus 实例。
  2. 应用 Prometheus 自带的 hashmod 对采集工作做分片。

然而,这些优化办法还是存在一些毛病:

  1. 配置繁琐,每个 Prometheus 实例的采集配置都须要独自配。
  2. 须要提前对数据规模做预估才好配置。
  3. 不同 Prometheus 实例采集工作不同,负载很可能不太平衡,管制不好的话依然可能存在局部实例负载过高的可能。
  4. 如需对 Prometheus 进行扩缩容,须要手动调整,无奈做到主动扩缩容。

Kvass 就是为了解决这些问题而生,也是本文的重点。

什么是 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,将其一键部署到集群:

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 生成器的采集:

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

小结

本文介绍了如何联合 Kvass 与 Thanos 来实现超大规模容器集群的监控,如果你应用了腾讯云容器服务,能够间接应用运维核心下的 云原生监控 服务,此服务就是基于 Kvass 构建的产品。

【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯,扫码关注同名公众号,及时获取更多干货!!

正文完
 0