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

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

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

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

• 远程存储：可作为单一或多个Prometheus的远程存储
• 安装简单：单节点架构一条命令就可以部署完毕（集群方式稍微复杂一些，但也很好理解）
• 兼容性：PromQL兼容和增强的MetricsQL
• Grafana兼容：VM可替换Grafana的Prometheus数据源（经测试，线上数据源直接替换后兼容）
• 低内存：更低的内存占用，官方对比Prometheus，可以释放7倍左右内存空间（线上对比大概4倍）
• 高压缩比：提供存储数据高压缩，官方说可以比Prometheus减少7倍的存储空间（线上对比大概是4~5倍）
• 高性能：查询性能比Prometheus更快
• 支持水平扩容&HA：基于VM集群版实现
• 支持多租户：主要针对集群版

• 图形化做的不好，虽然有vmui，但功能很少
• 告警功能需要单独配置vmalert，而且vmalert只有api管理和查看，暂时没用图形界面
• 没有类似Prometheus的WAL日志，突然故障可能会丢失部分数据
  
  

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

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

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

• 官网：https://victoriametrics.com

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

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

  
  

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

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

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

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

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

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

综上，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/）。

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

说明：

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

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

# 在192.168.1.102主机安装Prometheuscd /usr/localwget https://github.com/prometheus/prometheus/releases/download/v2.30.0/prometheus-2.30.0.linux-amd64.tar.gztar -xvzf prometheus-2.30.0.linux-amd64.tar.gz && mv prometheus-2.30.0.linux-amd64 prometheus && cd prometheus
cat > prometheus.yml << EOFglobal:  scrape_interval:     15sscrape_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}'EOFnohup ./prometheus --config.file="prometheus.yml" --storage.tsdb.retention=30d --web.enable-lifecycle &

# 在192.168.1.102主机安装Grafanacd /usr/localwget https://dl.grafana.com/oss/release/grafana-8.1.3.linux-amd64.tar.gztar -zxvf grafana-8.1.3.linux-amd64.tar.gz && mv grafana-8.1.3 grafana && cd grafananohup ./bin/grafana-server -config=./conf/defaults.ini &
# 注：Grafana默认账号密码都为admin

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

# 在192.168.1.102上，安装VM单节点版，作为Prometheus的远程存储（因为只是测试，所以安装在同一台机子上了）cd /usr/localwget https://github.com/VictoriaMetrics/VictoriaMetrics/releases/download/v1.65.0/victoria-metrics-amd64-v1.65.0.tar.gzmkdir victoria-metrics && tar -xvzf victoria-metrics-amd64-v1.65.0.tar.gz && \mv victoria-metrics-prod victoria-metrics/victoria-metrics && cd victoria-metricsnohup ./victoria-metrics -retentionPeriod=30d -storageDataPath=data &
# 配置Prometheus远程存储cat >> /usr/local/prometheus/prometheus.yml << EOFglobal:  scrape_interval:     15sscrape_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
# 重启Prometheuskill -HUP `pidof prometheus`

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

# 直接把Prometheus配置文件复制当VM目录，并关闭Prometheuscp /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正常展示。

/api/v1/query

/api/v1/query_range

/api/v1/series

/api/v1/labels

/api/v1/label/…/values

/api/v1/status/tsdb

/api/v1/targets

• 查询细化：/api/v1/query_range?extra_label=user_id=123&query=<query> 
• 相对时间：/api/v1/query_range?start=-30m&query=...
• 小数取舍：/api/v1/query?query=avg_over_time(temperature[1h])&round_digits=2

/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(总查询时间)

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

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

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

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

数据目录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进制。

索引目录，与数据目录不同的是，索引目录是由多个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集群版本，去重的逻辑都相同。

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查看等。

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

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

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

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

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

本文介绍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
  om/Articles.html