基于Prometheus的云原生监控系统架构演进

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中的met