VictoriaMetrics入门与实战

01

简介

VictoriaMetrics，是一个快速高效、经济并且可扩展的监控解决方案和时序数据库。

谈到VictoriaMetrics就必须要提到Prometheus，VictoriaMetrics是一个新兴的监控解决方案。它借助Prometheus强大的exporter生态、成熟的规范、服务发现等优点等，融入到Prometheus生态中。VictoriaMetrics官网很多兼容Prometheus参数解释都是直接跳转到Prometheus官网。

VictoriaMetrics可以作为Prometheus的长期远程存储方案，当然VictoriaMetrics也可以完全取代Prometheus，因为VictoriaMetrics基本支持Prometheus配置文件、PromQL、各类API、数据格式等等。

作为一款新兴TSDB，参考DB-Engines的TSDB排行，最近两年VictoriaMetrics热度很高：

注意：下面无特殊声明统一把VictoriaMetrics简写成VM。

1.1 VM优点

• 远程存储：可作为单一或多个Prometheus的远程存储

• 安装简单：单节点架构一条命令就可以部署完毕（集群方式稍微复杂一些，但也很好理解）

• 兼容性：PromQL兼容和增强的MetricsQL

• Grafana兼容：VM可替换Grafana的Prometheus数据源（经测试，线上数据源直接替换后100%兼容）

• 低内存：更低的内存占用，官方对比Prometheus，可以释放7倍左右内存空间（线上对比大概4倍）

• 高压缩比：提供存储数据高压缩，官方说可以比Prometheus减少7倍的存储空间（线上对比大概是4~5倍）

• 高性能：查询性能比Prometheus更快

• 支持水平扩容&HA：基于VM集群版实现

• 支持多租户：主要针对集群版

1.2 VM缺点

• 图形化做的不好，虽然有vmui，但功能很少

• 告警功能需要单独配置vmalert，而且vmalert只有api管理和查看，暂时没用图形界面

• 没有类似Prometheus的WAL日志，突然故障可能会丢失部分数据

1.3 VM分类

VM分为，单节点(single-node)版和集群(cluster)版，两套方案，根据业务需求选择即可。

单节点版：直接运行一个二进制文件，既可以运行，官方建议采集数据点(data points)低于100w/s，推荐VM单节点版，简单好维护，但不支持告警。

集群版：支持数据水平拆分，把功能拆分为vmstorage、 vminsert、vmselect，如果要替换Prometheus，还需要vmagent、vmalert。

1.4 官方网址

• 官网：https://victoriametrics.com

• 官方文档：https://docs.victoriametrics.com

• GitHub：https://github.com/VictoriaMetrics/VictoriaMetrics

1.5 部分名词解释

1）关于样本：

在时间序列（time-series）中的每一个点称为一个样本(sample)，样本(sample)由以下三部分组成：

指标（metric）：指标名和一组描述当前样本特征的labelsets唯一标识

时间戳（timestamp）：一个精确的时间戳，一般由采集时间决定（VM为秒，Prometheus为毫秒）

样本值（value）：当前样本的值

2）关于target：

每一个监控目标称为一个target，如：单个node-exporter、mysqld-exporter等等。

02

案例

下面列出部分官方案例，主要针对写和查，以供参考。

使用方	VM版本	写入数据点量	总数据量	99%查询耗时
Synthesio	单节点版	55万/秒	1.25万亿	147ms
Wix.com	单节点版	110万/秒	8.5万亿	1seconds
German	单节点版	2.4万/秒	1600亿	6.5ms
Wedos.com	集群版	17万/秒	未提供	50ms

综上，VM单节点版，和官方说的每秒抓取100w左右的数据点(data point也可以简单理解为1个样本)问题不大，如果单个target的样本数是1000个左右，那每秒VM就可以抓取100w/1000，预估一下，VM单节点版可以实现，大概1000个target/s 的抓取量。可根据自己的业务量，简单评估一下VM单节点是否适合自己的业务。

另外，DBA们比较熟悉的PMM(Percona Monitoring and Management )监控套件，在2.12版本开始也用VictoriaMetrics替换掉了Prometheus（https://www.percona.com/blog/2020/12/16/percona-monitoring-and-management-migration-from-prometheus-to-victoriametrics-faq/）。

03

VM单节点版

下面模拟2个node-exporter，被Prometheus采集数据，然后Prometheus把数据写到VM远程存储。通过Grafana分别对2种数据源（Prometheus、VictoriaMetrics）进行展示，验证VM的兼容性。最终使用VM完全替换Prometheus，可以达到架构简单、更低的资源占用。

