一文读懂 Prometheus 长期存储主流方案

Prometheus 作为云原生时代崛起的标志性项目，已经成为可观测领域的事实标准。Prometheus 是单实例不可扩展的，那么如果用户需要采集更多的数据并且保存更长时间该选择怎样的长期存储方案呢？

2022 年 8 月 9 日，在 CSDN 云原生系列在线峰会第 15 期“Prometheus 峰会”上，青云科技可观测与函数计算负责⼈霍秉杰分享了《Prometheus Long-Term Storage：海纳百川，有容乃大》。

Prometheus 简介及其局限性
云原生时代崛起的 Prometheus 已经在可观测领域得到了广泛应用，其影响力远远超出了云原生的范畴，具有两个显著特点。

单实例，不可扩展
Prometheus 的作者及社区核心开发者都秉承一个理念：Prometheus 只聚焦核心的功能，扩展性的功能留给社区解决，所以 Prometheus 自诞生至今都是单实例不可扩展的。

这对于很多从大数据时代走过来的工程师而言有点不可思议，大数据领域的很多开源项目比如 Elasticsearch、HBase、Cassandra 等无一不是多节点多角色的设计。

Prometheus 的核心开发者曾这样解释，Prometheus 结合 Go 语言的特性和优势，使得 Prometheus 能够以更小的代价抓取并存储更多数据，而 Elasticsearch 或 Cassandra 等 Java 实现的大数据项目处理同样的数据量会消耗更多的资源。也就是说，单实例、不可扩展的 Prometheus 已强大到可以满足大部分用户的需求。

Pull 模式抓取数据
Prometheus 倡导用 Pull 模式获取数据，即 Prometheus 主动地去数据源拉取数据。对于不便于 Pull 的数据源，Prometheus 提供了 PushGateway 进行处理，但 PushGateway 在部分应用场景上存在限制。

尽管单实例的 Prometheus 已经足够强大，但还是存在部分需求是其无法满足的，如跨集群聚合、更长时间的存储等。为了扩展 Prometheus，社区给出了多种方案。

在 Prometheus 长期存储出现之前，用户若需要跨集群聚合计算数据时，社区提供 Federation 方式实现。

在多个 Prometheus 实例的上一层有一个 Global Prometheus，它负责在各个实例中抓取数据并进行计算，以此解决跨集群聚合计算的问题。但如果各个集群的数据量较大，单实例的 GlobalPrometheus 也会遇到瓶颈。

Promretheus 长期存储方案的崛起
2017 年，Prometheus 加⼊ Remote Read/Write API，自此之后社区涌现出大量长期存储的方案，如 Thanos、Grafana Cortex/Mimir、VictoriaMetrics、Wavefront、Splunk、Sysdig、SignalFx、InfluxDB、Graphite 等。

接下来我们将挑选几个主流的 Prometheus 长期存储方案进行对比分析。