利用Prometheus 打造企业分布式监控平台(8)--VictoriaMetrics集群

在之前的系列文章中，我们讲到了一个远程存储对于企业级Prometheus的重要性，以及Thanos和VictoriaMetrics的对比。今天我们主要讲VictoriaMetrics，包括集群部署和如何与Prometheus结合。

VictoriaMetrics是一个高性能，低成本，可扩展的时序数据库。可以用来做Prometheus的长期存储。分为单机版本和集群版本，均已开源。如果数据写入速率低于每秒​​一百万个数据点，官方建议使用单节点版本而不是集群版本。

当然单机版本配置简单，可以通过纵向扩展的方式来提升性能。不过作为一个企业级的监控系统，选择集群版本，也就是选择横向扩展。

架构预览

VictoriaMetrics集群包含下面三个组件：

• vmstorage- 存储数据
• vminsert- 使用一致的哈希将获取的数据写入到vmstorage分片
• vmselect- 使用vmstorage中的数据执行查询

每个服务都可以独立扩展并可以在最合适的硬件上运行。vmstorage节点彼此之间不了解，不相互通信且不共享任何数据。这是不共享任何体系结构的。它提高了群集的可用性，简化了群集维护和群集扩展。

集群运维

集群安装

一个最小化的集群包含三个部分：

• 单个vmstorage节点。-retentionPeriod 和-storageDataPath命令行参数指定metrics保留时间和数据存储路径。
• 单个vminsert节点。通过-storageNode = <vmstorage_host>:8400建立与vmstorage的关系。
• 单个vmselect节点。通过-storageNode = <vmstorage_host>:8401建立与vmstorage的关系。

当然出于高可用的考虑，每个部分需要包含2+的节点。此时vminsert和vmselect前端各自需要一个负载均衡器。

• 以/insert 开头的请求必须路由到vminsert节点上的端口8480。
• 以/select开头的请求必须路由到vmselect节点上的端口8481。

监控

监控必不可少了。所有集群组件通过-httpListenAddr命令行参数指定暴露Prometheus兼容格式公开各种度量标准的端口。默认情况下，使用以下TCP端口：

• vminsert- 8480
• vmselect- 8481
• vmstorage- 8482

官方也提供了相应的grafana监控大图。

集群扩缩容

群集性能和容量可通过添加新节点来扩展。

vminsert和vmselect节点是无状态的，可以随时添加/删除。别忘了在http负载均衡器上更新这些节点的列表。添加更多的vminsert节点可以提高数据的写入速率。添加更多的vmselect节点可以提高数据查询速率。

vmstorage节点承载写入的数据，因此无法删除它们而不会丢失数据。添加更多的vmstorage节点可扩展群集容量。

增加vmstorage节点的步骤：

1. 使用与集群中现有节点相同的-retentionPeriod启动新的vmstorage节点。
2. 更改-storageNode命令行参数，增加<new_vmstorage_host>:8401，然后逐步重新启动所有vmselect节点：。
3. 更改-storageNode命令行参数，增加<new_vmstorage_host>:8400，然后逐步重新启动所有vminsert节点。

重新变更节点

可以通过正常关闭来更新所有节点类型-vminsert，vmselect和vmstorage-将SIGINT信号发送到相应的进程，等待其完成，然后使用新的配置启动新版本。

如果在更新过程中每种类型的至少一个节点仍然可用，则集群保持工作状态。

容量规划

每个实例类型（vminsert，vmselect和vmstorage）都可以在最合适的硬件上运行。

vminsert

• 可以根据写入数据速率计算所有vminsert实例的建议vCPU内核总数：vCPU =写入速率/150K。
• 每个vminsert实例的建议vCPU核心数应等于集群中的vmstorage实例数。
• 每个vminsert实例的RAM量应为1GB或更多。RAM用作缓冲区，以应对峰值速率。
• 有时，vminsert实例上的-rpc.disableCompression命令行标志可能会增加数据写入容量，但代价是vminsert和vmstorage之间的网络带宽使用率更高。

vmstorage

• 可以根据数据写入速率计算所有vmstorage实例的建议vCPU内核总数：vCPU =写入速率/ 150K。
• 可以从活跃时间序列数中计算出所有vmstorage实例的建议RAM总量：RAM = active_time_series * 1KB。如果时间序列在最后一个小时内至少收到一个数据点，或者已经接收到一个时间点，则该时间序列是活跃的在最后一个小时查询。
• 可以根据写入速率和保留时间来计算所有vmstorage实例的建议存储空间总量：storage_space =ingestion_rate * retention_seconds。

vmselect

vmselect实例的推荐硬件在很大程度上取决于查询的类型。少量时间序列上的轻量级查询通常需要vmselect上的vCPU内核数量少和RAM量少，而大量时间序列上的重量查询（> 10K）通常需要更多数量的vCPU内核和更大数量的RAM。

副本和数据安全

VictoriaMetrics将副本放到-storageDataPath所指向的基础存储上。建议将数据存储在Google Compute Engine永久磁盘上，因为它们可以防止数据丢失和数据损坏，还可以提供一致的高性能，并且可以调整大小而不会停机。对于大多数用例来说，基于持久性磁盘就足够了。

部署

官方提供了Helm包。可以快速安装。

当然官方也提供了docker镜像和可执行文件。

与Prometheus结合

配置Prometheus远程写，如下：

remote_write:
  - url: http://vminsert:8480/insert/0/prometheus

PS:
VictoriaMetrics集群版本数据写入的URL为 http://<vminsert>:8480/insert/<accountID>/<suffix>。

• accountID代表租户ID

• suffix可能有下面的值：

  • prometheus-用于使用Prometheus远程写入API插入数据
  • influx/write或influx/api/v2/write-使用Influx协议写入数据
  • opentsdb/api/put-用于接受OpenTSDB HTTP请求。
  • prometheus/api/v1/import-用于导入通过api/v1/export 导出的vmselect中数据。

然后，如果只是单纯的grafana展示，那么可以参考上面的架构图，在grafana中增加Prometheus数据源，地址为vmselect的负载均衡器的VIP即可，如下：

http://vmselect:8481/select/0/prometheus/ 

但是在实际场景下，我们往往需要报警，对接alertmanager。那么此时，可以将Prometheus分为两种角色。查询Prometheus和采集Prometheus。因为我们在查询端需要配置Prometheus的rules，来实现报警。

此时，查询Prometheus需要配置远程读，从vmselect中获取数据。

具体架构如下：

结论

本文简单介绍了VictoriaMetrics的架构和运维。并给出了VictoriaMetrics+prometheus的解决方案。