当前位置：首页 > news >正文

青云霍秉杰：一文读懂Prometheus长期存储主流方案

news 来源：原创 2024/5/10 2:20:33

嘉宾 | 霍秉杰整理 | 西京刀客

出品 | 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的版本。

Cortex with Chunk Storage

受Thanos的启发，Cortex新架构采用Block Storage。我们可以看到，Cortex新架构的distributor、ingester、querier、ruler、store-gateway、compactor都与Thanos类似，其中ruler、store-gateway、compactor都借鉴自Thanos。

Cortex with Block Storage

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。