VictoriaMetrics | 钱帅的博客

type

status

date

slug

summary

VictoriaMetrics简介

VictoriaMetrics（简称 VM）是一款高性能、高可用、易扩展的时序数据库，常用于为 Prometheus 提供长期远程存储。它默认将监控数据存储在本地磁盘中，提供了一个本地全量持久化存储方案，无需依赖外部对象存储系统，能够高效处理大规模监控数据。相比于 Thanos，VictoriaMetrics 有以下几个明显优势： VM 不依赖对象存储，数据保存在本地磁盘中，减少了对外部存储系统（如 S3、GCS）的依赖，查询性能更稳定； VM 的写入和查询效率通常优于 Thanos，适用于高并发、高负载的监控环境； VM 提供了 vmagent 组件，可以从多个 Prometheus 实例或其他来源收集数据，实现采集和存储的解耦； VM 支持完全替代 Prometheus，架构更简单，部署维护成本低，资源占用也更少。

而 Thanos 更适合超大规模场景，支持对象存储、数据分层存储和跨地域联邦查询等功能，但也因此引入了更多组件，架构复杂，查询性能依赖远程存储，可能存在延迟。因此在资源敏感或中大型集群中，如果更关注性能与维护成本，可以选择使用 VictoriaMetrics 作为存储引擎，甚至直接替换 Prometheus 本身。

VM架构

VictoriaMetrics主要包含以下几个组件： VictoriaMetrics (VM) 提供单节点和集群多种部署方案。单节点方案非常简单，只需运行一个二进制文件即可。官方建议在采集数据点时100w/s使用低于单节点版本，因为其易于维护，但需要需要注意单节点版本不支持告警功能。而集群版本则支持数据的水平拆分，适用于更大规模的数据处理场景。VM主要包含以下几个组件： vmstorage：数据存储以及查询结果返回，默认端口为 8482 vminsert：数据录入，可实现类似分片、副本功能，默认端口 8480 vmselect：数据查询，汇总和数据去重，默认端口 8481 vmagent：数据指标抓取，支持多种后端存储，会占用本地磁盘缓存，默认端口 8429 vmalert：报警相关组件，不如果不需要告警功能可以不使用该组件，默认端口为 8880

大致流程：vmagent → vminsert → vmstorage ← vmselect ← grafana

VictoriaMetrics（简称 VM）提供了两种部署方式：单节点 和 集群方案，根据你监控系统的规模和复杂度来选择就可以了。

单节点版

在比较小的业务场景里，推荐直接使用单节点版本，部署起来非常简单，就一个二进制文件运行就行了，不需要其他外部依赖。官方建议，如果你系统每秒采集的数据点数（data points）低于 100 万/s，用单节点就够了，既省事又稳定。不过要注意的是，单节点不支持告警（vmalert），所以如果你希望用 VM 来接收规则并发送告警，这点就要特别考虑了。

单节点部署

使用 Prometheus 采集数据，然后将 Prometheus 数据远程写入 VM 远程存储。我这里已经部署好了 Prometheus operator，只需要部署一个单节点模式的 VM。可以直接下载对应的二进制文件启动，也可以使用 docker 镜像一键启动，我们这里部署到 Kubernetes 集群中，首先创建名称空间

资源清单文件如下所示：

查看部署的VictoriaMetrics

到这里我们单节点的 VictoriaMetrics 就部署成功了。这个时候Prometheus其实和VM是没任何关系的，我们需要去修改Prometheus的配置，让它将数据写入到VM中去，修改 Prometheus CRD

在spec下新增如下内容

这个时候其实数据已经在向VM写入了，因为我们部署了Grafana嘛，所以我们直接去换数据源就行

Prometheus远程写入到VM，我们去查看VM的持久化存储数据目录是否有数据产生

然后导入 16098 这个 Dashboard，导入后效果如下图所示

访问vm页面，此时可以看到已经有了数据

替代 Prometheus

上述我们将 Prometheus 数据远程写入到了 VM，但是 Prometheus 开启 remote write 功能后会增加其本身的资源占用。VM本身有收集数据的模块，所以我们可以替换掉Prometheus。首先去掉prometheus中的远程写入的那个配置

创建一个 VM ConfigMap 文件

创建 sa 账号，对 sa 做 rbac 授权

把 sa 账号 vm 通过 clusterrolebing 绑定到 clusterrole 上

VictoriaMetrics 使用 flock.lock 文件来确保同一个数据目录不会被多个实例同时使用。当有另一个进程（或容器）已经在使用该目录时，第二个实例尝试启动就会失败。所以我们需要先把运行的 victoria-metrics deploy 删除

将victoriametrics的配置文件挂载到VM的的容器中，使用参数-promscrape.config来指定victoriametrics的配置文件

现在我们再去 Grafana 查看 Dashboard 是否可以正常显示

访问 vm web ui 页面

集群版

