我为什么选择 Victoria 体系¶
我的目标不是追求组件最多、功能最全的可观测平台，而是在满足指标、日志、查询、告警和 Grafana 展示的前提下，尽量降低服务器资源、存储成本和日常维护复杂度。
在这个约束下，我倾向于使用：
指标：vmagent → VictoriaMetrics
日志：Vector / vlagent → VictoriaLogs
查询与展示：Grafana
指标告警：vmalert → Alertmanager
这里的“Victoria 体系”主要指 VictoriaMetrics（VM）和 VictoriaLogs（VL）作为数据后端。Grafana 仍然保留，因为存储查询与统一展示是不同职责。
先说结论¶
Victoria 体系适合以下环境：
- 希望保留 Prometheus 指标格式、PromQL 习惯和现有 Grafana Dashboard。
- 指标、日志数据量持续增长，但不想维护过多分布式组件。
- 更关注写入吞吐、压缩、长时间保留和易运维。
- 可以接受 VictoriaLogs 使用 LogsQL，而不是继续使用 Elasticsearch Query DSL 或 LogQL。
- 愿意用自己的数据做容量与查询验证，而不是直接相信厂商性能数字。
它不是所有场景的绝对最优解。如果团队深度依赖 Elastic 的搜索、分析、生态插件和安全能力，或者已有稳定运行的 Prometheus/Loki 平台，迁移收益可能不足以覆盖改造成本。
原有组合解决了什么，又带来了什么¶
传统平台常见组合是：
这些方案成熟、资料多、生态完整，但随着数据量扩大，可能出现：
| 问题 | 常见表现 |
|---|---|
| 指标长期保存 | 单机 Prometheus 本地保留有限，需要增加远端存储或分片方案 |
| 日志存储成本 | Elastic 索引、Heap、分片和副本需要持续规划 |
| Loki 标签设计 | 高基数标签带来索引和查询压力，字段检索模型与 Elastic 不同 |
| 组件数量 | 采集、存储、查询、规则、网关分别维护，升级关系复杂 |
| 容量估算 | 指标基数、日志字段、保留期和副本策略很容易造成资源膨胀 |
这些不是产品“不能用”，而是运维成本是否符合当前团队规模的问题。
VictoriaMetrics 为什么适合做指标后端¶
VictoriaMetrics 是时序数据库，支持 Prometheus Remote Write、Prometheus 查询 API 和 PromQL，并提供 MetricsQL 扩展。现有 Exporter、应用 /metrics、Grafana Prometheus 数据源和多数 Dashboard 可以继续使用。
推荐把采集与存储分开：
这样做的价值：
- vmagent 靠近数据源，存储端维护时可以利用队列和重试缓冲。
- VictoriaMetrics 专注时序数据存储与查询。
- 单机版可以覆盖相当一部分中小规模场景，减少过早集群化。
- 需要扩大时再评估 VMCluster，而不是一开始部署所有分布式组件。
- Grafana 仍按 Prometheus 数据源连接，学习和迁移成本较低。
但“兼容 Prometheus”不应写成所有行为百分百相同。复杂 PromQL、Recording Rule、Remote Write、标签处理和 Dashboard 必须用真实数据验证；Prometheus 自身仍可以作为本地采集与故障查询入口。
VictoriaLogs 为什么适合做日志后端¶
VictoriaLogs 面向结构化和非结构化日志存储，使用 LogsQL 查询。官方文档说明它支持在日志字段中进行全文检索、组合过滤、查询时字段提取和统计聚合。
Kubernetes stdout / 主机文件 / Syslog
→ Vector、VictoriaLogs Collector 或 vlagent
→ VictoriaLogs
→ LogsUI / Grafana VictoriaLogs 数据源
选择它的主要原因：
- 日志存储、索引和保留由较少组件完成。
- 同时支持全文搜索、结构化字段和统计查询。
- 采集端可以使用 Vector，也可以选择 VictoriaLogs 官方 Collector/vlagent。
- 与 VictoriaMetrics 使用相似的部署、参数、监控和运维思路。
- Grafana 官方插件可以使用 LogsQL 查询、Explore、实时日志、Dashboard 和告警。
需要明确：VictoriaLogs 不是 Elasticsearch 或 Loki 的协议级完全替代。
| 原平台能力 | 迁移到 VictoriaLogs 时要处理 |
|---|---|
| Elasticsearch Query DSL / Kibana | 改写为 LogsQL，并重新规划 Grafana Dashboard |
| LogQL / Loki 标签 | 改成 VL 的 Stream Fields 与普通字段设计 |
| ILM、Index Template、Shard | 改为 VL 的保留、存储和数据流设计 |
| Elastic 插件和分析生态 | 确认 VL/Grafana 是否具有等价能力 |
迁移前必须抽取真实日志，测试写入速率、压缩后容量、常用查询、长时间范围查询和高基数字段，而不是只验证能写入和能搜索。
vmagent、Vector 和 vlagent 的职责¶
这几个组件不能混为一谈：
| 组件 | 主要数据 | 职责 |
|---|---|---|
| vmagent | Metrics | Prometheus 风格发现、抓取、Relabel、缓冲和 Remote Write |
| Vector | Logs，也支持其他信号 | Kubernetes/文件日志采集、解析、转换和发送 |
| VictoriaLogs Collector | Logs | 官方 Kubernetes 日志采集 Chart，负责把容器日志发送到 VL |
| vlagent | Logs | VictoriaLogs 原生 Agent，可采集、缓冲并转发日志 |
Vector 不是 VictoriaMetrics 团队的组件，只是 VL 官方支持的采集器之一。新建平台时应在 Vector、VictoriaLogs Collector/vlagent 中做一次选择，避免同一批日志被多个 DaemonSet 重复采集。
为什么仍然使用 Grafana¶
VictoriaMetrics 和 VictoriaLogs 都自带 Web UI：
- VMUI 适合临时执行 MetricsQL/PromQL、检查标签和定位慢查询。
- LogsUI 适合执行 LogsQL、查看日志字段和调试摄取结果。
它们更接近管理员查询工具，不是统一可观测门户。Grafana 仍负责：
- 服务、主机、Kubernetes、数据库和中间件综合 Dashboard。
- 环境、集群、Namespace、服务和实例变量。
- 指标、日志与 Trace 之间的跳转关联。
- Folder、权限、共享、注解和统一展示。
- 在明确规则归属后承载部分告警展示与管理。
指标侧把 VictoriaMetrics 配成 Prometheus 数据源；日志侧安装官方 victoriametrics-logs-datasource 插件并使用 LogsQL。原有 Prometheus Dashboard 多数可以继续使用，但不能承诺“所有 Dashboard 无需修改”，仍要验证数据源 UID、指标名称、标签和查询兼容性。
最终架构¶
[ 数据产生与采集 ] [ 存储和规则 ] [ 展示与通知 ]
应用 / Exporter / K8s
│
└─ vmagent ───────────> VictoriaMetrics ───────┐
│ │
└─ vmalert ─> Alertmanager
├─> Grafana
容器 stdout / 文件 / Syslog │
│ │
└─ Vector / vlagent ───> VictoriaLogs ─────────┘
Grafana 不在写入链路中。即使 Grafana 故障，采集和存储仍应继续；即使存储正常，Grafana 数据源、插件或权限错误也可能表现为“页面无数据”。排障时必须分层判断。
关于“节省 50%～80%”¶
不能把一个固定节省比例写进方案承诺。真实资源差异取决于：
- 指标活跃时序和标签基数。
- 日志每日写入量、字段和 Stream 设计。
- 数据保留时间、复制和备份策略。
- 查询时间范围、并发和 Dashboard 刷新频率。
- 原平台是否已经正确调优。
- 单机或集群模式，以及存储介质性能。
更严谨的说法是：Victoria 体系以高写入吞吐、压缩和较少组件为重要选型理由，预期能够降低资源和维护成本；最终节省比例必须通过同一批真实数据、相同保留期和相同查询目标做对比测试。
我不会因此放弃的能力¶
- 数据保留、容量和高基数监控。
- 备份、恢复与故障演练。
- vmalert/Alertmanager 的规则、路由和端到端通知测试。
- Grafana、数据源和 Dashboard 的 Git 化管理。
- 对采集队列、丢弃、写入错误和查询延迟的自监控。
- 日志脱敏、租户隔离、认证、TLS 和访问审计。
“组件轻量”不等于不需要运维，单节点也不等于天然高可用。
官方安装方式怎么选择¶
本页只记录安装入口和选择边界，具体安装参数单独整理，不在选型页堆放大段 YAML。
| 环境 | 推荐入口 | 适合情况 |
|---|---|---|
| Kubernetes 快速安装单个组件 | 官方 Helm Charts | 直接部署 VM/VL Single、Cluster、Agent、Collector 等 |
| Kubernetes 完整监控套件 | victoria-metrics-k8s-stack Helm Chart |
希望一次安装 Operator 和常用 Kubernetes 监控资源 |
| Kubernetes 长期声明式管理 | VictoriaMetrics Operator | 用 VMSingle/VMCluster、VLSingle/VLCluster、VMAgent、VLAgent 等 CRD 管理 |
| Linux 主机或虚拟机 | 官方 Ansible Collection | 批量部署 vmsingle、vmagent、vmalert、VM/VL Cluster 等 |
| 本地验证 | 官方二进制或容器镜像 | 快速验证写入、查询、Dashboard 和容量，不代表生产方案 |
Helm¶
官方 Helm 仓库同时提供 VictoriaMetrics、VictoriaLogs、Collector、Operator 和 K8s Stack 等 Chart。部署前先导出并提交 Values，固定 Chart/App 版本，执行模板或 dry-run 检查，再进入正式发布。
VictoriaMetrics Operator¶
Operator 适合 Kubernetes 中长期管理多个 Victoria 组件，以 CRD 表达期望状态并持续协调。它支持 VictoriaMetrics 和 VictoriaLogs 相关资源，也可以配合 GitOps。引入 Operator 的代价是增加 CRD、控制器、升级顺序和权限管理，因此单个简单实例不一定必须使用。
官方 Ansible Collection¶
官方仓库提供 victoriametrics.cluster Collection，可部署 vmsingle、vmagent、vmalert、VMCluster，以及 VictoriaLogs/VictoriaTraces 集群等，适合没有 Kubernetes 的 Linux/虚拟机环境。
VictoriaMetrics Ansible Playbooks
最终决策¶
我选择 VictoriaMetrics + VictoriaLogs，不是因为它们可以“无条件替代所有平台”，而是它们更符合当前目标：
保留 Prometheus/Grafana 使用习惯
+ 统一指标与日志后端的运维思路
+ 控制服务器资源和存储成本
+ 减少不必要的分布式组件
+ 保留后续从 Single 扩展到 Cluster 的路径
选型成功的标准不是安装完成，而是同样的数据保留和查询目标下，平台确实更稳定、更容易维护，并且故障、备份和恢复流程都能被团队掌握。
官方参考：VictoriaMetrics 文档、VictoriaLogs LogsQL、VictoriaLogs Grafana 插件。