版权说明: 本文章版权归本人及博客园共同所有,转载请在文章前标明原文出处( https://www.cnblogs.com/mikevictor07/p/17258452.html ),以下内容为个人理解,仅供参考。
一、前言
在监控领域,通常需要指标存储组件TSDB,目前开源的TSDB组件比较多,各个组件性能、高可用性、维护成本等等各有差异。本文不分析选型问题,重点讲解VictoriaMetrics(后面简称为vm)。
有兴趣的朋友建议结合源码进行分析,由于源码不断变更,此分析基于 v1.80.0,后续版本变化理论上不会很大。
二、架构与能力
vm开源版本分为single-server(all in one)的单节点模式和cluster模式,单点模式合适本地调试或测试使用,生产使用的cluster模式分为vmselect、vminsert、vmstorage三个主要模块:
(1)vmselect:查询模块,可无状态部署,客户端发送请求到查询模块后,查询模块会把请求分发到所有storage模块(由于没有元数据中心节点,固数据存储在哪无法感知,类似clickhouse的设计模式),得到原始的block数据后在select模块进行合并,再得到一个总结果。
(2)vminsert:写入模块,可无状态部署,写入数据的请求发到此模块后,根据labels通过一定的hash计算出一个值,根据这个值确定此条数据发往哪个storage节点。因此相同的时间线会往同一个点节点发送,如果有某个时间线数据量特别大则会出现数据倾斜问题后某个storage写入和查询压力都会增大。在扩容货缩容后,由于节点的列表变更,固计算出的hash发往的storage节点也会变更。
(3)vmstorage:存储模块,有状态,存储模块的移除须先从select和insert的配置中移除才不会有异常,此模块压力最大,非常消耗内存和IO,固推荐使用SSD和比较大的内存,宁愿用大规格的机器也不用量多但规格较小的机器(缓存不命中则会造成较多的IO,性能下降严重)。
三、vmstorage 存储模块
本文重点讲难度最高的 storage 模块,也只是属于个人理解,如有错误或偏差,望指正。
1、存储目录结构
/data 数据目录的逻辑结构如下:
(1)每个block只包括一个时间线,内部根据时间排序。
(2) 每个block最大容纳8000个sample,不同block可并发处理。
2、 写入流程与风险点
3、查询流程与风险点
4、数据过期机制
开源的cluster版本只能针对租户使用全局的统一过期时间,收费的企业版才能支持租户单独设置过期时间。
5、数据安全性保障
(1)VictoriaMetrics 并未使用WAL,而是直接写入类似SSTable的内存结构中,定时刷写磁盘,这是此模块能表现出极高的写入性能的一个原因,如果是单副本则宕机时有可能照成最近的少量数据丢失,如果是数据安全性要求极高的场景,则建议开启双副本模式。
(2)双副本状态下,写入性能有一定的下降。即使在双副本模式下,不能同时下线两台主机,如果同时下掉两台主机则数据会丢失,为保证数据安全,建议对存储层配置RAID1、RAID5或RAID10保证数据安全性,迁移时将数据从data目录直接迁移走即可在另一主机运行。
四、运维&监控能力、Downsample
(1)vm配置有grafana的监控模板,安装即可观测各个模块的性能,需要结合代码才能比较深入的了解各个指标的作用含义(不过最前面部分的CPU/内存总量的计算貌似不正确,未深究,有兴趣可以看看什么问题)。
(2)vm写入由于没有WAL,如果出现大量缓存失效则容易出现慢写入,甚至大量超时,所以写入建议前置一个MQ(如kafka)缓解写入异常放大,写入模块做一定的异常限流防止查询也出现大量超时。
(3)vm很吃内存和磁盘,磁盘随机IO很多,建议配置SSD。
(4)vm开源版不支持存储层的downsample(企业版才支持),故会查询原始数据后通过promQL配置采样减少输出点,但总的来说不是存储层的downsample查询时间范围过大时会有很大的压力(比如一个月以上),建议上报的数据1分钟一个点位减少数据量。
五、性能见解与总结
官方写了一些英文博文对比influxdb的性能,vm的表现优异,但建议实测(官方提供的总有一些趋向性)。从个人的测试数据上看表现确实很不错,数据不方便公开,建议自测。
总之,此款基于golang的开源TSDB性能表现很好,要能驾驭这组件需要比较多的功力,不能单纯从表层去把它当做一个黑盒来运维,以免后续出现慢写入慢查询会变得手足无措。
源码层面的分析可以搜索下其他文章,在此就不再分析代码段。
手机扫一扫
移动阅读更方便
你可能感兴趣的文章