概述

当前编写文章之时，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