Prometheus 作为目前最主流的可观测开源项目之一，已经成为云原生监控的事实标准，被众多企业广泛应用。在使用 Prometheus 的时候，我们经常会遇到全局视图的需求，但是数据确分散在不同的 Prometheus 实例中，遇到这种情况该怎么解决呢？本文列举了社区一般解决方案，同时给出了阿里云的全局视图解决方案，最后给出了某客户基于阿里云 Prometheus 的实践案例，希望能给您带来启发与帮助。

在使用阿里云 Promtheus 时，由于地域的限制、业务原因或者其他原因，经常会遇到 Prometheus 多实例的场景。如下图所示，某用户在杭州区域有多个 Prometheus “通用”实例。在多实例的背景下，我们经常会遇到一些问题。

所以，针对多 Prometheus 实例存在的上述问题，社区是如何解决的呢？

边缘节点每一个 Prometheus 实例都会包含一个/federate 的接口，用于获取一组指定的时间序列的监控数据，Global 节点只需要配置一个采集任务，用于从边缘节点获取监控数据即可。为了更好的理解 Federation 机制，下面给出了 Global Prometheus 的配置文件的配置。

scrape_configs:  - job_name: 'federate'    scrape_interval: 10s
    honor_labels: true    metrics_path: '/federate'
    # 根据实际业务情况进行Pull metrics，通过match参数，配置要拉取的Metrics    params:      'match[]':        - '{job="Prometheus"}'        - '{job="node"}'
    static_configs:      # 其他 Prometheus 节点      - targets:        - 'Prometheus-follower-1:9090'        - 'Prometheus-follower-2:9090'

• Thanos Sidecar：连接 Prometheus，将其数据提供给 Thanos Query 查询，并且将其上传到对象存储以供长期存储。

• Thanos Query：实现了 Prometheus API，提供全局查询视图将来 StoreAPI 提供的数据进行聚合最终返回给查询数据的 client（如 Grafana）。

• Thanos Store Gateway：将对象存储的数据暴露给 Thanos Query 去查询。

• Thanos Compact：将对象存储中的数据进行压缩和降低采样率，加速大时间区间监控数据查询的速度。

• Thanos Ruler：对监控数据进行评估和告警，还可以计算出新的监控数据，将这些新数据提供给 Thanos Query 查询并且/或者上传到对象存储，以供长期存储。

• Thanos Receiver：从 Prometheus 的远程写入 WAL 接收数据，将其公开和/或上传到云存储。

那 Thanos 如何实现 global 查询的呢？

如下为样例，修改 Prometheus.yml 添加 Remote Storage 相关的配置内容。

remote_write:  - url: "http://*****:9090/api/v1/write"

4.1.1. 阿里云 Prometheus 全局聚合实例方案介绍

4.1.2. 对比分析

下面针对开源 Prometheus Federation 以及 Thanos 方案以及阿里云全局聚合实例方案进行简单的汇总说明。

虽然 Prometheus Federation 能解决全局聚合查询，但是还存在一些问题。

• 边缘节点和 Global 节点依然是单点，需要自行决定是否每一层都要使用双节点重复采集进行保活，也就是仍然会有单机瓶颈。
• 对历史数据的存储问题仍旧未得到解决，必须依赖第三方存储，切缺少对历史数据的降准采样能力。
• 整体运维成本比较高。

• 可扩展性较差，添加或移除 Prometheus 实例需要修改配置文件。

2）Thanos Federation

• 架构比较复杂，运维成本较高。
• 仍存在 Prometheus 副本的单点问题。
• 时间线发散的情况下，支持的上限不够，不提供维度发散场景优化。
• 不支持降采样，长周期查询性能不高。

• 不支持算子下推，大数据量的请求性能有限，并且处理开销大。

3）阿里云全局聚合实例

• Prometheus 实例托管、免运维。
• 支持图形化界面进行多实例的管理，灵活性强、可扩展性高。这种模式允许系统轻松地添加或移除阿里云 Prometheus 实例，而不需要重新配置整个存储系统。

• 不占用额外的存储空间。由于没有将数据复制到集中的存储中，这种方法可以节约存储空间，每个 Prometheus 实例只需要维护自己的数据集。在不额外配置存储的情况下，查询到的数据仅是临时用于展示，真正的数据持久化仍然归于被聚合的实例。
• 隔离性：每个实例的自治性能够提高系统的容错性，因为单个实例的问题不会直接影响到其他实例。
• 支持跨 region 实例以及跨账号实例聚合，满足企业个性化的需求。

