VictoriaMetrics 1.146.0 源码专题【左扬精讲】—— 开源生态：VM 在 CNCF 生态中的位置

当我们在 Kubernetes 集群中部署监控系统时，整个可观测性生态就像一座运转精密的工厂：Prometheus 负责采集数据，Grafana 负责可视化，VictoriaMetrics 负责存储，CNI 插件负责网络——每个组件各司其职，共同支撑起云原生监控的大厦。

读完本篇，你应该能回答：VictoriaMetrics 在 CNCF 生态中扮演什么角色？它与 Prometheus、Grafana、k8s 等核心项目如何协作？整个 VM 工具链家族各自承担什么职责？

VictoriaMetrics CNCF Prometheus Grafana Kubernetes OpenTelemetry Prometheus Operator vmagent Helm 可观测性

学习重点

必须掌握：CNCF 可观测性全景图、VM 工具链矩阵、Prometheus 协议兼容性

需要理解：各集成方案的适用场景、Helm Chart 架构、Prometheus Operator CRD

一、从 CNCF 全景图看 VM 的生态位

思考记忆提示 — 理解 CNCF 生态中各项目的定位关系

关联前面章节：#10 中四大 TSDB 在生态中的位置
关联工具链：vmagent / vmalert / vmauth / vmbackup 各司其职
面试/考试高频提问：VictoriaMetrics 和 Prometheus 是什么关系？它属于 CNCF 哪个层次？

CNCF（Cloud Native Computing Foundation，云原生计算基金会）是 Linux Foundation 旗下的非营利组织，负责维护和推广云原生领域的开源软件。截至 2026 年，CNCF 托管了超过 170 个项目，涵盖容器编排、服务网格、可观测性、存储、网络等各个领域。

VictoriaMetrics 以 Sandbox（沙箱）级别加入 CNCF（具体加入时间请参考 CNCF 官方公告，建议访问 CNCF 官方公告页面核实）。在 CNCF 的项目成熟度体系中，Sandbox 是第一级，之上还有 Incubating（孵化）和 Graduated（毕业）两级。

我理解源码的意思是说

CNCF 可观测性生态不是抽象概念，可以直接从项目之间的协议和代码接口看出来。我们不看类比，直接看三个项目的集成方式：

源码视角一：Prometheus 和 Grafana 的协议契约

读 app/vmalert/datasource/client_prom.go 第 42-62 行，会发现 Prometheus 定义了标准的查询响应格式：metric 对象包含 Labels、Timestamps、Values。VictoriaMetrics 完全兼容这个格式，所以 Grafana 的 Prometheus 数据源类型可以直接查询 VM。

源码视角二：VictoriaMetrics 的生态位

VictoriaMetrics 不替代 Prometheus 的采集能力，而是通过 /api/v1/write（Remote Write）接收数据，通过 /api/v1/query（PromQL）提供查询。这种设计让 VM 成为 Prometheus 生态的"存储增强器"，而不是竞争对手。

源码视角三：Grafana 的数据源抽象

Grafana 的 Prometheus 数据源配置只需要一个 HTTP URL（见第 743-752 行 JSON 配置）。VictoriaMetrics 实现了完整的 Prometheus HTTP API，所以 Grafana 根本无法区分后端是 Prometheus 还是 VM。这是 VM 生态兼容性的核心机制。

源码视角总结：3 个协议契约

1 个写入契约：Prometheus Remote Write → /api/v1/write
1 个查询契约：PromQL → /api/v1/query
1 个展示契约：Grafana Prometheus 数据源 → 直接兼容

避坑提醒（源码视角）：

不要把 VM 当成 Prometheus 的替代品：VM 是存储后端，Prometheus 是采集层，两者互补
不要以为 Grafana 需要特殊插件：VM 完整实现 Prometheus API，无需额外插件

1.1 CNCF 可观测性三要素与 VM 的对应关系

CNCF 可观测性体系围绕三大支柱构建：Metrics（指标）、Logs（日志）、Traces（链路）。VictoriaMetrics 的定位非常清晰——专注于 Metrics（指标）存储，同时通过 VictoriaLogs 向日志领域延伸。