各服务部署如下表：

服务名称	IP	PORT
node-exporter	192.168.1.100 192.168.1.101	9100
Prometheus	192.168.1.102	9090
VM单机版		8428
Grafana		3000

说明：

用VM单机版，可以替换Prometheus，前提是没有用到告警功能，否则还要引入vmalert。下面只是示例，为了好理解整体流程，大多数参数都用的默认值启动，实际线上建议修改部分默认参数。Grafana的Dashboard选了一个官网用的比较多，展示类型相对丰富的，主要是为了验证VM兼容性。

3.1 node-exporter配置

# 在2台主机上分别执行如下命令，来安装node-exporter
cd /usr/local
wget https://github.com/prometheus/node_exporter/releases/download/v1.2.2/node_exporter-1.2.2.linux-amd64.tar.gz
tar -xvzf node_exporter-1.2.2.linux-amd64.tar.gz && mv node_exporter-1.2.2.linux-amd64 node_exporter && cd node_exporter
nohup ./node_exporter &

3.2 Prometheus配置

# 在192.168.1.102主机安装Prometheus
cd /usr/local
wget https://github.com/prometheus/prometheus/releases/download/v2.30.0/prometheus-2.30.0.linux-amd64.tar.gz
tar -xvzf prometheus-2.30.0.linux-amd64.tar.gz && mv prometheus-2.30.0.linux-amd64 prometheus && cd prometheus


cat > prometheus.yml << EOF
global:
  scrape_interval:     15s
scrape_configs:
  - job_name: 'linux'
    static_configs:
    - targets: ['192.168.1.100:9100']
    - targets: ['192.168.1.101:9100']
    relabel_configs:   # 通过relabeling替换从__address__中提取IP信息，主要是为了后面验证VM是否兼容relabeling
    - source_labels:  ['__address__']
      regex: '(.*):(.*)'
      action: replace
      target_label: 'ip'
      replacement: '\${1}'
EOF
nohup ./prometheus --config.file="prometheus.yml" --storage.tsdb.retention=30d --web.enable-lifecycle &

3.3 Grafana配置

# 在192.168.1.102主机安装Grafana
cd /usr/local
wget https://dl.grafana.com/oss/release/grafana-8.1.3.linux-amd64.tar.gz
tar -zxvf grafana-8.1.3.linux-amd64.tar.gz && mv grafana-8.1.3 grafana && cd grafana
nohup ./bin/grafana-server -config=./conf/defaults.ini &


# 注：Grafana默认账号密码都为admin

打开Grafana添加Prometheus数据源

下载node-exporter的dashboard，并导入。

下载地址：https://grafana.com/api/dashboards/12377/revisions/1/download

至此，已经配置完基本的Prometheus收集主机性能方案。下面将展示，用VM单节点版 存储或者替换Prometheus。

3.4 VM单节点版-作为Prometheus远程存储

# 在192.168.1.102上，安装VM单节点版，作为Prometheus的远程存储（因为只是测试，所以安装在同一台机子上了）
cd /usr/local
wget https://github.com/VictoriaMetrics/VictoriaMetrics/releases/download/v1.65.0/victoria-metrics-amd64-v1.65.0.tar.gz
mkdir victoria-metrics && tar -xvzf victoria-metrics-amd64-v1.65.0.tar.gz && \
mv victoria-metrics-prod victoria-metrics/victoria-metrics && cd victoria-metrics
nohup ./victoria-metrics -retentionPeriod=30d -storageDataPath=data &


# 配置Prometheus远程存储
cat >> /usr/local/prometheus/prometheus.yml << EOF
global:
  scrape_interval:     15s
scrape_configs:
  - job_name: 'linux'
    static_configs:
    - targets: ['192.168.1.100:9100']
    - targets: ['192.168.1.101:9100']
    relabel_configs:   # 通过relabeling替换从__address__中提取IP信息
    - source_labels:  ['__address__']
      regex: '(.*):(.*)'
      action: replace
      target_label: 'ip'
      replacement: '\${1}'
remote_write:    # 存储到远程VM存储（这里只是示例，所以Prometheus和VM在一台机子上）
  - url: http://127.0.0.1:8428/api/v1/write
    queue_config:    # 如果Prometheus抓取指标很大，可以加调整queue，但是会提高内存占用
      max_samples_per_send: 10000
      capacity: 20000
      max_shards: 30  
EOF


# 重启Prometheus
kill -HUP `pidof prometheus`

在Grafana上，使用VM替换Prometheus源

再次访问Grafana，用VM替换Prometheus源后，显示正常，确定VM是兼容的。