但是需要注意的是 Thanos Federation 与阿里云全局聚合实例都是非合并数据的方式实现全局查询。由于需要在查询时从多个数据源检索数据，这可能会导致查询性能下降，特别是当查询涉及大量不需要的数据时，需要等待多个数据源筛选出需要的数据，等待这些数据处理的过程可能导致查询超时或长时间等待。

4.1.3. 阿里云 Prometheus 全局聚合实例实践

4.2.1. 阿里云 Prometheus Remote Write 解决方案

1. 在被聚合的 Prometheus 实例中，存储着该实例所有的原始数据，包括期望被聚合查询的实例以及其他数据。用于原业务场景中单实例的查询。

2. 在中央/聚合 Prometheus 中，存储着其他“被聚合实例”的“期望被聚合的数据”，在统一管理的场景下，可以通过该实例获取全局视图的查询，执行跨实例数据的搜索。

4.2.2. 阿里云 Prometheus Remote Write VS 社区 Prometheus Remote Write

开源 Remote Write 的形式最大的弊端在于对 Prometheus Agent 的影响，在 Agent 设置 Remote Write 会增加 Agent 的资源消耗，影响数据采集的性能，而这一点往往是致命的。

阿里云 Prometheus Remote Write 的优势还是非常明显的。

• 查询性能高：因为只存储了必要的聚合数据，聚合 Prometheus 实例的查询响应时间更短，极大地提升了用户体验。此外，在查询时本质上只是对一个 Prometheus 实例进行操作，而非多个实例，读写的性能、计算的性能更高。
• 数据质量高：经过筛选后的数据更加干净，没有不必要的 "脏数据"，这有助于进行更加精准和有效的数据分析。
• 提供丰富的 ETL 能力: 在写入聚合实例之前提供丰富的处理能力，如过滤筛选、指标富化等。
• 图形化配置，操作简单便捷。

• 费用问题：由于需要额外的 Prometheus 实例来作为聚合和全局查询的存储点，这意味着需要额外的 TSDB 后端存储需要被聚合的数据，这些独立的存储空间是需要计费的。
• 网络消耗：在数据投递过程中，跨网络的数据传输会增加带宽占用，特别是在跨数据中心或宽带有限的环境中，所以需要进行合理的评估。

4.2.3. 阿里云 Prometheus Remote Write 使用

Prometheus 全局聚合实例的设计理念是在保持 Prometheus 实例的存储独立性的同时，提供一个统一的接口对多个实例进行查询来实现全局视图。该方案的核心理念为“查询时指标聚合”，也就是说数据原封不动地存储在多个实例中，当统一查询时才将多个实例的数据获取并聚合。这种方法有其明显的优点，如节省存储空间，但也存在一些挑战，对于实例数量较多、数据量大的场景查询性能会受较大影响。

Prometheus 数据投递-Remote Write 的设计理念是将查询的流量转化为数据写入的流量，它消耗了额外的存储空间提供多实例聚合数据的方案，它通过在写入之前筛选数据，使得中心实例精简地存储着聚合数据。该方案的核心理念为“存储时指标聚合”，此时多个实例的数据副本将存储在统一中心化实例中，对多个实例的查询将转化为单实例查询，大大提升了查询速率与数据质量。

5.1.1. 介绍

此时 SRE 团队 无法对所有集群状态有全局的视角，难以准确获取该产品的健康状态。 在平时的运维工作中，大多依赖告警提示某个集群处于非健康状态。 目前 A 运维平台托管了上百个集群， 全部依赖告警会有消息过多的风险，导致等级较高的故障无法快速定位。

5.1.2. 诉求

当前在“A 运维平台”的运维管理面临一个挑战：缺少对所有地区集群状态的一目了然的全局视图。“A 运维平台”的目标是配置单一的 Grafana 大盘，通过引入单一的数据源，实现对个产品线整所有租户集群运行状况的实时监控这应。包括关键指标的可视化，例如集群的整体状态（包括集群的数量、各节点和 Pod 的数量、全网集群的  CPU 使用情况等），以及\APIServer 的 SLO（服务水平目标）状态（诸如全网非 500 响应的动词比例、50X 错误的详细信息、请求成功率等）。

5.1.3. 难点