VictoriaMetrics 简介

VictoriaMetrics(VM) 是一个支持高可用、经济高效且可扩展的监控解决方案和时间序列数据库，可用于 Prometheus 监控数据做长期远程存储。

前面章节我们介绍了 Thanos 方案也可以用来解决 Prometheus 的高可用和远程存储的问题，那么为什么我们还要使用 VictoriaMetrics 呢？相对于 Thanos，VictoriaMetrics 主要是一个可水平扩容的本地全量持久化存储方案(性能比thanos性能要好，thanos不是本地全量的，它很多历史数据是存放在对象存储当中的，如果要查询历史数据都要从对象存储当中去拉取，这肯定比本地获取数据要慢)，VictoriaMetrics 不仅仅是时序数据库，它的优势主要体现在一下几点。

• 对外支持 Prometheus 相关的 API，可以直接用于 Grafana 作为 Prometheus 数据源使用
• 指标数据摄取和查询具备高性能和良好的可扩展性，性能比 InfluxDB 和 TimescaleDB 高出 20 倍
• 在处理高基数时间序列时，内存方面也做了优化，比 InfluxDB 少 10x 倍，比 Prometheus、Thanos 或 Cortex 少 7 倍
• 高性能的数据压缩方式，与 TimescaleDB 相比，可以将多达 70 倍的数据点存入有限的存储空间，与 Prometheus、Thanos 或 Cortex 相比，所需的存储空间减少 7 倍
• 它针对具有高延迟 IO 和低 IOPS 的存储进行了优化
• 提供全局的查询视图，多个 Prometheus 实例或任何其他数据源可能会将数据摄取到 VictoriaMetrics

• 操作简单

• VictoriaMetrics 由一个没有外部依赖的小型可执行文件组成

• 所有的配置都是通过明确的命令行标志和合理的默认值完成的
• 所有数据都存储在 - storageDataPath 命令行参数指向的目录中

• 可以使用 vmbackup/vmrestore 工具轻松快速地从实时快照备份到 S3 或 GCS 对象存储中

• 支持从第三方时序数据库获取数据源

• 由于存储架构，它可以保护存储在非正常关机（即 OOM、硬件重置或 kill -9）时免受数据损坏
• 同样支持指标的 relabel 操作

架构

---

VM 分为单节点和集群两个方案，根据业务需求选择即可。单节点版直接运行一个二进制文件既，官方建议采集数据点(data points)低于 100w/s，推荐 VM 单节点版，简单好维护，但不支持告警。集群版支持数据水平拆分。下图是 VictoriaMetrics 集群版官方的架构图。

上面这里是客户端，比如grafana，它通过负载均衡去查询我们的数据，vmselect是一个无状态的，如果有压力就可以随意去扩展，它从存储上面获取数据，然后返回回去。

vmstorge是有状态的，它是整个集群组件里面唯一一个有状态的组件，所有的时序数据都是存储在这个vmstorge里面的。

vminsert也是一个无状态的，所以也可以随便水平去扩展，它是将数据插入到vmstorge里面去的，可以通过Prometheus远程写的接口将数据写到vminsert。

所以分为了两端，一端是vminsert写数据，一端是vmselect将数据查询出来。

写入数据的来源除了来自于Prometheus，还支持其他数据库。

主要包含以下几个组件：

• vmstorage：数据存储以及查询结果返回，默认端口为 8482
• vminsert：数据录入，可实现类似分片、副本功能，默认端口 8480（可以将数据分片插入到多个storage实例当中去，具体怎么插入是有一套算法）
• vmselect：数据查询，汇总和数据去重，默认端口 8481
• vmagent：数据指标抓取，支持多种后端存储，会占用本地磁盘缓存，默认端口 8429
• vmalert：报警相关组件，不如果不需要告警功能可以不使用该组件，默认端口为 8880

集群方案把功能拆分为 vmstorage、 vminsert、vmselect 组件，如果要替换 Prometheus，还需要使用 vmagent、vmalert（如果完全不想使用Prometheus，那么可以使用vmagent，

）。从上图也可以看出 vminsert 以及 vmselect（几乎）都是无状态的，所以扩展很简单，只有 vmstorage 是有状态的。

vmagent 特性

vmagent 相比于 Prometheus 抓取指标来说具有更多的灵活性，比如除了拉取（pull）指标还可以推送（push）指标，此外还有很多其他特性：

• 可以替换 prometheus 的 scraping target
• 支持从 Kafka 读写数据
• 支持基于 prometheus relabeling 的模式添加、移除、修改 labels，可以在数据发送到远端存储之前进行数据的过滤
• 支持多种数据协议，influx line 协议，graphite 文本协议，opentsdb 协议，prometheus remote write 协议，json lines 协议，csv 数据等
• 支持收集数据的同时，并复制到多种远端存储系统
• 支持不可靠远端存储，如果远程存储不可用，收集的指标会在 -remoteWrite.tmpDataPath 缓冲，一旦与远程存储的连接被修复，缓冲的指标就会被发送到远程存储，缓冲区的最大磁盘用量可以用 -remoteWrite.maxDiskUsagePerURL 来限制。
• 相比 prometheus 使用更少的内存、cpu、磁盘 io 以及网络带宽
• 当需要抓取大量目标时，抓取目标可以分散到多个 vmagent 实例中
• 可以通过在抓取时间和将其发送到远程存储系统之前限制唯一时间序列的数量来处理高基数和高流失率问题
• 可以从多个文件中加载 scrape 配置

支持的功能和Prometheus差不多，可以去读取Prometheus的配置，也支持rebleing，支持添加全局的标签，持久化数据到数据盘。

还支持远程写的协议，写到vm当中。

外面就是可以主动去抓取我们的指标。 

如果你是从头去搭建你的监控系统，其实你一开始就可以不使用Prometheus，可以直接使用vm，只不过报警功能有点弱。如果vmalter做好了这块，完全没有Prometheus什么事情了，因为在内存和存储，查询方面都要优于Prometheus。