3.5 VM单节点版-替换Prometheus(推荐)

开启Prometheus的remote_write功能，会导致Prometheus占用主机资源增加，其实完全可以用VM替换Prometheus，这样既节省了开启remote_write占用的资源，还能降低原有Prometheus的资源占用（CPU、内存、磁盘）。

# 直接把Prometheus配置文件复制当VM目录，并关闭Prometheus
cp /usr/local/prometheus/prometheus.yml /usr/local/victoria-metrics/
kill `pidof prometheus` && sleep 2 && ps -ef|grep prometheus


# 不需要做任何改动，直接使用VM加载Prometheus配置文件
cd /usr/local/victoria-metrics && kill `pidof victoria-metrics`
nohup ./victoria-metrics -retentionPeriod=30d -storageDataPath=data -promscrape.config=prometheus.yml &

如下图，查看VM的log文件，VM已经加载Prometheus配置文件成功，并开始抓取2个target（node-exporter）性能指标。

切换到Grafana页面，确定VM通过Prometheus配置文件，抓取target样本数据，并且展示正常。

至此，通过VM彻底替换Prometheus，并确定target数据可以正常抓取，并在Grafana正常展示。

04

兼容性

4.1 API兼容性

1）VM支持Prometheus querying API，主要如下：

/api/v1/query

/api/v1/query_range

/api/v1/series

/api/v1/labels

/api/v1/label/…/values

/api/v1/status/tsdb

/api/v1/targets

2）也有(query和query_range)部分增强功能，如下：

• 查询细化：/api/v1/query_range?extra_label=user_id=123&query= 

• 相对时间：/api/v1/query_range?start=-30m&query=...

• 小数取舍：/api/v1/query?query=avg_over_time(temperature[1h])&round_digits=2

注：除非必要，建议不用，这样就算回到Prometheus技术栈也没问题

3）还新增部分VM自身数据统计API：

/api/v1/series/count ：返回VM时间序列的总数

/api/v1/labels/count ：列出VM所有label数量统计，如上面的instance、ip、job等就是label

/api/v1/status/active_queries ：返回当前VM运行的查询语句

/api/v1/status/top_queries：返回查询TopN，展示维度topByCount(查询次数)、topByAvgDuration(平均查询时间)、topBySumDuration(总查询时间)

4.2 服务发现兼容性

VM基本兼容Prometheus大多数常用的服务发现与抓取类型，部分线上已测试，更多可兼容类型如下：

• static_config（已测试）

• file_sd_config（已测试）

• kubernetes_sd_config

• ec2_sd_config

• gce_sd_config

• consul_sd_config（已测试）

• dns_sd_config

• openstack_sd_config

• docker_sd_config

• dockerswarm_sd_config

• eureka_sd_config

• digitalocean_sd_config

• http_sd_config

05

性能对比

5.1 环境简介

下面只是对VM和Prometheus做了一下简单的查询性能对比，本次测试把VM和Prometheus放到同一台主机上（主机可用资源充裕），用同一个Prometheus配置文件，并抓取同样的线上target，来保证基准环境相同。

5.2 查询逻辑

每组同时并发24个请求，每个请求统计1个小时内的，磁盘使用率和MySQL OPS的Top10，

然后每组请求3次，求平均值。部分代码逻辑如下：

测试结果：

执行相同查询逻辑后，VM大约可以比Prometheus，节省1倍多的查询时间。

06

存储目录简介

6.1 根目录

VM根目录，主要文件如下：

下面主要介绍 数据目录 和 索引目录。

6.2 数据目录

数据目录data，最主要的就是 small 和 big 目录，这两个目录同时创建，结构是一样的。

• small目录：内存中的数据先持久化此目录，压比例高，会定期检测判断是否满足merge条件，合并多个小文件。

• big目录：small过大后会合并到big目录，压比例极高。

small目录和big目录的存在，主要是兼顾近期数据读取和历史数据压缩的需求。下面简单介绍一下small具体目录作用（big目录类似）：

small目录，按照月生成partition目录，比如下图中的2021_09目录，每个partition目录包括 partition目录、临时目录、事物目录 三类目录。内存中数据每刷一次盘，就会生成一个partition目录，如下图的

“5004_1251_20210916071840.019_20210916071929.037_16A53BF0BA13671D”，5004表示包括的数据行数(抓取的数据点数量)，1251表示数据块数，20210916071840.019_20210916071929.037表示此partition目录覆盖数据的时间戳范围，最小时间_最大时间，16A53BF0BA13671D目录生成的系统时间，纳秒时间戳的16进制。

