VictoriaMetrics 简介与生产运维

VictoriaMetrics 是 Prometheus 兼容的时序数据库与监控组件集合。它能接收 Prometheus Remote Write、暴露 PromQL 兼容查询接口，并以较低的存储与查询开销支撑长期指标保留。它适合希望保留现有 Exporter、Prometheus 规则和 Grafana 看板，同时扩展容量或保留周期的团队。

它不替代采集、告警路由和可视化：Prometheus 或 vmagent 负责采集与转发，VictoriaMetrics 负责存储和查询，Grafana 负责展示，Alertmanager 或 vmalert 负责告警通知。

1. 组件与部署形态

形态	组件	适用场景	主要限制
单机	victoria-metrics	单集群、中等指标量、先降低运维复杂度	单实例仍需备份与故障恢复方案
采集代理	vmagent	集中转发、削峰、Remote Write 重试、服务发现	不持久化长期查询数据
集群	vminsert、vmselect、vmstorage	多租户、大规模写入、长期保留和独立扩容	组件、存储与网络运维复杂度更高
告警	vmalert	使用 MetricsQL 或 PromQL 规则	仍需接入 Alertmanager 等通知系统

在规模尚不明确时，优先从单机 VictoriaMetrics 或 vmagent + 已有 Prometheus 开始。只有在写入、数据量、租户隔离或查询并发有明确压力时，再拆分为集群部署。

Exporter / Application --> Prometheus or vmagent --> VictoriaMetrics --> Grafana
                                      |                   |
                                      |                   +--> 备份 / 长期保留
                                      +--> Alertmanager / vmalert

2. Prometheus Remote Write 接入

在 Prometheus 中增加 Remote Write 后，指标会继续保存在本地 TSDB，并异步写入 VictoriaMetrics。先保留本地数据一段时间，确认写入延迟、标签和查询结果一致后再调整保留周期。

remote_write:
  - url: http://victoriametrics.monitoring.svc:8428/api/v1/write
    # 队列需要按真实写入量压测；不要盲目增大并发。
    queue_config:
      max_shards: 8
      capacity: 10000
      max_samples_per_send: 2000
    # 通过外部标签标识来源集群，避免跨集群序列混淆。
    write_relabel_configs:
      - target_label: storage
        replacement: victoriametrics

接入后在 Prometheus 的 remote_storage_* 指标中观察队列长度、失败次数和发送延迟。持续增长的 pending 队列通常意味着网络、后端容量、限流或序列基数出现问题。

3. 单机部署基线

单机模式应使用独立数据盘、受控保留期和最小网络暴露。下面的 Compose 示例用于说明核心参数；生产环境应补充资源限制、日志收集、TLS、身份认证与备份任务。

services:
  victoriametrics:
    image: victoriametrics/victoria-metrics:latest
    command:
      # 数据目录必须挂载到持久化磁盘。
      - -storageDataPath=/storage
      # 保留期按合规、查询需求和成本确定。
      - -retentionPeriod=90d
      # 仅在可信网络内开放 HTTP 接口。
      - -httpListenAddr=:8428
    volumes:
      - /srv/victoriametrics:/storage
    ports:
      - "8428:8428"
    restart: unless-stopped

不要把容器可写层当作数据盘，也不要在没有备份和恢复演练的情况下把单实例标记为高可用。

4. 查询与健康检查

VictoriaMetrics 提供 Prometheus HTTP API 兼容接口。Grafana 数据源地址通常是 http://<host>:8428，先用基础查询验证写入和标签，再迁移复杂面板。

# 检查服务存活；200 表示 HTTP 端点可达，不等于数据写入正常。
curl -fsS http://victoriametrics.monitoring.svc:8428/health

# 查询最近 5 分钟是否有 up 指标，验证写入和 PromQL 查询链路。
curl -G 'http://victoriametrics.monitoring.svc:8428/api/v1/query' \
  --data-urlencode 'query=up'

# 查看活跃时间序列数量，用于容量和高基数风险评估。
curl -fsS 'http://victoriametrics.monitoring.svc:8428/api/v1/status/tsdb'

排障时先区分四段链路：采集目标是否正常、Prometheus/vmagent 是否积压、Remote Write 是否成功、VictoriaMetrics 是否能按预期返回查询。不要仅根据 Grafana 空面板判断存储故障。

5. 容量、标签与备份

• 容量：按每日写入样本数、平均标签数、保留期和查询窗口测算，使用真实指标回放验证，而不是只看磁盘压缩比。
• 标签：继续遵循 Prometheus 的低基数原则。用户 ID、订单 ID、完整 URL、请求 ID 和错误文本不应作为标签。
• 多租户：集群或多租户接口需要明确租户 ID、认证边界和 Grafana 数据源权限，避免不同环境数据混查。
• 备份：备份对象、频率、保留周期与恢复目标必须文档化；备份成功不等于可恢复，至少定期恢复到隔离环境验证查询。

6. 学习路径

1. Prometheus Remote Write 接入：在不改变既有抓取方式的前提下，将指标写入 VictoriaMetrics。
2. vmagent 采集与转发：在大规模采集、跨网络转发或替换 Prometheus 抓取职责时使用。
3. 集群架构与 Kubernetes 部署：了解 vminsert、vmselect 与 vmstorage 的扩缩容边界。
4. 备份、恢复与故障排查：把数据保留、灾备、容量和日常巡检落到可执行流程。

验收清单

• Remote Write 队列没有持续积压，失败与重试指标处于可接受范围。
• Grafana 的常用 PromQL、长时间范围查询和告警规则已验证兼容性。
• 数据目录、保留期、备份位置和恢复责任人已明确。
• 关键标签经过基数治理，跨集群与环境查询能通过标签准确过滤。