网络运维监控三剑客怎么选

监控系统可以拆成三个平面：采集面负责从设备、主机、应用拿到数据；存储与查询面负责时序数据的持久化和检索；告警与执行面负责阈值判断、通知和联动。Zabbix 是三者一体的传统监控平台，强项在设备纳管、模板化采集和告警动作；Prometheus 以拉取模型和 PromQL 查询为核心，强项在指标存储与聚合；OTel 不是监控后端，而是采集与传输的规范，统一 metrics、logs、traces 的管道。

素材给出的关键判断是：Prometheus 与 OTel 在 metrics 层已经融合。这意味着 OTel Collector 可以作为统一采集入口，把指标导出到 Prometheus 兼容的存储，而不必在两者之间做取舍。Zabbix 8.0 rc1 的发布信息来自该媒体片段，GA 时间属于预计，生产环境升级应以官方发布说明为准。

Prometheus 采用拉取模型，由服务端周期性抓取目标的 /metrics 端点，数据模型是“指标名 + 标签集”的时序样本。OTel 采用推送或拉取均可的 Collector 架构，数据模型包含资源属性、指标、日志和链路，语义更丰富但链路更长。Zabbix 以主动/被动检查采集，数据落到关系型数据库，适合结构化资产和触发器逻辑。

一个常见误区是把高基数标签直接塞进 Prometheus。标签值数量爆炸会显著增加内存与查询开销，这类数据更适合走日志或链路系统。反过来，设备 SNMP 采集、带外管理、告警升级流程，用 Zabbix 的模板和动作机制更省事。边界判断可以简化为：需要资产台账和告警联动的，归 Zabbix；需要灵活聚合与查询的指标，归 Prometheus；需要统一采集规范和多后端分发的，归 OTel。

假设一个园区网有核心交换机、接入交换机和防火墙，需要同时监控端口流量、设备可达性和应用侧接口延迟。可复现的做法是：OTel Collector 部署在管理区，通过 SNMP receiver 或主机 agent 采集设备指标，同时接收应用侧通过 OTLP 推送的指标，统一导出到 Prometheus 兼容后端；Zabbix 继续负责设备可达性、告警升级和工单联动。

示例配置思路（参数需按现场调整，不作为通用模板）：

验证命令示例：用 curl -s http://<collector>:8888/metrics 查看 Collector 自身指标；用 PromQL 查询 up{job="otel-export"} 确认目标状态；用 promtool check config 校验抓取配置语法。这些命令属于通用实践示例，具体端口和路径以实际部署为准。

第一步，盘点现有监控资产。列出 Zabbix 中已纳管的设备、模板和告警动作，标记哪些必须保留在 Zabbix，哪些指标可以迁移到指标后端。第二步，确定采集边界。设备侧 SNMP、带外管理留在 Zabbix；应用与中间件指标走 OTel Collector；主机基础指标按团队习惯二选一，避免重复采集。第三步，搭建最小管线。先接一个业务系统的 OTLP 指标，验证从 Collector 到后端的完整链路，再逐步扩量。第四步，统一告警出口。指标后端负责阈值告警，Zabbix 负责设备类告警，通知渠道收敛到同一平台，避免告警风暴。第五步，建立基线指标。至少监控抓取成功率、采集延迟、Collector 队列丢弃数和后端写入错误率。

组合架构的代价是运维面变多。Collector 本身成为新的单点，需要配置资源限制和健康检查；Prometheus 的本地存储不适合长期保留，长期数据需要远端存储或降采样策略；Zabbix 数据库增长需要定期清理历史数据。素材没有给出具体性能数字，任何容量规划都应基于现场压测，而不是照搬他人参数。

另一个边界是团队能力。OTel 的配置项较多，缺少专人维护时容易变成“装了但没人看”的管道。若团队规模小、设备类型单一，Zabbix 单栈加少量脚本可能更稳；若已有云原生环境和多后端需求，OTel 加 Prometheus 的分层更合适。Zabbix 8.0 尚处 rc 阶段，生产升级应等待 GA 并核对变更说明，不宜在关键告警链路上先行试水。