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

iyacontrol · · 935 次点击 · · 开始浏览    
这是一个创建于 的文章,其中的信息可能已经有所发展或是发生改变。

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

victoriametrics.png

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

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

架构预览

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

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

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

vc01.png

集群运维

集群安装

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

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

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

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

监控

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

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

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

image.png

集群扩缩容

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

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

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

增加vmstorage节点的步骤:

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

重新变更节点

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

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

容量规划

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

vminsert

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

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结合

victoria.jpg

配置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/writeinflux/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中获取数据。

具体架构如下:

vectoria-p.jpg

结论

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


有疑问加站长微信联系(非本文作者)

本文来自:Segmentfault

感谢作者:iyacontrol

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

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:701969077

935 次点击  
加入收藏 微博
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传