VictoriaMetrics入门与实战

2022-03-24 00:00:00 数据 节点 目录 替换 抓取

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数据源(经测试,线上数据源直接替换后兼容)
  • 低内存:更低的内存占用,官方对比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-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 &


3.2 Prometheus配置

# 在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 &



3.3 Grafana配置

# 在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
打开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/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`
在Grafana上,使用VM替换Prometheus源



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


3.5 VM单节点版-替换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正常展示


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=<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的0,

然后每组请求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/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基本一样,就不在详细阐述。


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
    om/Articles.html

相关文章