关于云计算:一文读懂-Prometheus-长期存储主流方案

嘉宾 | 霍秉杰
整顿 | 西京刀客
出品 | CSDN 云原生

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 长期存储计划进行比照剖析。

M3

M3 是 Uber 开源的一个 Prometheus 长期存储的计划，它的组件次要包含 M3 Coordinate、M3 Queries、M3 Aggregator 及 M3DB。

M3 的工作原理是 Prometheus 将数据通过 M3 Coordinate Remote 写入至 M3DB 中，M3 Queries 可间接对接 M3DB 进行查问。M3Aggregator 对接收数据进行实时聚合，降采样后存入 M3DB。

M3 是 Uber 为了满足本身海量数据需要所开发的 Prometheus 长期存储的计划，其毛病是部署麻烦，且社区也不沉闷、文档欠佳。

VictoriaMetrics

VictoriaMetrics 是一个开源的 Prometheus 长期存储我的项目，除开源我的项目外，还有商业化的产品和服务。VictoriaMetrics 的采纳者包含知乎、Grammarly、fly.io、CERN 等。

VictoriaMetrics 次要由三个组件形成：接入数据的 vminsert、存储数据的 vmstorage 以及查问数据的 vmselect。

vminsert 和 vmselect 都是无状态的，能够通过减少正本的形式进行扩大。

vmstorage 尽管是有状态的，但也能够扩大，当数据量超过一个正本的存储量时，能够通过减少另外一个正本对其进行扩大。

VictoriaMetrics 的 Agent 性能较为弱小，次要体现在以下几方面：

• 能够代替 Prometheus 抓取数据，还能够接管 Prometheus 之外的数据源 Push 过去的数据，如 Graphite、InfluxDB、OpenTSDB 等；
• 能够把抓取的数据 Remote Write 到多个 Long-Term Storage；
• 能够将数量泛滥的抓取指标在 vmagent 实例之间进行调配。

VictoriaMetrics 还有一个独自的用于告警的组件——VictoriaMetrics Alert，它具备两个性能：

• 通过查问 vmselect 决定是否须要告警，如果须要就将告警发到 alertmanager 中；
• 通过查问 vmselect 计算 Recording Rule，并把计算结果通过 vminsert 写入存储。

另一个组件是 VictoriaMetrics Gateway，它次要有两个性能：

• 限速，在租户读写时，会将局部数据写入至另外一个 VictoriaMetrics 的实例中来记录用量，超量的时候会做出肯定的限度；
• 访问控制，访问控制指在读或者写之前，必须先得获取一个 Token。

VictoriaMetrics 还有其余的组件比方 vmauth、vmbackup/vmrestore、vmbackupmanager、vmanomaly 等。

值得一提的是，VictoriaMetrics 并不是所有性能都是开源的，未开源的企业版性能包含：

• Downsampling 降采样；
• vmgateway 的 SSO、LDAP、JWT Token Authentication&Access Control；
• 租户级别的读写限速；
• vmagent 读写 Kafka；
• 多租户告警与统计；
• BackupManager；
• 基于机器学习的异样监测 vmanomaly。

Thanos

Thanos 由 Improbable 开源，是社区最先呈现的 Prometheus 长期存储计划，采纳者包含 Adobe、字节、eBay、腾讯等。

Thanos 在架构上较为翻新，具备诸多较为独特的性能：

• 可能提供 Prometheus 实例的全局查问视图，能够逾越多个 Prometheus 实例对数据进行查问和聚合；
• 能够把数据通过 Sidecar 上传至对象存储以便长时间保留；
• 提供压缩与降采样性能，通过压缩能够减小对象存储上保留的 Block 的大小，通过降采样能够放慢长时间范畴数据的查问与聚合速度。

Thanos 有两种模式，Sidecar 模式和 Receive 模式。

Thanos Sidecar 模式

ThanosSidecar 模式是 Thanos 最早反对的模式，其原理是：

• 每个 Prometheus Pod 中都有一个 Sidecar，这个 Sidecar 通过 Store API 与外界交互；
• Thanos Query 通过 Store API 与 Thanos Sidecar 交互，经由 Thanos Sidecar 查问到各 Prometheus 实例上的数据后进行聚合，去重后提供给用户一个跨多个 Prometheus 实例的全局视图；
• Thanos Sidecar 中的 Shipper 会把本地 Prometheus 实例落盘的 Block 上传到对象存储，之后由 Thanos Compact 对上传到对象存储的 Block 进行压缩、降采样和过期删除；
• 存储在对象存储里的 Block 可由 Store Gateway 通过 Store API 向 Thanos Query 提供查问服务，Store Gateway 会缓存对象存储里 Block 的 index 以放慢查问速度；
• 此外，Thanos Query 后面还有 Thanos Query Frontend 用于缓存查问后果以放慢查问速度；
• Thanos Ruler 用于通过查问 Thanos Query 计算 Recording 或 Alerting Rules。

Thanos Receive 模式

Thanos Receive 模式是 Thanos 响应社区用户 Remote Write 的需要新增的模式，其原理是：

