如果使用Kvass+Thanos监控十万容器的大集群
Prometheus
Prometheus依靠其强劲的单机性能，灵活的PromSQL，活跃的社区生态，逐渐成为云原生时代最核心的监控组件，被全球各大产商用于监控他们的核心业务。
然而，面对大规模监控目标（数千万series）时，由于原生Prometheus只有单机版本，不提供集群化功能，开发人员不得不通过不断增加机器的配置来满足Prometheus不断上涨的内存。
Thanos
Thanos是社区最为流行的Prometheus HA方案，其可以将多个Prometheus数据汇总，去重，得到全局的数据视图，并支持将数据存储到COS中长期保存。虽然Thanos为Prometheus提供了，多副本，多集群监控的能力，但是针对单个规模较大的集群，用户往往需要通过将采集任务切分到不同的Prometheus来防止单个Prometheus负载过高，这不仅加大了配置管理难度，而且切分后的Prometheus负载也特别不均衡。
Kvass
Kvass项目是腾讯云开源的轻量级Prometheus横向扩缩容方案，其巧妙的将服务发现与采集过程分离，并用sidecar动态给Prometheus生成配置文件，从而达到不同Prometheus采集不同任务的效果。配合Thanos的全局视图，就可以轻松构建只使用一份配置文件的大规模集群监控系统。关于Kvass，腾讯云也发布了一篇文章详细介绍了原理和使用效果https://mp.weixin.qq.com/s/P3F1grbVpb7LF2hcxYNOcg
架构图
使用案例
这一节我们通过一个部署例子，来直观感受一下Kvass的效果，相关yaml文件可以在这里找到https://github.com/tkestack/kvass/tree/master/examples
读者可以将项目clone到本地，并进入examples。
git clone https://github.com/tkestack/kvass.git
cdkvass/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为指标生成器生成的指标名）
