当我们在 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 生态中各项目的定位关系
CNCF（Cloud Native Computing Foundation，云原生计算基金会）是 Linux Foundation 旗下的非营利组织，负责维护和推广云原生领域的开源软件。截至 2026 年，CNCF 托管了超过 170 个项目，涵盖容器编排、服务网格、可观测性、存储、网络等各个领域。
VictoriaMetrics 于 2023 年 9 月以 Sandbox（沙箱）级别加入 CNCF，是可观测性领域中增长最快的时序数据库项目之一。在 CNCF 的项目成熟度体系中，Sandbox 是第一级，之上还有 Incubating（孵化）和 Graduated（毕业）两级。
我理解源码的意思是说
可以把 CNCF 想象成一个大型开放式厨房美食广场——Prometheus 是广场中央的主厨台（最早入驻，最多人用），而 VictoriaMetrics 是主厨台旁边新建的一个超级省电冰箱：它不替代主厨台（Prometheus），但可以让整个后厨（监控系统）存储更多食材（时序数据）、消耗更少电费（内存）。
具体类比如下：
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 的入口，VM 是 Prometheus 的扩展
VictoriaMetrics 对 Prometheus 生态的集成，首先体现在协议层面的完整兼容。Prometheus 定义了三个核心协议，VM 全部支持：
小贴士
Remote Write 是 Prometheus 最核心的数据导出机制。相比于 Prometheus 的 Federation 联邦模式（查询时拉取数据），Remote Write 是推送模式——Prometheus 本地只做采集，数据实时推送到 VM，好处是不占用 Prometheus 本地存储空间。
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 配置。
除了接收 Prometheus 推送的数据，VictoriaMetrics 还提供了自己的采集代理 vmagent。vmagent 可以完全替代 Prometheus 的抓取功能，并且支持将数据同时发送给多个目的地：
我理解源码的意思是说
vmagent 和 Prometheus 的关系，可以类比为快递小哥的两种工作模式：
具体类比如下：
vmagent 支持同时发送给多个目的地——就像快递小哥同时为多家电商平台取货送货，一个 agent 服务多个存储后端。
必记闭环逻辑（核心考点）
VictoriaMetrics 与 Prometheus 的集成以"Remote Write 协议"为桥梁，实现了数据流向的解耦：Prometheus/vmagent 负责采集，VM 负责存储和查询，Grafana 负责展示。三者各司其职，组成一个零迁移成本的可观测性栈。
思考记忆提示 — k8s 是 VM 最主流的部署环境
VictoriaMetrics Operator（vmoperator）是 VM 官方维护的 Kubernetes Operator，用于以声明式方式管理 VM 集群的所有组件。它本质上是 Prometheus Operator 的"维多利亚版本"，遵循相同的 CRD 设计理念：
小贴士
如果你已经在使用 Prometheus Operator，想迁移到 VM，不需要删除现有的 Prometheus Operator。可以在同一集群中并行部署 VictoriaMetrics Operator，逐步将数据流切换到 VM，实现平滑过渡。
对于不需要 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 可以控制副本数、资源限制、持久化存储、服务类型等所有参数。
在生产环境中，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 是 VM 数据的主要展示渠道
Grafana 是 CNCF 毕业的可视化项目，也是 VictoriaMetrics 最重要的展示层集成。
在 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 的全部端点。
VictoriaMetrics 自带了内置的 Web UI（vmui），位于 /vmui 路径。vmui 提供以下核心功能：
小贴士
vmui 是轻量级工具，适合快速调试和排查问题。生产环境仍然推荐使用 Grafana，因为 Grafana 拥有更丰富的图表类型、Dashboard 模板和告警功能。vmui 和 Grafana 可以并行使用，互不冲突。
必记闭环逻辑（核心考点）
Grafana 对 VictoriaMetrics 的支持是开箱即用的：选择 Prometheus 数据源类型，填入 VM 的 HTTP URL 即可。这是因为 VM 完整实现了 Prometheus API 的所有端点，Grafana 根本无法区分它是在查询 Prometheus 还是 VictoriaMetrics。
思考记忆提示 — OTel 是未来采集方向，VM 已全面支持
OpenTelemetry（OTel）是 CNCF 毕业项目，旨在统一 Metrics、Logs、Traces 的采集标准。VictoriaMetrics 通过以下两种方式接入 OTel 生态：
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 的路径存储。
OTel 的一个核心设计理念是"指标先行"（Metrics First）。VictoriaMetrics 的 OTLP 接收能力，让它可以同时服务于传统 Prometheus 采集（Prometheus 推送或拉取）和现代 OTel 采集两种模式：
我理解源码的意思是说
OTel 和 Prometheus 的关系，可以类比为新一代高速公路和普通公路：
具体类比如下：
必记闭环逻辑（核心考点）
VictoriaMetrics 通过 vmagent 的 OTLP 接收能力，无缝接入 OpenTelemetry 生态。这让 VM 同时支持传统 Prometheus 采集（Remote Write）和现代 OTel 采集（OTLP）两种模式，用户可以根据系统现状灵活选择，无需强制迁移。
思考记忆提示 — VM 不只是一个数据库，是一个完整的可观测性平台
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/ |
这里需要澄清一个常见混淆：vmalert 和 Alertmanager 是两个不同的东西，功能上互补但不重叠：
关系是：vmalert 执行告警规则 → 触发告警 → 发送给 Alertmanager → Alertmanager 通知。
设计精髓
VictoriaMetrics 工具链的设计哲学是"专注分工、REST 协作"：每个工具都是独立进程，通过标准 HTTP API 通信。这与 Prometheus Operator 的设计理念一致——用 Kubernetes 的声明式管理来组合分散的组件，形成一个有机的整体。
vmctl 是 VictoriaMetrics 提供的数据迁移工具，支持从以下系统迁移数据到 VM：
# 从 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 是全篇的"临考前速背"模块，涵盖生态集成的所有高频问题
VictoriaMetrics 于 2023 年 9 月以 Sandbox 级别加入 CNCF，是可观测性领域增长最快的沙箱项目之一。Sandbox 是 CNCF 成熟度的第一级，之上还有 Incubating（孵化）和 Graduated（毕业）两级。Prometheus 是 Graduated 项目，Grafana 也是 Graduated 项目，Thanos 是 Incubating 项目。
VictoriaMetrics 是 Prometheus 的存储后端，不是替代品。Prometheus 负责采集（抓取 targets）和部分查询，VictoriaMetrics 负责存储和大规模查询。两者通过 Remote Write 协议连接，Prometheus 推送数据，VM 接收并存储。
支持，vmagent 内置 OTLP 接收器。应用程序通过 OTel SDK 采集的 metrics 数据，可以通过 OTel Collector → vmagent → VictoriaMetrics 的路径存储。同时 vmagent 也支持将 Prometheus 格式的数据通过 OTLP 转发给其他 OTel 后端。
不能直接管理，但可以并行部署 VictoriaMetrics Operator。Prometheus Operator 专门管理 Prometheus 实例。如果想在 k8s 中管理 VM 集群，应使用 VictoriaMetrics Operator（vmoperator），它提供了 VMCluster、VMSingle、VMAgent 等 CRD。
可以，但通常不需要。Thanos 的 Sidecar 模式将 Prometheus 数据写入对象存储，VictoriaMetrics 有自己的存储引擎。如果已经部署了 Thanos，可以逐步将新数据流切换到 VM，同时保留 Thanos 作为历史数据的查询入口。
小规模用 Single-Node（一个 StatefulSet），大规模用 Cluster（三个独立 Deployment）。Single-Node 通过 Helm 一行命令部署，适合 100 万以内 series。Cluster 模式需要分别部署 vminsert、vmstorage、vmselect，适合 1000 万+ series 和高可用需求。
三个核心配置：存储大小（storage.capacity）、副本数（replicaCount）、资源限制（resources）。建议为 vmstorage 配置 PersistentVolumeClaim，使用本地 SSD 或云厂商的 io1/io2 类型存储以获得最佳性能。
Cluster 模式下，vmstorage 部署多个副本，数据按 tenant 分片分布。单个 vmstorage 节点故障只会影响部分分片，不影响全局查询。建议至少部署 2 个 vmstorage 副本，并配置 Kubernetes PodDisruptionBudget 防止同时重启。
本地 SSD 是性能最优解，也支持 NFS/云存储作为降级方案。在 k8s 环境中，推荐使用 LocalPV（本地 SSD）配合 StorageClass 的方式。云厂商的 CSI 驱动（如 AWS EBS、GCP PD）也可以使用，但性能不如本地 SSD。
三步走：1）配置 Prometheus remote_write 指向 VM；2）等待新数据流入 VM；3）使用 vmctl 迁移历史数据。期间 Grafana 数据源切换到 VM，Grafana Dashboard 无需修改。整个过程可以热操作，不需要停机。
vmagent 更轻量、更灵活、内存占用更小。vmagent 本身不存储数据，只负责采集和转发，内存占用通常只有 Prometheus 的 1/5。同时 vmagent 支持将数据同时推送给多个目的地（multi-remote_write），这是 Prometheus 不支持的功能。
vmalert 负责告警评估（执行 PromQL），Alertmanager 负责告警通知（发送消息）。两者是上下游关系：vmalert 执行告警规则判断是否触发，触发了就发给 Alertmanager，Alertmanager 再做分组、抑制、静默处理后通知用户。
vmauth 是专门为 VictoriaMetrics 设计的认证代理，支持 API Key/JWT 认证和基于 tenant 的路由。nginx 是通用反向代理，配置复杂但功能全面。vmauth 针对 VM 的多租户场景做了优化，开箱即用。
支持 S3/GCS/Azure Blob/MinIO 等所有 S3 兼容存储。vmbackup 通过快照硬链接实现增量备份（只备份新增的 Part 文件），支持按时间窗口恢复。备份过程不影响 VM 正常读写。
有，vmctl 内置速率限制器，通过 --rate-limit 参数控制写入速度。默认不限制，生产环境建议设置 --rate-limit 避免压垮目标 VM。迁移大存量数据时，推荐分批次、限速进行。
选择 Prometheus 数据源类型，URL 填入 VM 的 HTTP 地址即可。Grafana 原生支持 Prometheus API，VictoriaMetrics 完整实现了该 API，所以不需要安装任何插件。Grafana 甚至无法区分它在连接 Prometheus 还是 VictoriaMetrics。
VM 自研存储引擎（MergeSet），性能远优于 Thanos 的 Prometheus TSDB + 对象存储架构。Thanos 的优势是复用 Prometheus 配置，但查询性能受限于对象存储 IO。VM 将数据存储在本地 SSD，通过 MergeSet 引擎高效查询，在相同硬件下查询延迟通常只有 Thanos 的 1/10。
Prometheus Operator 管理 Prometheus 实例，VictoriaMetrics Operator 管理 VM 实例，两者功能对标但各自独立。如果你的集群已经运行 Prometheus Operator，可以同时安装 VictoriaMetrics Operator，新部署的服务指向 VM，已有服务继续指向 Prometheus。
VM 本身不内置告警引擎，告警功能由 vmalert 提供。vmalert 执行 PromQL 查询，根据结果判断是否触发告警，然后发送给 Alertmanager 或其他通知渠道（如 Slack、邮件、Webhook）。
快速增长：2024 年 GitHub stars 突破 15k，被 Spotify、Roblox、Grammarly 等大厂采用，CNCF 沙箱项目身份加速生态影响力。未来方向包括 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 协作。
本篇覆盖了 VictoriaMetrics 在 CNCF 生态中的位置和集成方案，后续将深入各个专题：
本文参考与源码链接：
• VictoriaMetrics 官方文档
• CNCF 项目全景
• Prometheus Remote Write 配置
• Grafana Prometheus 数据源
• VictoriaMetrics Operator 文档
• OpenTelemetry 官方文档
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。