利用Prometheus 打造企业分布式监控平台(3)--远程读写之战

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，介绍一下咱们实际生产中运行的实践。