VictoriaMetrics

帅大大的架构之路

已于 2023-05-25 11:35:00 修改

阅读量2k

点赞数

分类专栏：数据库文章标签： java 数据库大数据

于 2023-05-25 11:32:15 首次发布

原文链接：https://blog.csdn.net/qihoo_tech/article/details/120558834

版权

数据库专栏收录该内容

29 篇文章 0 订阅

订阅专栏

原文

简介

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集群版实现
支持多租户：主要针对集群版
它针对具有高延迟 IO 和低 IOPS 的存储进行了优化
提供全局的查询视图，多个 Prometheus 实例或任何其他数据源可能会将数据摄取到 VictoriaMetrics
VictoriaMetrics 由一个没有外部依赖的小型可执行文件组成
所有的配置都是通过明确的命令行标志和合理的默认值完成的
所有数据都存储在 - storageDataPath 命令行参数指向的目录中
可以使用 vmbackup/vmrestore 工具轻松快速地从实时快照备份到 S3 或 GCS 对象存储中
由于存储架构，它可以保护存储在非正常关机（即 OOM、硬件重置或 kill -9）时免受数据损坏
同样支持指标的 relabel 操作

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

架构

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

下图是 VictoriaMetrics 集群版官方的架构图。

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

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

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

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

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

主要包含以下几个组件：

vmstorage：数据存储以及查询结果返回，默认端口为 8482
vminsert：数据录入，可实现类似分片、副本功能，默认端口 8480（可以将数据分片插入到多个storage实例当中去，具体怎么插入是有一套算法，将数据哈希到某个节点上面去）（vminsert也是无状态的，所以暴露的时候可以使用LB的形式，Prometheus可以通过远程写的方式写入到LB，LB后面对应的是vminsert，vminsert就可以将数据存储到vmstorage里面去）(Prometheus通过remote write远程写的接口将数据写入vminsert)
vmselect：数据查询，汇总和数据去重，默认端口 8481，如果有压力可以横向扩展
vmagent：数据指标抓取，支持多种后端存储，会占用本地磁盘缓存，默认端口 8429
vmalert：报警相关组件，不如果不需要告警功能可以不使用该组件，默认端口为 8880

集群方案把功能拆分为 vmstorage、 vminsert、vmselect 组件，如果要替换 Prometheus，还需要使用 vmagent、vmalert（如果完全不想使用Prometheus，那么可以使用vmagent）。从上图也可以看出 vminsert 以及 vmselect（几乎）都是无状态的，所以扩展很简单，只有 vmstorage 是有状态的。

1.5 部分名词解释

1）关于样本：

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

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

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

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

2）关于target：

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

案例

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

使用方	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/）。

VM单节点版

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

各服务部署如下表：

服务名称	IP	PORT
node-exporter	192.168.1.100192.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正常展示。

兼容性

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

性能对比

5.1 环境简介

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

5.2 查询逻辑

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

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

测试结果：

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

存储目录简介

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进行多维检索。

关于去重

这里单独把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集群版本，去重的逻辑都相同。

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集群版来替换此方案。

图形界面

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基本一样，就不在详细阐述。

总结

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

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

参考链接：