对于低于每秒一百万个数据点的摄取率，建议使用单节点版本而不是集群版本。单节点版本可根据 CPU、内存和可用存储空间的数量进行扩展。单节点版本比集群版本更容易配置和操作，所以在使用集群版本之前要三思而后行。如果你希望系统具备更强的扩展能力和高可用性，那就需要使用集群版本。VM 的集群架构把不同的功能拆成了几个独立的组件： vminsert：负责接收写入的数据流，比如从 Prometheus 或 vmagent 发送过来的指标； vmselect：负责处理查询请求，比如 Grafana 发过来的图表数据请求； vmstorage：存储所有的时序数据，是集群中唯一一个有状态的组件。

除了这三大核心组件之外，如果你想用 VM 完全替代掉 Prometheus，还可以使用： vmagent：功能相当于 Prometheus 的数据采集器，支持 service discovery 和 relabeling，可以从各种目标抓取数据并远程写入 VM； vmalert：提供规则评估和告警功能，和 Prometheus 的 Alertmanager 配合逻辑相似。

vminsert 和 vmselect 都是无状态服务，所以横向扩展很方便，服务压力大了就多部署几个实例就行。而 vmstorage 是存储组件，有状态，扩展时就要考虑数据分片、持久化和节点平衡的问题。

多租户

VictoriaMetrics（VM）天生支持多租户，非常适合在共享监控集群中部署多个团队或业务线。每个租户的数据相互隔离，查询、写入都独立处理。每个租户在 VM 中由以下两种方式标识：accountID 和 accountID:projectID ，两者都是 32 位整数，取值范围为 [0, 2^32]，如果没有指定 projectID，则默认使用 0。示例 URL：

虽然租户是在首次写入数据时自动创建的，但其元信息（如认证、配额、计费等）不会直接存储在 VM 集群中，而是交由上层代理管理，上层服务会根据 URL 中的租户 ID 识别身份，进而转发请求。 vmauth：简单的认证代理，支持 basic auth、token 等 vmgateway：企业级认证入口，支持 RBAC、LDAP 等

所有租户的数据会被均匀分布在 vmstorage 节点之间。数据分布与租户无关，即使某个租户写入量远大，也不会影响其它租户的数据隔离性。VM 的性能瓶颈不是租户数量，而是系统中活跃时间序列的总量。注意：不支持跨租户查询！也就是说，单次查询只能属于一个租户（一个 accountID），不能一次查多个。

集群版部署

如果你打算用 VictoriaMetrics 集群版，那么最起码需要搭建一个最小可运行集群。这个最小集群至少要包含三个组件，各自跑一个节点就行： vmstorage：负责存储时序数据，运行时要带上两个关键参数：-retentionPeriod：数据保留时长，比如 1y 表示保留 1 年；-storageDataPath：指定数据存储路径 vminsert：负责接收写入的数据，比如从 vmagent 或 Prometheus 推来的数据，运行时要告诉它数据存到哪里，用参数：-storageNode=<vmstorage 的地址>vmselect：处理查询请求，比如 Grafana 想展示一个图表，就会通过 vmselect 去查 vmstorage，运行时同样要加上：-storageNode=<vmstorage 的地址>

在部署集群版之前，我们需要先部署动态持久化存储，这里使用的是OpenEBS，所有节点安装iSCSI启动器

安装OpenEBS

查看安装状态

查看生成的StorageClass 对象

我们这里采取手动部署，由于 vmstorage 组件是有状态的，这里我们先使用 StatefulSet 进行部署，由于该组件也是可以进行扩展的，这里我们首先部署两个副本

创建一个 Headless 的 Service，因为后面的组件需要访问到每一个具体的 Pod，在 vmstorage 启动参数中通过 --retentionPeriod 参数指定指标数据保留时长，1 表示一个月，这也是默认的时长，然后通过 --storageDataPath 参数指定了数据存储路径，记得要将该目录进行持久化。查看部署状态

接着可以部署 vmselect 组件，由于该组件是无状态的，我们可以直接使用 Deployment 来进行管理，对应的资源清单文件如下所示：

其中最重要的部分是通过 --storageNode 参数指定所有的 vmstorage 节点地址，上面我们使用的 StatefulSet 部署的，所以可以直接使用 FQDN 的形式进行访问。查看部署结果：

接着就需要部署用来接收指标数据插入的 vminsert 组件，同样该组件是无状态的，其中最重要的也是需要通过 --storageNode 参数指定所有的 vmstorage 节点：

由于本身是无状态的，所以可以根据需要增加副本数量，也可以配置 HPA 进行自动扩缩容

到这里我们集群版的 VictoriaMetrics 就部署成功了。这个时候Prometheus其实和VM是没任何关系的，我们需要去修改Prometheus的配置，让它将数据写入到VM中去，修改 Prometheus CRD

在spec下新增如下内容

这个时候其实数据已经在向VM写入了，因为我们部署了Grafana嘛，所以我们直接去换数据源就行。如果要进行查询，那么我们可以直接对外暴露 vmselect 这个 Service 服务即可，修改 Grafana 数据源地址为 http://vmselect.monitoring-vm:8481/select/0/prometheus。然后导入 16098 这个 Dashboard，导入后效果如下图所示

vm-operator

