从零搭建统一监控平台：云宏虚拟化接入 VictoriaMetrics 实践

企业引入云宏 CNware 虚拟化后，需要同时观察集群、宿主机、虚拟机和物理硬件。难点不是调用一次 API，而是把多种来源的数据转换为统一指标，稳定采集、长期保存，并通过同一套标签、看板和告警规则形成闭环。本文给出一套可从小规模起步、再逐步扩展的参考架构。

READING NOTES

本文要点

采用 VictoriaMetrics 不等于必须部署 Prometheus Server；vmagent 可以抓取 Prometheus 格式指标并通过 Remote Write 转发
CNware 接入应优先使用厂商正式支持的 Exporter 或 API，并在平台外建立独立适配层
vmalert 负责规则计算，Alertmanager 负责分组、去重、抑制和路由，两者职责不同
同一对象、同一类指标和同一条告警都应明确唯一主要来源，避免重复采集与告警风暴

01｜先确定平台边界

第一阶段先把 Metrics 链路做稳：确定数据从哪里来、由谁集中采集、存在哪里，以及异常如何进入通知和工单流程。Logs、Traces、变更事件与 CMDB 可以后续接入，但不应阻塞基础设施指标的统一。

这套方案把云宏视为首批监控对象之一，而不是把监控平台做成某个虚拟化产品的附属组件。采集、存储、查询和告警都保持通用协议，后续接入服务器、网络设备或其他虚拟化平台时不需要重建主链路。

监控对象 / Exporter
        │  Pull: /metrics
        ▼
     vmagent ── Remote Write ──> vminsert ──> vmstorage
                                      ▲            │
                                      │            ▼
通知渠道 / 工单 <── Alertmanager <── vmalert <── vmselect ── Grafana

FIELD NOTE监控负责发现异常；可观测性还要组织证据、解释影响，并让处置过程可以追踪。

02｜把组件与数据动作分开理解

方案评审里最常见的混乱，是把产品、进程、动作和协议放在同一层比较。例如 Push 只描述传输方向，Remote Write 才描述数据按照什么协议写入；两者并不冲突。

这里没有 Prometheus Server。vmagent 承担目标发现、抓取、过滤、补标签、队列缓冲和转发；VictoriaMetrics 承担时序存储和查询；vmalert 执行兼容 Prometheus 规则格式的告警与记录规则。

类别	示例	在架构中的含义
产品或平台	CNware、VictoriaMetrics、Grafana	提供一组可部署能力的软件
运行组件	vmagent、vminsert、vmstorage、vmselect、vmalert	承担特定职责的服务进程
数据动作	Scrape、Pull、Push、Query、Route	说明数据由谁发起、向哪里移动
协议或格式	HTTP、Remote Write、Redfish、IPMI、SNMP	规定两端交换数据的方式
接口或语言	/metrics、PromQL、MetricsQL	说明访问入口或查询表达式

03｜Exporter、Telegraf 与 vmagent 如何分工

Exporter 把目标系统的状态翻译为 Prometheus exposition format，通常只暴露 /metrics，不保存历史数据。Linux、Windows、黑盒探测、服务器带外管理和网络设备应按对象选择对应的 Exporter 或协议采集器。

Telegraf 与 vmagent 都能采集和转发指标，但定位不同。Telegraf 更像插件型主机 Agent，适合数据库、中间件和特殊设备插件；vmagent 更适合集中抓取 Prometheus 目标，并统一执行 relabel、过滤、缓冲和 Remote Write。

场景	建议链路
已有 Prometheus Exporter	Exporter → vmagent → VictoriaMetrics
依赖 Telegraf 特殊插件	Telegraf → vmagent → VictoriaMetrics
普通主机基础指标	Telegraf 与 node/windows_exporter 二选一
后端可能短时不可达	使用 vmagent 磁盘队列缓冲并设置容量上限

FIELD NOTE同一对象的同一组指标只指定一个主要采集器。重复采集不仅浪费容量，还会让看板与告警口径失去一致性。

04｜为云宏建立独立指标适配层

CNware 接入按三个优先级选择：厂商正式支持的外部 Exporter 或 /metrics、厂商支持的只读 API、厂商明确允许读取的内部监控数据。不要直接修改产品内部的 Prometheus、Grafana 或 Kubernetes 配置，这些组件首先服务于产品自监控，升级也可能覆盖人工变更。

当厂商 API 返回 JSON 时，需要一个独立的 cnware_exporter 负责认证、分页、限流、字段单位转换与缓存。生产实现不应在每次访问 /metrics 时临时登录并全量查询，而应由后台任务周期采集，/metrics 快速返回最近一次成功结果。

下面的指标名是适配层的建议命名，不代表厂商原生字段。正式上线前还要逐项确认指标单位、刷新周期、对象状态含义和 API 支持边界。

账号只授予读取监控与资源清单所需权限。
通过受控管理入口访问，启用 TLS 校验，不在配置文件中明文保存凭据。
限制并发、重试次数和采集频率，避免适配层反向压垮管理平台。
对象关联优先使用稳定 ID，名称只作为展示标签。

CNware API
    │ 只读账号 / 管理入口
    ▼
cnware_exporter
    ├─ 周期查询、分页、超时与缓存
    ├─ API 健康、采集耗时、最后成功时间
    └─ /metrics
         cnware_api_up
         cnware_host_cpu_used_ratio
         cnware_host_memory_used_ratio
         cnware_cluster_vm_count

05｜vmagent 与 VictoriaMetrics 的读写链路

vmagent 面向上游 Exporter 主动 Pull，面向下游存储主动 Push。Remote Write 规定指标的编码与写入接口。官方文档也说明，vmagent 可以抓取 Prometheus 兼容目标，并把数据写到 VictoriaMetrics 或其他兼容远端存储。

