Prometheus远程读写存储是一个热门话题，已经存在了数个系统（Cortex，M3DB，InfluxDB），并且在过去的几个月中已经诞生了一些系统（Thanos，VictoriaMetrics）。每个系统都有自己的架构和不同的使用场景。

一句话：成也Prometheus，败也Prometheus。

Prometheus生态和体系太过优秀，导致抛开Prometheus，另起炉灶，重新创建一个轮子的难度非常之大。而正如第一篇文章所述，Prometheus本身tsdb的劣势，又给了诸多系统机会。

至于这场战争，谁会笑到最后，目前来看不得而知。

目前Prometheus已经支持以下第三方系统的对接：

不过良莠不齐，很多是一些实验性的适配器。当然如果你恰好运行在公有云上，而且能承受监控存储所带来的成本，那么使用公有云的时序存储，是一个高枕无忧的方案。

接下来，我会重点介绍一下目前已经存在的，比较优秀的开源系统。这些系统均提供了以下的功能：

• 长期保存，任意保留。
• 从多个Prometheus实例收集的数据的全局查询视图。
• 水平可伸缩性。

Thanos

Thanos 也是一个CNCF基金会下管理的项目。Thanos利用Prometheus 2.0存储格式以经济高效的方式将历史指标数据存储在任何对象存储中，同时保留快速查询延迟;此外，它还提供了所有Prometheus安装的全局查询视图，并且可以即时合并Prometheus HA对中的数据。

Thanos 包括了如下的组件：

• Sidecar -- 它将与每个Prometheus实例一起部署并执行以下任务：1）将早于2小时的Prometheus数据上传到对象存储（例如Amazon S3或Google Cloud Storage）； 2）将对最近添加的数据的查询处理到本地Prometheus（小于2小时）。
• Store gateway -- 处理对存储在对象存储（例如S3或GCS）中的数据的查询。
• Query -- 实现Prometheus查询API并针对从Sidecars和Stores获得的数据提供全局查询视图。
• Compact -- 默认情况下，Sidecar将数据以2小时的块上传到对象存储中，Compactor会逐渐将这些块合并为更大的块，以提高查询效率并减小所需的存储大小。
• Rule -- 对从Query（又称全局查询视图）获得的数据执行Prometheus记录规则和警报规则。由于Query及其底层组件的可靠性低，规则组件的故障率通常较高。
• Receiver -- 实验性组件，可以通过remote_write API接收来自Prometheus的数据。从Thanos v0.5.0开始，该组件尚未准备就绪。

整体架构图如下：

个人感觉，Thanos 组件比较复杂，维护成本比较高，如果你在一些非云的环境中，需要自己提供一套对象存储。当然Minio（社区办S3）可能是你一个不错的选择。社区比较活跃。

Cortex

Cortex有是cncf基金会下管理的项目，Cortex由Weaveworks创建，是一个用于应用程序和微服务的开源时间序列数据库和监视系统，基于Prometheus，Cortex增加了水平缩放和几乎无限的数据保留。

• 它开箱即用地支持四个长期存储系统：AWS DynamoDB，AWS S3，Apache Cassandra和Google Cloud Bigtable。
• 它提供了Prometheus时间序列数据的全局视图，其中包括长期存储的数据，从而大大扩展了PromQL用于分析目的的用途。
• 它的核心部分内置了多租户。所有通过Cortex的Prometheus指标都与特定租户相关联。

Cortex包含的组件非常多，此处不一一介绍，大家可以看下图：

整体架构图如下：

关于Cortex，是为数不多的支持多租户的TSDB。社区也比较活跃，不过其开发者已经跳槽到了grafana公司，开发了Loki日志处理系统。此外Cortex的组件比Thanos都复杂。

M3

Uber开发了指标平台M3和分布式时间序列数据库M3DB。来解决Uber在发展过程中遇到的问题：使用开源软件后，由于可靠性，成本等问题，在操作密集型方面无法大规模使用这些开源软件。所以Uber逐步构建了自己的指标平台。我们利用经验来帮助我们构建本地分布式时间序列数据库，高度动态和高性能的聚合服务，查询引擎以及其他支持基础架构。

M3包括了如下的组件：

• M3DB -- M3db是一个使用TSDB（时间数据库），保存所有Prometheus指标，M3db是分布式，高可用性和复制的数据库，它使用Etcd作为共识算法。
• M3Coordinator -- 是Prometheus实例与M3db之间的适配器，它公开了Prometheus用来从数据库中推送和提取数据的读/写端点。
• M3Query -- 众所周知，Prometheus努力处理显示大量数据的查询，而不是从Prometheus提取数据，M3Query实现了相同的PromQL并可以响应此类请求。
• M3Aggregator -- 可选但很重要，此服务将降低指标的采样率，为长期存储做好准备。

整体架构图如下：

关于M3，我们目前积累了一些生产实践。目前的问题是，社区不够活跃，文档也不够丰富。很多时候遇到问题，只能去研究代码。M3query对PromSql支持的不够，所以M3query并不能生产环境使用。

VictoriaMetrics

VictoriaMetrics是一种快速，经济高效且可扩展的时间序列数据库，可用作Prometheus的长期远程存储。

VictoriaMetrics 包括了如下的组件：

• vmstorage -- 存储数据。
• vminsert -- 通过remote_write API接收来自Prometheus的数据并将其分布在可用的vmstorage节点上。
• vmselect -- 通过从vmstorage节点获取并合并所需数据，通过Prometheus查询API执行传入查询。

每个组件可以使用最合适的硬件配置独立扩展到多个节点。

整体架构图如下：

上图中与负载平衡器框一起的VictoriaMetrics集群框可以在Kubernetes中运行，并且可以通过Helm图表进行管理。

该系统的优势是架构简单，性能也比较高，依赖于块存储。但是数据没有副本，有丢失数据的可能。为此，为大家提供了vmbackup和vmrestore组件。

如果我们认为我们的监控数据是可以允许丢失一部分，那么这种VictoriaMetrics将非常值得投入。

总结

本文简单介绍了Prometheus远程读写存储，并详细介绍了几种开源的远程存储方案。接下来，会专门介绍一下M3，介绍一下我们实际生产中运行的实践。

有疑问加站长微信联系（非本文作者）