CNCF 可观测性生态全景
│
├── 【Metrics 指标】— VictoriaMetrics 主战场
│   ├── Prometheus（毕业）— 采集层 + 查询语言
│   ├── VictoriaMetrics（沙箱）— 存储层 / Prometheus 后端
│   ├── Thanos（孵化）— Prometheus 扩展 / 长期存储
│   └── Grafana（毕业）— 可视化层
│
├── 【Logs 日志】— VictoriaMetrics 扩展方向
│   ├── Loki（毕业）— Grafana 主导的日志系统
│   └── VictoriaLogs（沙箱）— VM 家的日志产品
│
└── 【Traces 链路】— VM 间接支持
    ├── Jaeger（毕业）
    ├── Zipkin（毕业）
    └── OpenTelemetry（毕业）— 统一采集标准

设计精髓

VictoriaMetrics 在 CNCF 生态中的战略定位非常务实：不做全能选手，而是在 Metrics 领域做到极致。它通过兼容 Prometheus 协议，以"替换存储层"的姿态切入生态，最大化复用已有工具（Grafana、Alertmanager），降低用户迁移成本。这是典型的"农村包围城市"策略。

必记闭环逻辑（核心考点）

VictoriaMetrics 以"Prometheus 兼容存储后端"的姿态加入 CNCF 沙箱，不替代 Prometheus，而是扩展其存储和查询能力。VM 的生态位是Metrics 存储层的性能增强器——复用 Prometheus 的采集生态，Grafana 的展示生态，自己专注于"存得更多、查得更快、耗得更少"。

二、Prometheus 生态：VM 的核心集成

思考记忆提示 — Prometheus 是 VM 的入口，VM 是 Prometheus 的扩展

关联前面章节：#02 全局架构中 Single-Node / Cluster 模式
关联工具链：vmagent 作为 Prometheus-side 抓取代理
面试/考试高频提问：VM 和 Prometheus 是什么关系？数据怎么从 Prometheus 流入 VM？

2.1 协议层面的完整兼容

VictoriaMetrics 对 Prometheus 生态的集成，首先体现在协议层面的完整兼容。Prometheus 定义了三个核心协议，VM 全部支持：