• Prometheus 或 Prometheus Agent 通过 Remote Write 将监控数据发送到 Thanos Receive Router；
• Thanos Receive Router 依据租户信息将数据发送给响应的 Thanos Receive Ingestor，其中 Router 是无状态的，Ingestor 是有状态的；
• Thanos Receive Ingestor 相当于在一个没有数据抓取能力和告警能力的 Prometheus 之上减少了 Store API 的反对用于和 Thanos Query/Thanos Ruler 交互，减少了 Shipper 组件将落盘 Block 上传对象存储；
• Thanos Query 能够对立查问 Thanos Ingestor、Thanos Store Gateway；
• 其余组件作用和 Thanos Sidecar 模式相似。

Cortex

Cortex 由 Grafana 开源，Loki、Tempo、Grafana Cloud 等产品或我的项目都采纳了 Cortex 的技术。采纳者包含 AWS、Digital Ocean、Grafana Labs、MayaData、Weaveworks 等。

Cortex 最后是基于 Chunk Storage 的版本，因部署运维起来较为简单且依赖 Cassandra 或 DynamoDB 存储元数据，曾经确定被弃用，改为基于 Block Storage 的版本。

受 Thanos 的启发，Cortex 新架构采纳 Block Storage。咱们能够看到，Cortex 新架构的 distributor、ingester、querier、ruler、store-gateway、compactor 都与 Thanos 相似，其中 ruler、store-gateway、compactor 都借鉴自 Thanos。

Grafana Mimir

Grafana Mimir 是 Grafana Lab 于 2022 年 3 月底以 AGPL v3 协定新公布的开源我的项目。

从 Mimir 公布的 Blog Announcing Grafana Mimir 能够看出，Grafana Mimir 在 Fork 了 Cortex 我的项目之后减少了许多企业级性能，被用于 Grafana Cloud 及服务 Grafana 的企业客户的产品 Grafana Enterprise Metrics（GEM）。这么做的次要起因是 Grafana Lab 认为 Cortex 被一些 ISV 或云厂商用于给本人的客户提供服务，却没有像 Grafana Lab 一样奉献代码，于是将越来越多的性能放到了 Cortex 的 Fork Mimir 中。

作为 Cortex 的增强版，之前很长一段时间 Mimir 是未开源的状态，但这与 Grafana Lab 的开源文化相悖，于是为了兼顾开源和本人的商业利益，Grafana Lab 将 Mimir 在 AGPL v3 下开源。

因为 Grafana Mimir Fork 了 Cortex，所以其架构和 Cortex 及 Thanos 十分类似。

尽管 Grafana Mimir 同样借鉴了 Thanos 的 store-gateway、compactor 和 ruler，但与 Cortex 不同之处在于 querier 和 query frontend 之间加了一个额定的组件 query scheduler，更好地满足了查问组件的可扩展性。

Mimir 各组件（包含 compactor、store-gateway、query、ruler 等）的程度可扩展性较好，值得一提的是 Mimir 对 Alertmanage 做了多租户和程度扩大的反对。

Prometheus 长期存储计划比照

咱们能够基于多维度对上述介绍的 Prometheus 长期存储计划进行横向比照：

• Thanos 和 Cortex 已捐给 CNCF 基金会并处于孵化阶段，有着更好的中立性，而 Mimir 的 AGPL v3 许可证不够敌对；
• 从一些开源我的项目的指标看，Thanos 更受欢迎，其采纳者也比拟多；
• Mimir 是 Grafana Lab 商业产品的开源版本，具备更好的程度可扩展性；
• Mimir 与 VictoriaMetrics 有着更好的文档；
• 在波及多租户、权限管制、接入数据源的多样性等企业级性能方面，Mimir 和 VictoriaMetrics 更优；
• M3 在各个维度上都不占优。

总结

综上，咱们能够得出以下论断。

• 数据长久化到硬盘的计划里，VictoriaMetrics 是更好的抉择，但须要留神的是 VictoriaMetrics 并没有开源 Downsampling 降采样性能，如需跨较长时间范畴进行聚合及查问，耗时会比拟久。
• 数据长久化到对象存储的计划中，Thanos 更受欢迎，Grafana Mimir 更有后劲。
• Thanos 能够不应用对象存储，用本地盘存数据（Cortex/Mimir 待验证）。
• Grafana Fork 了 Cortex，创立了 Mimir 并批改 License 为 AGPL-3.0。后续 Grafana 及社区的投⼊水平成疑，不倡议持续采纳 Cortex。
• Thanos/Cortex/Mimir 相互借鉴，架构相似。Cortex/Mimir 借鉴了 Thanos 的对象存储拜访及长久化。Thanos 借鉴了 Cortex 的 QueryFrontend。Mimir 作为 Grafana Cloud 的开源版本，其基于 Thanos 和 Cortex 的架构做了更多的优化。
• 总体来说，在不介意许可证的状况下，能够采⽤ Mimir，若在意更宽松许可证，CNCF 孵化我的项目的 Thanos 是更好的抉择。
• 没有对象存储，举荐应用 VictoriaMetrics（有些重要性能没开源）, 有对象存储尽量用 Thanos 或 Mimir。
• 没有非凡起因尽量不要采纳 M3。

本文由博客一文多发平台 OpenWrite 公布！