政企信息中心与集成商常面对这样的局面：核心业务跑在物理机与虚拟机上，新业务又陆续迁到云主机，网络设备散在各校区，监控却各管一摊——Zabbix 看服务器、云控制台看云资源、网管软件看交换机，告警散落、口径不一，出故障没人说得清全貌。本文面向信息化团队与集成商交付侧，给出一套"混合环境统一监控"的可落地架构：用一套监控内核把物理机、虚拟机、云主机、网络设备收口到同一视图。方案基于原生 Zabbix 6.0 LTS 验证，云主机侧采用云厂商 Exporter / API 对接，不涉及任何闭源适配。风险提示：统一前先冻结一套命名规范，否则后期主机群组会乱到无法收敛。
一、问题本质：不是缺工具，是缺"统一建模"
混合环境监控碎片的根本原因，不是没有监控软件，而是每个环境用了不同的采集协议与命名体系。物理机用 Zabbix Agent、网络设备用 SNMP、云主机用云 API，三者若各自为政，主机名、分组、指标含义都对不上，自然无法汇总。解决思路是"采集协议可不同，但建模必须统一"——在监控平台侧用同一套主机群组与标签贯穿所有对象。
二、分层架构（落地步骤）
建议四层：
- 采集层：按对象类型选协议，就近部署 Proxy 减轻中心压力。
- 汇聚层：跨校区/跨机房部署 Zabbix Proxy，网络不通时本地缓存、恢复后上送，中心只收汇总数据。
- 存储层：统一落 MySQL/MariaDB，开启后续分区维护。
- 展现层：Grafana 统一出图，按"校区/业务/环境"三维过滤，管理层与执行层各取所需。
三、采集方式矩阵（实操经验）
| 对象类型 | 推荐采集方式 | 建议间隔 | 说明 |
|---|---|---|---|
| 网络设备（交换机/路由器） | SNMP v2c/v3 | 1–5 min | 读接口流量、CPU、温度，v3 建议开认证 |
| 物理服务器 | Zabbix Agent（主动） | 1 min（核心）/5 min（普通） | 主动模式省连接数 |
| 虚拟机（VMware/KVM） | 虚拟机平台 API 或宿主机 Agent | 1–5 min | 取 CPU/内存/磁盘配额使用率 |
| 云主机（公有云/私有云） | 云厂商 Exporter / 监控 API 拉取 | 1–5 min | 通过 AK/SK 只读拉取，禁止写权限 |
| 业务/HTTP 探活 | Web 监测 / HTTP Agent | 30 s–1 min | 测可用性与时延 |
高频采集（10s/30s）只保留关键指标，历史数据保留 7 天即可，避免存储压力。
四、统一建模：命名与打标规范
主机群组按三维组织：校区 / 业务系统 / 环境（生产·测试）。例如 东区校区 / 一卡通 / 生产。标签（宏）统一注入：env=prod、biz=card、zone=east。这样一张 Grafana 面板用 $env、$biz 变量即可在全校范围钻取，无需为每套环境单独建图。
- 命名规范后置：先采集后统一，结果主机名重复、分组混乱，返工成本高于重做。
- 中心直连所有 Agent：跨校区公网直接连 Server，断网即丢数据；应部署 Proxy 做缓存汇聚。
- 云主机用写权限 AK：只读拉取即可，给写权限等于敞开口子，违反最小权限。
- 高频全量采集：所有指标都 10s 采，存储半年爆表；高频只给核心项。
混合环境统一监控的关键，是"协议可杂、建模要纯"：采集方式随对象灵活选，但主机群组与标签必须全校一套。先把命名规范冻结，再按四层架构落地，监控全貌自然清晰。
若你正在为混合 IT 环境设计统一监控架构、需要开源栈落地参考，可联系我们获取基于开源监控平台的架构与可视化方案咨询。