Remote Write（写入）：Prometheus 将采集的指标数据通过 Remote Write 协议推送到远端存储。VM 完全兼容此协议，Prometheus 配置一个 remote_write 指向 VM 即可。
PromQL（查询）：VictoriaMetrics 不仅兼容 PromQL，还扩展出了 MetricsQL。这意味着所有 Grafana Dashboard 无需修改，直接查询 VM 的数据。
Prometheus API（/api/v1/*）：VM 实现了 Prometheus 的全部 HTTP API 端点，Grafana Explore 面板无需任何适配即可使用。

小贴士

Remote Write 是 Prometheus 最核心的数据导出机制。相比于 Prometheus 的 Federation 联邦模式（查询时拉取数据），Remote Write 是推送模式——Prometheus 本地只做采集，数据实时推送到 VM，好处是不占用 Prometheus 本地存储空间。

2.2 数据流向全解析

Prometheus → VictoriaMetrics 数据流（Remote Write 模式）
════════════════════════════════════════════════════════

  ┌──────────────┐
  │  Prometheus  │  ← 采集 k8s / 虚机 / 应用 metrics
  │  (抓取代理)   │
  └──────┬───────┘
         │  remote_write
         │  HTTP POST /api/v1/write
         ▼
  ┌──────────────┐
  │ VictoriaMetrics│  ← Single-Node 或 Cluster
  │   (存储层)    │     vminsert → vmstorage
  └──────┬───────┘
         │  PromQL / /api/v1/*
         ▼
  ┌──────────────┐
  │   Grafana    │  ← 可视化 Dashboard
  │  (展示层)    │
  └──────────────┘

这条数据流的特点是零迁移成本：已有的 Prometheus 配置文件、Grafana Dashboard、Alertmanager 告警规则全部可以复用。唯一的改动是增加一行 remote_write 配置。

2.3 vmagent：轻量级 Prometheus-side 采集代理

除了接收 Prometheus 推送的数据，VictoriaMetrics 还提供了自己的采集代理 vmagent。vmagent 可以完全替代 Prometheus 的抓取功能，并且支持将数据同时发送给多个目的地：

推送到 VictoriaMetrics（原生）
推送到 Prometheus（兼容 Remote Write）
推送到其他支持 Remote Write 的存储（如 Thanos）

我理解源码的意思是说

vmagent 和 Prometheus 的设计差异，可以直接从源码的入口函数和命令行参数看出来。我们不看类比，直接看关键代码：

源码视角一：Prometheus 的采集+存储一体设计

Prometheus 的 app/scrape/scrape.go 实现了拉取（scrape）和存储（storage）的一体化：Prometheus 同时负责抓取指标和写入本地 TSDB。这导致 Prometheus 实例既是采集代理又是存储后端，内存占用由两者共同决定。

源码视角二：vmagent 的采集+转发分离设计

vmagent（app/vmagent/main.go）的职责单一：只抓取指标，通过 Remote Write 协议转发到远端存储。vmagent 本身不存储数据，因此内存占用远小于 Prometheus。这种设计让它可以部署在资源受限的环境中。

源码视角三：多目的地转发的实现

vmagent 支持同时向多个远端存储发送数据——这个能力通过 remote_write 配置数组实现，每个配置项对应一个独立的目标端点。源码在 app/vmagent/remotewrite/remotewrite.go 中处理并发写入。

源码视角总结：2 个设计原则

1 个架构原则：vmagent 采集转发分离，Prometheus 采集存储一体
1 个扩展原则：vmagent 通过配置数组支持多目的地

避坑提醒（源码视角）：

不要以为 vmagent 可以替代 Prometheus 的所有功能：vmagent 只负责采集，不负责存储和查询
不要混淆 vmagent 和 vmstorage：vmagent 是采集代理，vmstorage 是存储后端

必记闭环逻辑（核心考点）

VictoriaMetrics 与 Prometheus 的集成以"Remote Write 协议"为桥梁，实现了数据流向的解耦：Prometheus/vmagent 负责采集，VM 负责存储和查询，Grafana 负责展示。三者各司其职，组成一个零迁移成本的可观测性栈。

三、Kubernetes 生态：Operator 与 Helm 部署

思考记忆提示 — k8s 是 VM 最主流的部署环境

关联前面章节：#02 Single-Node / Cluster 部署架构
关联工具链：vmagent / vmalert 在 k8s 中的配置方式
面试/考试高频提问：如何在 k8s 中高可用部署 VictoriaMetrics？

3.1 VictoriaMetrics Operator

VictoriaMetrics Operator（vmoperator）是 VM 官方维护的 Kubernetes Operator，用于以声明式方式管理 VM 集群的所有组件。它本质上是 Prometheus Operator 的"维多利亚版本"，遵循相同的 CRD 设计理念：

VMOperator：管理 VM 集群生命周期
VMSingle：声明式管理 Single-Node 部署
VMCluster：声明式管理 Cluster 模式部署
VMAgent：声明式管理 vmagent 部署
VMAlert：声明式管理 vmalert 部署
VMAuth：声明式管理 vmauth 部署

小贴士

如果你已经在使用 Prometheus Operator，想迁移到 VM，不需要删除现有的 Prometheus Operator。可以在同一集群中并行部署 VictoriaMetrics Operator，逐步将数据流切换到 VM，实现平滑过渡。

3.2 Helm Chart 部署

对于不需要 Operator 复杂度的场景，官方 Helm Chart 提供了最简洁的部署方式：

# 添加 Helm 仓库
helm repo add vm https://victoriametrics.github.io/helm-charts/
helm repo update

# 部署 Single-Node
helm install vm vm/victoria-metrics-single \
  --namespace monitoring \
  --create-namespace

# 部署 Cluster 模式
helm install vm vm/victoria-metrics-cluster \
  --namespace monitoring \
  --set insert.capacity=3 \
  --set storage.capacity=50Gi

Helm Chart 的优势是配置灵活：通过 values.yaml 可以控制副本数、资源限制、持久化存储、服务类型等所有参数。

3.3 高可用部署架构

在生产环境中，VictoriaMetrics 推荐以下 k8s 高可用部署架构：

k8s 高可用部署架构
══════════════════════════════════════════════════════
┌─────────────────────────────────────────────────┐
│              monitoring namespace                 │
│                                                  │
│  ┌──────────┐   remote_write    ┌───────────┐  │
│  │ Prometheus│ ──────────────────▶│ VMCluster │  │
│  │ Operator  │                   │           │  │
│  └──────────┘                    │ ┌───────┐ │  │
│                                   │ │vminsert│ │  │
│  ┌──────────┐                    │ └───┬───┘ │  │
│  │  vmagent │ ──────────────────▶│ ┌───┴───┐ │  │
│  └──────────┘                    │ │vmstorage│ │  │
│                                   │ └───┬───┘ │  │
│  ┌──────────┐                    │ ┌───┴───┐ │  │
│  │  vmalert │ ◀─── alerts ──────│ │vmstorage│ │  │
│  └──────────┘                    │ └───┬───┘ │  │
│                                   │ ┌───┴───┐ │  │
│  ┌──────────┐                    │ │vmselect│ │  │
│  │  vmauth  │ ◀─── queries ─────│ └───────┘ │  │
│  └──────────┘                    └───────────┘  │
│                                                  │
│  ┌──────────┐   ┌──────────┐   ┌──────────┐    │
│  │  Grafana │   │Alertmanager│  │  其他    │    │
│  │(Dashboard)│   │ (通知)   │   │ 数据源   │    │
│  └──────────┘   └──────────┘   └──────────┘    │
└─────────────────────────────────────────────────┘

注意

Cluster 模式下，vminsert、vmstorage、vmselect 三个组件各自独立部署。vmstorage 之间通过一致性哈希分片存储数据，任意一个 vmstorage 节点故障只会影响部分数据，不会导致全量不可用。建议 vmstorage 至少部署 2 个副本以保证高可用。

必记闭环逻辑（核心考点）

k8s 是 VictoriaMetrics 最重要的部署环境。VictoriaMetrics Operator 通过 CRD 实现了声明式管理，Helm Chart 提供了快速部署能力。高可用部署推荐使用 Cluster 模式：vminsert 接收写入、vmstorage 分片存储、vmselect 处理查询，三者通过 Kubernetes Service 进行内部通信。

四、Grafana 生态：无缝集成

思考记忆提示 — Grafana 是 VM 数据的主要展示渠道

关联前面章节：#02 中 vmui 内置 UI 与 Grafana 的关系
关联工具链：vmui 作为轻量级替代 Grafana 的选择
面试/考试高频提问：Grafana 如何连接 VictoriaMetrics？

Grafana 是 CNCF 毕业的可视化项目，也是 VictoriaMetrics 最重要的展示层集成。

4.1 数据源配置

在 Grafana 中添加 VictoriaMetrics 数据源非常简单，只需配置 HTTP URL：

{
  "name": "VictoriaMetrics",
  "type": "prometheus",
  "url": "http://victorial-metrics-cluster.monitoring.svc:8428",
  "access": "proxy",
  "jsonData": {
    "timeInterval": "15s"
  }
}

关键点：Grafana 的 Prometheus 数据源类型完全兼容 VictoriaMetrics，不需要安装额外的 Grafana 插件。这是因为 VictoriaMetrics 实现了 Prometheus HTTP API 的全部端点。

4.2 vmui 内置 UI

VictoriaMetrics 自带了内置的 Web UI（vmui），位于 /vmui 路径。vmui 提供以下核心功能：

Graph 面板：类似 Grafana 的简单可视化
PromQL 查询：在线输入 PromQL 并查看结果
Series 探索：浏览当前存储的 metric 列表
VictoriaLogs 入口：从指标直接跳转查看关联日志

小贴士

vmui 是轻量级工具，适合快速调试和排查问题。生产环境仍然推荐使用 Grafana，因为 Grafana 拥有更丰富的图表类型、Dashboard 模板和告警功能。vmui 和 Grafana 可以并行使用，互不冲突。

必记闭环逻辑（核心考点）

Grafana 对 VictoriaMetrics 的支持是开箱即用的：选择 Prometheus 数据源类型，填入 VM 的 HTTP URL 即可。这是因为 VM 完整实现了 Prometheus API 的所有端点，Grafana 根本无法区分它是在查询 Prometheus 还是 VictoriaMetrics。

五、OpenTelemetry 生态：现代采集标准

思考记忆提示 — OTel 是未来采集方向，VM 已全面支持

关联前面章节：#04 数据流生命周期中协议接入层
关联工具链：vmagent 支持 OTLP 协议接入
面试/考试高频提问：VictoriaMetrics 如何接收 OpenTelemetry 数据？

OpenTelemetry（OTel）是 CNCF 毕业项目，旨在统一 Metrics、Logs、Traces 的采集标准。VictoriaMetrics 通过以下两种方式接入 OTel 生态：

5.1 vmagent 接收 OTLP

vmagent 支持接收 OpenTelemetry Pipeline（OTLP）协议的数据：

# vmagent 配置：监听 OTLP gRPC 端口
# 端口 4317 = OTel Collector gRPC
# 端口 4318 = OTel Collector HTTP
remote_write:
  - url: http://victoria-metrics:8428/api/v1/write
    remote_timeout: 30s

# OTLP 接收配置
otlp_config:
  listen_addr: ":4317"   # gRPC
  # http_listen_addr: ":4318"  # HTTP

这意味着应用程序通过 OTel SDK 采集的 metrics 数据，可以直接通过 OTel Collector → vmagent → VictoriaMetrics 的路径存储。

5.2 OpenTelemetry 与 Prometheus 的融合

OTel 的一个核心设计理念是"指标先行"（Metrics First）。VictoriaMetrics 的 OTLP 接收能力，让它可以同时服务于传统 Prometheus 采集（Prometheus 推送或拉取）和现代 OTel 采集两种模式：

遗留系统：继续使用 Prometheus_exporter + vmagent/Prometheus remote_write
新系统：使用 OTel SDK + OTel Collector + vmagent (OTLP)
统一存储：所有数据都流入 VictoriaMetrics

我理解源码的意思是说

OTel 和 Prometheus 的关系，可以直接从 VictoriaMetrics 的协议接入层代码看出来。我们不看类比，直接看源码中的两种接收方式：

源码视角一：Prometheus Remote Write 接收

VictoriaMetrics 在 Single-Node 和 Cluster 模式下都实现了 /api/v1/write 端点，接收 Prometheus Remote Write 协议的数据。这个端点定义在 lib/prompb/write_request_unmarshaler.go 中，通过 protobuf 解析 WriteRequest。

源码视角二：OTLP 接收

vmagent 支持监听 OTLP 端口（gRPC: 4317 / HTTP: 4318），将 OTLP 格式的 metrics 转换为 VM 内部格式后转发。这种设计让 VM 同时服务于两套采集生态，而不需要用户迁移现有系统。

源码视角三：两种协议在存储层是等价的

无论数据是通过 Prometheus Remote Write 还是 OTLP 进入 VictoriaMetrics，最终都存储在 MergeSet 中。存储层对上层协议完全透明，这是 VM 兼容策略的技术基础。

源码视角总结：2 个集成方式

1 个传统路径：Prometheus remote_write → /api/v1/write
1 个现代路径：OTLP → vmagent → /api/v1/write

避坑提醒（源码视角）：

不要以为 VM 强制用户选择一种采集协议：两种协议可以同时使用
不要混淆 OTLP 和 Remote Write：OTLP 是 CNCF OTel 标准，Remote Write 是 Prometheus 私有协议

必记闭环逻辑（核心考点）

VictoriaMetrics 通过 vmagent 的 OTLP 接收能力，无缝接入 OpenTelemetry 生态。这让 VM 同时支持传统 Prometheus 采集（Remote Write）和现代 OTel 采集（OTLP）两种模式，用户可以根据系统现状灵活选择，无需强制迁移。

六、VictoriaMetrics 工具链全家福

思考记忆提示 — VM 不只是一个数据库，是一个完整的可观测性平台

关联前面章节：#02 全局架构中 app/ 目录下的三大进程
关联工具链：每个工具对应一个特定场景
面试/考试高频提问：vmalert 和 Alertmanager 有什么关系？

VictoriaMetrics 工具链包含多个独立二进制，各自解决监控系统的不同环节：

工具	职责	对应 Prometheus 生态	源码位置
vmagent	轻量级指标采集代理	Prometheus（抓取部分）	app/vmagent/
vmalert	告警和录制规则执行	Prometheus Alertmanager	app/vmalert/
vmauth	认证和负载均衡代理	nginx / Ambassador	app/vmauth/
vmbackup	快照备份到云存储	Thanos Store-Gateway	app/vmbackup/
vmrestore	从备份恢复数据	Thanos Sidecar	app/vmrestore/
vmctl	多源数据迁移工具	无直接对应	app/vmctl/
vmgateway	API 网关（认证/限流）	kong / Auth0	app/vmgateway/
vmui	内置 Web 可视化 UI	Grafana（轻量替代）	app/vmui/

6.1 vmalert vs Alertmanager

这里需要澄清一个常见混淆：vmalert 和 Alertmanager 是两个不同的东西，功能上互补但不重叠：

Alertmanager（Prometheus 生态）：负责告警通知——分组、抑制、静默、发送邮件/Slack/Webhook。
vmalert（VictoriaMetrics 生态）：负责告警评估——执行 PromQL 查询判断是否触发告警，然后将触发的告警发送给 Alertmanager。

关系是：vmalert 执行告警规则 → 触发告警 → 发送给 Alertmanager → Alertmanager 通知。

设计精髓

VictoriaMetrics 工具链的设计哲学是"专注分工、REST 协作"：每个工具都是独立进程，通过标准 HTTP API 通信。这与 Prometheus Operator 的设计理念一致——用 Kubernetes 的声明式管理来组合分散的组件，形成一个有机的整体。

6.2 数据迁移：vmctl 的多源支持

vmctl 是 VictoriaMetrics 提供的数据迁移工具，支持从以下系统迁移数据到 VM：

Prometheus：读取 TSDB 快照格式
Thanos：读取 Prometheus TSDB Block 格式
InfluxDB：InfluxQL 查询结果迁移
OpenTSDB：OpenTSDB 格式数据
DataDog：DataDog API 数据导出

# 从 Prometheus 迁移到 VictoriaMetrics
vmctl prometheus \
  --prometheus snapshots-dir=/path/to/snapshots \
  --vm-addr=http://localhost:8428 \
  --prom-concurrency=5

必记闭环逻辑（核心考点）

VictoriaMetrics 工具链围绕"采集→存储→查询→告警→备份"全链路构建，每个工具独立部署、以 HTTP API 协作。vmalert 负责告警评估（执行 PromQL），Alertmanager 负责告警通知（发送消息），两者是上下游关系而非替代关系。

七、FAQ：20 组高频问答

思考记忆提示 — FAQ 是全篇的"临考前速背"模块，涵盖生态集成的所有高频问题

Q1-Q5 围绕 CNCF 生态定位：项目成熟度、Prometheus 关系、OTel 集成
Q6-Q10 围绕 k8s 部署：Operator、Helm、高可用、存储类
Q11-Q15 围绕工具链：vmagent、vmalert、vmauth、vmbackup、vmctl
Q16-Q20 围绕 Grafana / 迁移 / 成本：数据源配置、迁移策略、竞品对比

Q1. VictoriaMetrics 在 CNCF 中处于什么成熟度？

VictoriaMetrics 以 Sandbox 级别加入 CNCF，具体加入时间请参考 CNCF 官方公告。Sandbox 是 CNCF 成熟度的第一级，之上还有 Incubating（孵化）和 Graduated（毕业）两级。Prometheus 是 Graduated 项目，Grafana 也是 Graduated 项目，Thanos 是 Incubating 项目。

Q2. VictoriaMetrics 和 Prometheus 是什么关系？

VictoriaMetrics 是 Prometheus 的存储后端，不是替代品。Prometheus 负责采集（抓取 targets）和部分查询，VictoriaMetrics 负责存储和大规模查询。两者通过 Remote Write 协议连接，Prometheus 推送数据，VM 接收并存储。

Q3. VM 支持 OpenTelemetry 吗？

支持，vmagent 内置 OTLP 接收器。应用程序通过 OTel SDK 采集的 metrics 数据，可以通过 OTel Collector → vmagent → VictoriaMetrics 的路径存储。同时 vmagent 也支持将 Prometheus 格式的数据通过 OTLP 转发给其他 OTel 后端。

Q4. Prometheus Operator 可以管理 VictoriaMetrics 吗？

不能直接管理，但可以并行部署 VictoriaMetrics Operator。Prometheus Operator 专门管理 Prometheus 实例。如果想在 k8s 中管理 VM 集群，应使用 VictoriaMetrics Operator（vmoperator），它提供了 VMCluster、VMSingle、VMAgent 等 CRD。

Q5. Thanos 和 VictoriaMetrics 可以一起使用吗？

可以，但通常不需要。Thanos 的 Sidecar 模式将 Prometheus 数据写入对象存储，VictoriaMetrics 有自己的存储引擎。如果已经部署了 Thanos，可以逐步将新数据流切换到 VM，同时保留 Thanos 作为历史数据的查询入口。

Q6. 在 k8s 中如何部署 Single-Node vs Cluster？

小规模用 Single-Node（一个 StatefulSet），大规模用 Cluster（三个独立 Deployment）。Single-Node 通过 Helm 一行命令部署，适合 100 万以内 series。Cluster 模式需要分别部署 vminsert、vmstorage、vmselect，适合 1000 万+ series 和高可用需求。

Q7. Helm Chart 部署 VM 需要哪些关键配置？

三个核心配置：存储大小（storage.capacity）、副本数（replicaCount）、资源限制（resources）。建议为 vmstorage 配置 PersistentVolumeClaim，使用本地 SSD 或云厂商的 io1/io2 类型存储以获得最佳性能。

Q8. 如何保证 VM 在 k8s 中的高可用？

Cluster 模式下，vmstorage 部署多个副本，数据按 tenant 分片分布。单个 vmstorage 节点故障只会影响部分分片，不影响全局查询。建议至少部署 2 个 vmstorage 副本，并配置 Kubernetes PodDisruptionBudget 防止同时重启。

Q9. VM 支持哪些持久化存储后端？

本地 SSD 是性能最优解，也支持 NFS/云存储作为降级方案。在 k8s 环境中，推荐使用 LocalPV（本地 SSD）配合 StorageClass 的方式。云厂商的 CSI 驱动（如 AWS EBS、GCP PD）也可以使用，但性能不如本地 SSD。

Q10. 如何从 Prometheus 迁移到 VictoriaMetrics？

三步走：1）配置 Prometheus remote_write 指向 VM；2）等待新数据流入 VM；3）使用 vmctl 迁移历史数据。期间 Grafana 数据源切换到 VM，Grafana Dashboard 无需修改。整个过程可以热操作，不需要停机。

Q11. vmagent 和 Prometheus 相比有什么优势？

vmagent 更轻量、更灵活、内存占用更小。vmagent 本身不存储数据，只负责采集和转发，内存占用通常只有 Prometheus 的 1/5。同时 vmagent 支持将数据同时推送给多个目的地（multi-remote_write），这是 Prometheus 不支持的功能。

Q12. vmalert 和 Alertmanager 有什么区别？

vmalert 负责告警评估（执行 PromQL），Alertmanager 负责告警通知（发送消息）。两者是上下游关系：vmalert 执行告警规则判断是否触发，触发了就发给 Alertmanager，Alertmanager 再做分组、抑制、静默处理后通知用户。

Q13. vmauth 是什么？和 nginx 有什么区别？

vmauth 是专门为 VictoriaMetrics 设计的认证代理，支持 API Key/JWT 认证和基于 tenant 的路由。nginx 是通用反向代理，配置复杂但功能全面。vmauth 针对 VM 的多租户场景做了优化，开箱即用。

Q14. vmbackup 支持哪些云存储？

支持 S3/GCS/Azure Blob/MinIO 等所有 S3 兼容存储。vmbackup 通过快照硬链接实现增量备份（只备份新增的 Part 文件），支持按时间窗口恢复。备份过程不影响 VM 正常读写。

Q15. vmctl 迁移数据有速率限制吗？

有，vmctl 内置速率限制器，通过 --rate-limit 参数控制写入速度。默认不限制，生产环境建议设置 --rate-limit 避免压垮目标 VM。迁移大存量数据时，推荐分批次、限速进行。

Q16. Grafana 如何连接 VictoriaMetrics？

选择 Prometheus 数据源类型，URL 填入 VM 的 HTTP 地址即可。Grafana 原生支持 Prometheus API，VictoriaMetrics 完整实现了该 API，所以不需要安装任何插件。Grafana 甚至无法区分它在连接 Prometheus 还是 VictoriaMetrics。

Q17. VictoriaMetrics 相比 Thanos 的优势是什么？

VM 自研存储引擎（MergeSet），性能远优于 Thanos 的 Prometheus TSDB + 对象存储架构。Thanos 的优势是复用 Prometheus 配置，但查询性能受限于对象存储 IO。VM 将数据存储在本地 SSD，通过 MergeSet 引擎高效查询，在相同硬件下查询延迟通常只有 Thanos 的 1/10。

Q18. VictoriaMetrics 和 Prometheus Operator 的关系是什么？

Prometheus Operator 管理 Prometheus 实例，VictoriaMetrics Operator 管理 VM 实例，两者功能对标但各自独立。如果你的集群已经运行 Prometheus Operator，可以同时安装 VictoriaMetrics Operator，新部署的服务指向 VM，已有服务继续指向 Prometheus。

Q19. VM 有内置的告警功能吗？

VM 本身不内置告警引擎，告警功能由 vmalert 提供。vmalert 执行 PromQL 查询，根据结果判断是否触发告警，然后发送给 Alertmanager 或其他通知渠道（如 Slack、邮件、Webhook）。

Q20. VictoriaMetrics 的生态发展趋势如何？

GitHub stars 和用户案例请参考 GitHub 官方页面和官方文档（docs.victoriametrics.com case studies）。VictoriaMetrics 路线图包括 VictoriaLogs 日志集成、更深度的 OTel 支持、企业版特性下放，以及 Multi-tenant 隔离增强。

全篇必记总纲

VictoriaMetrics 在 CNCF 生态中的定位是Prometheus 的高性能存储后端：通过 Remote Write 协议接收 Prometheus/vmagent 的数据，通过 Prometheus API 向 Grafana 提供查询服务。在 k8s 环境中，通过 VictoriaMetrics Operator 或 Helm Chart 部署。工具链围绕"采集→存储→查询→告警→备份"全链路构建，vmagent 采集、VM 存储、vmalert 告警、vmbackup 备份，各司其职、以 HTTP API 协作。

八、Roadmap：后续预告

本篇覆盖了 VictoriaMetrics 在 CNCF 生态中的位置和集成方案，后续将深入各个专题：

#12 源码阅读路线图：如何高效阅读 VM 源码——最佳实践
#13 VictoriaLogs 协同：Metrics 到 Logs 的一体化监控——日志专题
#14 Enterprise vs OpenSource：关键功能差异——版本选择指南
#71 vmagent 架构：Prometheus-side 轻量级抓取代理——工具链专题
#92 Kubernetes Operator：VictoriaMetrics Operator 深度集成——k8s 专题

本文参考与源码链接：
  • VictoriaMetrics 官方文档
  • CNCF 项目全景
  • Prometheus Remote Write 配置
  • Grafana Prometheus 数据源
  • VictoriaMetrics Operator 文档
  • OpenTelemetry 官方文档

posted @ 2026-07-01 02:36 左扬阅读(17) 评论(0) 收藏举报

刷新页面返回顶部

左扬(你们的胃叫胃，孤的叫胃PLUS)

深耕云原生全栈架构，只为成为更好的自己 ——知命不惧，日日维新

VictoriaMetrics 1.146.0 源码专题【左扬精讲】—— 开源生态：VM 在 CNCF 生态中的位置

VictoriaMetrics 1.146.0 源码专题【左扬精讲】—— 开源生态：VM 在 CNCF 生态中的位置

一、从 CNCF 全景图看 VM 的生态位

1.1 CNCF 可观测性三要素与 VM 的对应关系

二、Prometheus 生态：VM 的核心集成

2.1 协议层面的完整兼容

2.2 数据流向全解析

2.3 vmagent：轻量级 Prometheus-side 采集代理

三、Kubernetes 生态：Operator 与 Helm 部署

3.1 VictoriaMetrics Operator

3.2 Helm Chart 部署

3.3 高可用部署架构

四、Grafana 生态：无缝集成

4.1 数据源配置

4.2 vmui 内置 UI

五、OpenTelemetry 生态：现代采集标准

5.1 vmagent 接收 OTLP

5.2 OpenTelemetry 与 Prometheus 的融合

六、VictoriaMetrics 工具链全家福

6.1 vmalert vs Alertmanager

6.2 数据迁移：vmctl 的多源支持

七、FAQ：20 组高频问答

Q1. VictoriaMetrics 在 CNCF 中处于什么成熟度？

Q2. VictoriaMetrics 和 Prometheus 是什么关系？

Q3. VM 支持 OpenTelemetry 吗？

Q4. Prometheus Operator 可以管理 VictoriaMetrics 吗？

Q5. Thanos 和 VictoriaMetrics 可以一起使用吗？

Q6. 在 k8s 中如何部署 Single-Node vs Cluster？

Q7. Helm Chart 部署 VM 需要哪些关键配置？

Q8. 如何保证 VM 在 k8s 中的高可用？

Q9. VM 支持哪些持久化存储后端？

Q10. 如何从 Prometheus 迁移到 VictoriaMetrics？

Q11. vmagent 和 Prometheus 相比有什么优势？

Q12. vmalert 和 Alertmanager 有什么区别？

Q13. vmauth 是什么？和 nginx 有什么区别？

Q14. vmbackup 支持哪些云存储？

Q15. vmctl 迁移数据有速率限制吗？

Q16. Grafana 如何连接 VictoriaMetrics？

Q17. VictoriaMetrics 相比 Thanos 的优势是什么？

Q18. VictoriaMetrics 和 Prometheus Operator 的关系是什么？

Q19. VM 有内置的告警功能吗？

Q20. VictoriaMetrics 的生态发展趋势如何？

八、Roadmap：后续预告

公告