gpt4 book ai didi

TSDB-VictoriaMetrics技术原理浅析

转载 作者:我是一只小鸟 更新时间:2023-04-02 22:31:20 56 4
gpt4 key购买 nike

版权说明: 本文章版权归本人及博客园共同所有,转载请在文章前标明原文出处( https://www.cnblogs.com/mikevictor07/p/17258452.html ),以下内容为个人理解,仅供参考.

  。

1、前言 。

     在监控领域,通常需要指标存储组件TSDB,目前开源的TSDB组件比较多,各个组件性能、高可用性、维护成本等等各有差异。本文不分析选型问题,重点讲解VictoriaMetrics(后面简称为vm).

     有兴趣的朋友建议结合源码进行分析,由于源码不断变更, 此分析基于 v1.80.0 ,后续版本变化理论上不会很大.

  。

2、架构与能力 。

   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,性能下降严重).

  。

  。

  。

  。

3、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目录直接迁移走即可在另一主机运行.

  。

  。

4、运维&监控能力、Downsample 。

  (1)vm配置有grafana的监控模板,安装即可观测各个模块的性能,需要结合代码才能比较深入的了解各个指标的作用含义(不过最前面部分的CPU/内存总量的计算貌似不正确,未深究,有兴趣可以看看什么问题).

  (2)vm写入由于没有WAL,如果出现大量缓存失效则容易出现慢写入,甚至大量超时,所以写入建议前置一个MQ(如kafka)缓解写入异常放大,写入模块做一定的异常限流防止查询也出现大量超时.

  (3)vm很吃内存和磁盘,磁盘随机IO很多,建议配置SSD.

  (4)vm开源版不支持存储层的downsample(企业版才支持),故会查询原始数据后通过promQL配置采样减少输出点,但总的来说不是存储层的downsample查询时间范围过大时会有很大的压力(比如一个月以上),建议上报的数据 1分钟 一个点位减少数据量.

  。

5、性能见解与总结 。

  官方写了一些英文博文对比influxdb的性能,vm的表现优异,但建议实测(官方提供的总有一些趋向性)。从个人的测试数据上看表现确实很不错,数据不方便公开,建议自测.

  总之,此款基于golang的开源TSDB性能表现很好,要能驾驭这组件需要比较多的功力, 不能单纯从表层去把它当做一个黑盒来运维,以免后续出现慢写入慢查询会变得手足无措 .

  源码层面的分析可以搜索下其他文章,在此就不再分析代码段.

  。

最后此篇关于TSDB-VictoriaMetrics技术原理浅析的文章就讲到这里了,如果你想了解更多关于TSDB-VictoriaMetrics技术原理浅析的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。

56 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com