Operator 我们知道是 Kubernetes 的一大杀器，可以大大简化应用的安装、配置和管理，同样对于 VictoriaMetrics 官方也开发了一个对应的 Operator 来进行管理 vm-operator，它的设计和实现灵感来自 prometheus-operator，它是管理应用程序监控配置的绝佳工具。vm-operator 定义了如下一些 CRD： VMServiceScrape：定义从 Service 支持的 Pod 中抓取指标配置 VMPodScrape：定义从 Pod 中抓取指标配置 VMRule：定义报警和记录规则 VMProbe：使用 blackbox exporter 为目标定义探测配置

此外该 Operator 默认还可以识别 prometheus-operator 中的 ServiceMonitor、PodMonitor、PrometheusRule 和 Probe 对象，还允许你使用 CRD 对象来管理 Kubernetes 集群内的 VM 应用。vm-operator 提供了 Helm Charts 包，所以可以使用 Helm 来进行一键安装

将chart包下载解压到本地

根据自己的需要定制 values.yaml 文件，部分修改参考

安装 vm-operator

查看 vmoperator 是否安装成功

Operator 安装完成后会包含如下所示的一些 CRD

安装 VM 集群

比如现在我们要来部署 VM，如果只是想要单节点模式则可以直接使用 VMSingle 对象，如果要部署一套 VM 的集群则可以直接使用 VMCluster 来定义一个对象即可，完全不需要我们去手动创建各个组件，Operator 会根据我们的定义去帮我们拉起一套集群起来。比如这里我们定义一个如下所示的 VMCluster 对象：

整个对象可配置的属性我们可以通过 kubectl explain 来获取

同样要想获取组件可以定义的属性也可以通过该方式来获取，比如查看 vmstorage 对象可以配置的属性

创建后 vm-operator 会 watch 到我们创建了该 CRD 对象，然后会根据我们的定义去自动创建对应的 VM 集群

安装VMAgent

通过定义简单的 VMCluster 对象就可以来管理 VM 集群了，VM 集群虽然安装成功了，但是现在还没有任何数据，所以还需要去配置监控指标的抓取，这里我们可以直接去创建一个 VMAgent 对象即可，下面我们来自定义资源（CR）用于部署 VictoriaMetrics Agent（VMAgent），同样要获取 VMAgent 的所以可配置的属性可以通过 kubectl explain VMAgent.spec 来获取

远程写入这个地址指向的是：service服务名.命名空间.svc.cluster.local:端口/插入路径。0代表的是租户的id，0表示没有租户。创建后 vm-operator 会根据对应的描述创建对应的 vmagent 实例：

可以看到 vmagent 有两个容器，一个是 vmagent 应用容器，另外一个是用于挂载 Secret 对象的 config-reloader 容器，它会 watch 配置的变化，并发送信号为 vmagent 重新加载配置，该 Secret 对象中就是定义的 vmagent 抓取指标的配置内容。然后将 vmagent service 类型改为 NodePort

vmagent 会通过 Kubernetes 服务发现去获取需要抓取的目标，此服务发现由 vm operator 控制。在浏览器中访问 <ip>:31042/targets 来检查 vmagent 采集的集群指标

VMNodeScrape

默认情况下，VMAgent 会自动采集一些基础指标，比如 VM 自家的一些组件（像 vmagent 自己的运行状态），但这远远不够。很多时候我们还想采集比如 node-exporter 的主机监控指标，这可是监控系统里最基础的部分了。这时候就要用到 VMNodeScrape 这个对象了。你可以把 VMNodeScrape 看作是专门用于采集 Node 上的指标的一个配置入口。它的作用类似于 Prometheus 的 kubernetes_sd_configs + role: node 配置组合。

只要你定义了一个 VMNodeScrape 对象，VMAgent 就会自动去发现集群中的每个 Node 节点，并根据你提供的端口、路径等信息，去采集指标，比如从 http://<nodeIP>:9100/metrics 去抓取 node-exporter 的数据。比如你在每台 Node 上都部署了 node-exporter（默认监听在 9100 端口），你可以创建一个像这样的配置：

创建后，VMAgent 会自动发现每个 Node，并尝试从它们的 9100 端口上拉取指标。

使用 kubectl patch 命令将 VMAgent 的服务从 ClusterIP 类型改为 NodePort

VMServiceScrape

在使用 VictoriaMetrics Operator（vm-operator）时，不只是节点抓取可以自动化管理，Pod、Service、报警规则等维度的监控采集和管理也都能借助 CRD 来实现，简洁又强大。下面我们来通过 VMServiceScrape 去定义要抓取的 Service 服务（Endpoints），这里以监控coredns为例

查看创建好的 servicemonitor 和 vmservicescrapes

VMPodScrape

有些组件没暴露 Service，或者是 DaemonSet/Job 这类不方便暴露 Service 的 Pod，这时我们可以用 VMPodScrape 来直接定义抓取方式，适合 Job、DaemonSet 等无 Service 场景，补齐 Prometheus ServiceMonitor 不方便覆盖的边角。

查看创建的VMPodScrape

此时查看 web ui 页面，已经显示了该目标