概述

当前编写文章之时,Prometheus 的最新版本是 2.25,所以以下讨论都基于 Promethues 2.25 的特性来展开。

联邦解决什么问题

联邦(Federation)这个特性只是部分解决了单点性能瓶颈问题,其中 Prometheus 提供两种联邦的使用场景,分别是:

层级联邦

在 Prometheus Federation 中,层级联邦(Hierarchical Federation)的作用是将细致的 metric 分散到各个不同的子 prometheus 中存储,每个子 prometheus 各司其职管理自己的范围内的详细 metrics。

还有,对于一个整体视图的 metrics,那么将由一个整体的 prometheus 从各个子 prometheus 中获取。

举个详细例子,假如有一个 3 节点的集群,每个集群里面运行着很多服务,那么每个节点上都运行一个 prometheus,负责这个节点上所有服务的所有 metrics 监控。然后,对于这个集群的整体视图的 metric,例如 host CPU usage 这些,可以在集群中选出一个 leader 节点,再单独运行一个 prometheus,由这个 prometheus 从 3 个节点上的 prometheus 拉取像 CPU 使用率这样的 metric,从而分散每一个 prometheus 的压力。

跨服务联邦

Prometheus Federation 的另外一种模式是所谓的跨服务联邦(Cross-service federation)。在这种模式下,Prometheus 是以服务为主体进行组织的。

例如还是 3 节点的集群,在每个节点(主机)上,可能运行有集群服务(例如 K8S),也会运行有业务服务(例如 Web Server 之类),这两种服务分别使用不同的 Prometheus 用于抓取和存储 metrics。但是,可能对于业务 Prometheus 也会关注说某个业务应用的 CPU 使用情况,此时,就可以将业务 Prometheus 从平台 Prometheus 中获取应用的 CPU 使用情况的 metric,从而组成了一种跨服务联邦。

总结

Prometheus Federation 在一定程度上解决了 Promtheus 的单点性能瓶颈,但是,并没有解决其他问题,例如就跨服务联邦来说,如果业务 Prometheus 挂掉了,那么业务 Metrics 也就无法抓取,你挂多久就多久没有 Metrics;还有对于跨联邦的一些聚合, Prometheus 应该是没有实现的(这在某些第三方中是单独实现的),例如跨服务的联邦,你想看所有服务的 CPU 使用率 Top10 的服务,这个可能没法实现,当然,前面也提到了,你可以将关注的这些指标单独抽离出来一个 Prometheus 来做,但是还是比较诡异。

Prometheus 官方也在一些 Issue 中回答过单点故障数据丢失的问题,他们建议的解决方案是做主备,也就说对于业务 Prometheus,开多个 Prometheus 实例,以相同的频率采集相同的 endpoint,但是,当你查询 Metirc 的时候,只找其中一个来查询就可以了。

主备方案行不行?也许行,但是在 2B 场景下大多数情况下是不行,因为 Metrics 是实时数据,即使主备两个 Prometheus 同时请求,也很可能获取到不同的值,那如果 Prometheus A 采集到的值可以触发报警,Prometheus B 采集到的值不能触发报警,那我是要触发报警呢?还是不触发报警?如果触发报警了,倒是 A 挂了,你通过 B 查看历史数据,你又要怎么解释呢?

Ref