在之前的系列文章中,我们讲到了一个远程存储对于企业级Prometheus的重要性,以及Thanos和VictoriaMetrics的对比。今天我们主要讲VictoriaMetrics,包括集群部署和如何与Prometheus结合。
VictoriaMetrics是一个高性能,低成本,可扩展的时序数据库。可以用来做Prometheus的长期存储。分为单机版本和集群版本,均已开源。如果数据写入速率低于每秒一百万个数据点,官方建议使用单节点版本而不是集群版本。
当然单机版本配置简单,可以通过纵向扩展的方式来提升性能。不过作为一个企业级的监控系统,选择集群版本,也就是选择横向扩展。
架构预览
VictoriaMetrics集群包含下面三个组件:
-
vmstorage
- 存储数据 -
vminsert
- 使用一致的哈希将获取的数据写入到vmstorage分片 -
vmselect
- 使用vmstorage中的数据执行查询
每个服务都可以独立扩展并可以在最合适的硬件上运行。vmstorage节点彼此之间不了解,不相互通信且不共享任何数据。这是不共享任何体系结构的。它提高了群集的可用性,简化了群集维护和群集扩展。
集群运维
集群安装
一个最小化的集群包含三个部分:
- 单个
vmstorage
节点。-retentionPeriod
和-storageDataPath
命令行参数指定metrics保留时间和数据存储路径。 - 单个
vminsert
节点。通过-storageNode =
建立与:8400 vmstorage
的关系。 - 单个vmselect节点。通过
-storageNode =
建立与: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
节点的步骤:
- 使用与集群中现有节点相同的-retentionPeriod启动新的
vmstorage
节点。 - 更改
-storageNode
命令行参数,增加:8401,然后逐步重新启动所有 vmselect
节点:。 - 更改
-storageNode
命令行参数,增加: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://
。
-
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的解决方案。