6.3 索引目录

索引目录，与数据目录不同的是，索引目录是由多个table目录组成，每个目录会根据保留周期迭代，并且完全自治。

关于TSID：

VM在接收写数据后，会根据包含metric和labels的MetricName生成一个唯一标识TSID，然后metric + labels + TSID作为索引index， TSID + timestamp + value作为数据data。其中，索引部分主要是用于支持按照label或者tag进行多维检索。

07

关于去重

这里单独把VM的去重逻辑列出来，笔者感觉这个比较重要，去除重复既可以节省存储空间，还能降低查询时的资源占用。当有多个Prometheus或者vmagent（配置文件里global的external_labels内容相同），写入到同一个VM里，VM启动如果指定了-dedup.minScrapeInterval=60s，则指定的时间为一个时间范围(官方称为bucket)，这里为60s，在60s内：

1）相同的样本数据点，最早的会被保留

2）如果timestamps相同，则随机保留1个

推荐：-dedup.minScrapeInterval等于Prometheus或vmagent的scrape_interval（抓取数据间隔）

注意：不管是VM单节点版，还是VM集群版本，去重的逻辑都相同。

08

HA架构

VM单节点版的高可用方案，其实和Prometheus的HA方案差不多，只是官方建议使用vmagent替换Prometheus来进行数据采集。

自由组合的方案很多，笔者认为如下两个方案比较有代表性，大家也可以根据自己业务需求进行搭建。

方案1：不同机房多个VM（抓取量小~中等）

推荐使用此高可用架构，简单够用，正常情况下15~30s抓取间隔，同时小于1万的target，完全能应付的过来。

方案2：vmagent分组，写入多个区域并冗余VM（抓取量大）

当抓取数据里很大或者target很多时，单个VM节点往往处理不过来，这时候可以通过vmagent自动分组或者手动分组进行抓取，数据分组存储在后端VM。为了保证跨机房HA，vmagent分别把数据写到本机房和跨机房的VM单节点。

并通过Promxy把多个VM单节点数据进行汇总和简单展示。这里没有直接用VM进行分组抓取，而用vmagent进行多写，主要是能减少单个target被抓取次数，降低target负载。

建议：这种架构其实已经很接近VM集群版了，可以调研VM集群版来替换此方案。

09

图形界面

VM单节点版自带一个web的图形界面，叫vmui，目前还是Beta版本，功能比较简单，只能针对当前节点执行样本数据查询。

如果用惯了Prometheus自带的Web界面，推荐使用Promxy，而且promxy还可以进行多个VM单节点的数据聚合，以及target查看等。

9.1 vmui

vmui已经集成在VM单节点版的二进制文件里，直接访问即可。

访问地址：http://192.168.1.102:8428/vmui

9.2 Promxy

Promxy主要兼容的是Prometheus，但对VM基本的使用还是没问题的，安装配置也很简单：

cd /usr/local
wget https://github.com/jacksontj/promxy/releases/download/v0.0.72/promxy-v0.0.72-linux-amd64
mkdir promxy && mv promxy-v0.0.72-linux-amd64 promxy/promxy && cd promxy && chmod 755 promxy
cat > config.yaml << EOF
promxy:
  server_groups:
    - static_configs:
        - targets:
          - 192.168.1.102:8428 # 如果涉及多个VM节点，继续下面追加即可
      path_prefix: /prometheus # 追加请求前缀
EOF
nohup ./promxy --bind-addr=:8082 --config=config.yaml &

访问地址：http://192.168.1.102:8082   展示的和Prometheus的Web UI基本一样，就不在详细阐述。

10

总结

本文介绍VictoriaMetrics，本着实用至上的原则，着重介绍VictoriaMetrics单节点版的安装&使用、基本原理，以及HA方案等，VictoriaMetrics是个不错的Prometheus 远程存储 或者 替代方案。VictoriaMetrics针对HDD盘、高延迟网盘做了优化，以及更低的资源使用率，更高的查询性能，都使它带来更高的成本优势。

再次推荐大家尝试VictoriaMetrics，如有建议可下方留言~

参考链接：

• https://docs.victoriametrics.com/Single-server-VictoriaMetrics.html

• https://docs.victoriametrics.com/Articles.html

• https://docs.victoriametrics.com/FAQ.html

• https://docs.victoriametrics.com/CaseStudies.html

• https://db-engines.com/en/ranking/time+series+dbms

• https://zhuanlan.zhihu.com/p/368912946

• https://www.robustperception.io/evaluating-performance-and-correctness