VictoriaMetrics 集群把写入、存储和查询拆成 vminsert、vmstorage 与 vmselect。Grafana 和 vmalert 访问 vmselect；vmagent 把指标写入 vminsert；底层数据由 vmstorage 保存。中小规模环境可以先用单机版验证指标模型，容量与高可用需求清晰后再切换集群版。

组件	职责	主要访问方
vminsert	接收写入并把数据分发到存储节点	vmagent、记录规则
vmstorage	保存时序数据和索引	vminsert、vmselect
vmselect	提供 PromQL / MetricsQL 兼容查询	Grafana、vmalert

vmagent \
  -promscrape.config=/etc/vmagent/scrape.yml \
  -remoteWrite.url=http://vminsert:8480/insert/0/prometheus/api/v1/write \
  -remoteWrite.tmpDataPath=/var/lib/vmagent-buffer \
  -remoteWrite.maxDiskUsagePerURL=20GB

06｜先统一标签，再建设 Grafana 看板

Grafana 是查询和展示客户端，不在 vmagent 到 vminsert 的写入链路中。把 vmselect 配置为 Prometheus 数据源后，先建设全局概览、集群容量、宿主机健康、虚拟机趋势与采集链路健康五类看板。

看板能否长期复用取决于标签，而不是面板数量。对象名称会变化，主关联键应使用稳定 ID；时间戳、完整错误信息与随机请求 ID 不应成为标签，否则会快速制造高基数序列。

先定义标签字典、允许值和责任人，再开放新数据源接入。
容量看板同时展示已用量、分配量、增长速率与预计耗尽时间。
每个业务看板保留到告警、日志或排障文档的跳转入口。

environment="production"
site="dc-a"
platform="cnware"
cluster_id="cluster-001"
host_id="host-001"
business_system="example-service"
owner_team="platform-ops"

07｜vmalert 与 Alertmanager 各自做什么

vmalert 周期性查询 vmselect，执行 PromQL 或 MetricsQL 规则，并在条件持续满足后生成告警。Alertmanager 再负责去重、分组、抑制、静默、路由与通知节奏，最后把事件送往通用通知渠道或工单平台。

只有现有告警中心已经完整承担这些治理能力，并提供经过验证的兼容入口时，才考虑减少 Alertmanager 这一层。仅仅部署 vmalert，不能替代告警管理。

每条规则明确持续时间、恢复条件、严重级别和责任团队。
通知中附带对象标签、看板链接和排障入口，不只发送一句阈值超限。
同一条告警不要同时在 Grafana、vmalert 和遗留平台重复计算。

groups:
  - name: cnware-host
    interval: 1m
    rules:
      - alert: CNwareHostCPUHigh
        expr: cnware_host_cpu_used_ratio > 0.90
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "虚拟化宿主机 CPU 使用率持续过高"

08｜按七个阶段灰度实施

从零建设时不要一次接入全部对象。先跑通少量测试目标，再逐步扩大范围，每个阶段都设置可验证的退出条件。

阶段	主要动作	完成标准
1. 指标设计	列对象、指标、来源与标签	每项有唯一采集器和责任人
2. 存储底座	部署单机版或集群版 VictoriaMetrics	写入、查询、容量与备份策略可验证
3. 采集试点	vmagent 接入少量 Linux、Windows 与黑盒目标	up 稳定，重启和短时断网无异常缺口
4. 云宏适配	以只读方式接入集群和宿主机概要	单位、刷新周期、限频与自监控已确认
5. 看板	接入 Grafana 并建设五类基础看板	标签筛选与对象跳转一致
6. 告警	部署 vmalert 与 Alertmanager	测试事件可完成去重、路由和恢复
7. 灰度验收	测试环境到单集群再到全量	故障演练、回退方案和责任矩阵已归档

09｜兼容遗留监控，但保持唯一出口

网络设备或历史主机可能仍由 Zabbix 等平台监控。建设初期可以保留旧链路，不必为了架构整洁强行一次性迁移；但必须建立告警责任矩阵，规定某类对象的某条告警由哪个平台主要产生。

等新链路的指标口径、标签和规则稳定后，再根据覆盖率与维护成本决定迁移范围。兼容链路可以存在，重复的责任出口不应该存在。

风险	直接结果	控制方式
Telegraf 与 Exporter 重复采集	指标重复、口径不一致	按对象和指标族指定唯一采集器
多平台重复配置规则	重复通知与告警风暴	指定唯一规则计算平台
高基数标签	存储增长和查询延迟	限制标签维度及取值数量
API 高频登录或全量查询	管理平台压力升高	复用会话、限并发、周期采集和缓存
修改厂商内部监控组件	升级覆盖并影响支持边界	只使用正式外部接口和独立适配层
跳过 TLS 校验	凭据或会话泄露	配置内部 CA 并启用证书校验

10｜从统一监控走向完整可观测性

Metrics 链路稳定后，再逐步增加集中日志、OpenTelemetry Trace、发布与配置变更事件、CMDB 关系、SLI/SLO 和成本治理。这样告警发生时，工程师可以从指标定位异常对象，再跳到同一时间窗口的日志、调用链和变更记录。

建设顺序可以概括为“先打通、再统一、后关联”：先保证关键对象持续产出可信数据，再统一标签、查询与告警，最后关联业务上下文并衡量处置效果。

让告警直接跳转到相关指标、日志与排障文档。
把发布、扩缩容和配置变更放进统一时间线。
用 CMDB 关联集群、宿主机、虚拟机、业务与责任团队。
以 SLI/SLO、错误预算和复盘衡量平台是否真正改善稳定性。

FIELD NOTE平台目标不是堆齐所有组件，而是让每个异常都能找到可信证据、明确责任并完成验证闭环。

SOURCES / 资料核对