Nagios vs Zabbix vs Prometheus：从设备失联到应用变慢，监控怎样交接

机房网络间歇中断时，值班人员首先需要知道哪些设备失联；业务恢复以后，应用团队又想追问：为什么只有某个接口的延迟持续升高？这两个问题都叫监控，但需要的数据和判断方式不同。

Nagios、Zabbix 与 Prometheus 的选择，适合从这两次交接开始。已有检查脚本能否继续使用，历史图里留下了什么，远端断网时谁还能作出判断，比把三者排成“旧一代到新一代”更有意义。以下以 Nagios Core 与商业版 XI、Zabbix 当前 7.4 文档以及 Prometheus 自建组件为范围，资料核对日期为 2026 年 10 月 21 日。

一条检查结果，怎样变成故障判断

Nagios Core 的插件接口很直接：程序输出文字，并用退出码报告状态。服务检查的 0、1、2、3 分别对应 OK、WARNING、CRITICAL、公开资料未说明；主机状态的解释还受主机检查规则影响。检查程序可以连 TCP 端口、查数据库，也可以调用内部系统接口。已有脚本如果表达的是明确的运行条件，这种模型仍然实用。官方插件接口

比如“备份是否在规定时间内完成”不必先变成复杂的时间序列分析。插件检查最近一次成功记录，将超时与执行失败分开，值班人员就能收到有业务意义的状态。代价是这些判断散落在插件与配置中，需要明确维护者；脚本还能执行，也不代表里面的超时、权限和异常处理一直正确。

也不能把 Core 的默认体验直接套给整个 Nagios。插件可附带 performance data，而 Nagios XI 提供配置向导、Web 配置、性能图表和报表等商业产品能力。比较采购方案时，应把 XI 的授权和支持，与自建 Core 加扩展的维护工作分别列出来。“Nagios 没有图表”会漏掉真正参与选型的版本。

连续数值留下来，才有第二次调查

Zabbix 将主机、监控项、触发器与模板组织在同一管理体系中。监控项收集值，触发器表达问题条件，模板用于复用配置。官方支持的采集方式包括 Agent、SNMP、HTTP、JMX 等，设备监控和应用指标可以进入同一套运维流程。监控项类型

历史留存尤其容易被界面误导。Zabbix 的 history 保存逐个采集值，trends 则对数值型数据按小时保存最小值、最大值、平均值和数量，两者可配置不同保留时间。一个月前仍有曲线，不等于当时每一分钟的样本还在。若问题是“尖峰恰好与一次部署重合吗”，只有小时趋势可能不够。history 与 trends

Prometheus 的起点则是带标签的时间序列。HTTP 拉取、服务发现和 PromQL 让团队能够按服务、实例或状态码聚合，而不只是逐台看机器是否健康。应用频繁扩缩容时，查询面向稳定的服务标签通常比追踪每个临时实例更容易延续。Prometheus 架构概览

这也要求提前设计标签。service、region 适合表示有限集合，逐请求变化的订单号或用户标识会产生大量时间序列；这类细节更适合放进日志或链路。把所有字段都变成标签，会把查询自由度转化为存储和内存压力。指标与标签规范

远端断网以后，采集与告警会怎样

Zabbix Proxy 适合放在远端站点收集数据，并在与 Server 通信中断时按本地缓冲配置暂存。它使用独立数据库，不能指向 Server 的数据库。但 Proxy 不计算触发器、不处理事件，也不发送告警。因此，“站点还能采集”和“站点断网时还能独立通知”是两项需求；部署 Proxy 只解决前者的一部分，缓冲容量和断网时长仍有上限。Proxy 的职责

Prometheus 将规则判断与通知处理分开。Server 评估告警规则，Alertmanager 负责分组、去重、路由、静默和抑制。若数据库失联导致多项服务同时报错，可以围绕共同标签组织通知，减少同一事件的重复打扰。Alertmanager 集群有自己的高可用配置；官方要求 Prometheus 向所有 Alertmanager 实例发送告警，而不是在两者之间简单负载均衡。Alertmanager 文档

所以迁移验收不能止于出现红色状态。应该让一个测试检查超时、恢复，再让上游依赖中断，观察通知到了谁、是否重复、恢复消息是否保留上下文。这里检验的是团队的完整配置，而不是某个产品页面列出的“支持告警”。

留得更久，不只是调大一个天数

Prometheus 有本地 TSDB，并非必须先搭建外部存储才能工作。未设置时间或容量保留限制时，默认时间保留为 15 天；可调整保留参数。官方也明确本地存储不是集群复制的持久存储方案，提供 remote write/read 接口与外部系统集成。Thanos、Mimir 等是可以评估的扩展路径，并非运行 Prometheus 的前置条件。本地存储与远程接口

延长保留以后，预算要同时考虑采集频率、活跃序列、磁盘与故障恢复。Zabbix 则需要区分原始 history 与聚合 trends 的数据库负担；Nagios Core 的状态记录和插件性能数据扩展，也不能直接等同于保留了可任意聚合的原始指标。三套系统都能产生历史视图，但历史视图能回答的问题并不相同。

自建预算除了许可证，还包括插件与模板升级、数据库或 TSDB 运维、采集器权限、通知配置和当班人员。XI 的商业授权也不能与“开源软件费用为零”直接比较后得出总成本结论。把同一组故障演练、同样的历史调查窗口和可用性目标摆在一起，成本差异才有解释。

让现有投资各自有位置

如果核心任务是复用大量明确的可用性检查，Nagios Core 仍值得保留；需要可视化配置与商业支持时，应具体评估 XI。设备、主机与分支站点由统一运维团队管理，且希望模板、趋势和告警保持一致时，Zabbix 是自然的候选。应用指标需要跨实例聚合、服务发现与持续演进的查询时，Prometheus 更贴近这种工作方式。

它们也可以并用。网络团队保留设备告警，应用团队采用 Prometheus，不必先证明某一套系统能吞下全部职责。真正需要统一的是服务命名、时间基准、告警归属和事故交接入口；否则增加一个平台只会增加一个需要复制搜索条件的窗口。

用观测云承接已有指标

若希望保留现有 exporter，再把指标接入观测云，可以从 DataKit 的 Prometheus Exporter 采集开始，检查采集地址、标签与过滤配置。先选一个服务核对指标含义和采样间隔，再扩展范围；指标接入本身不会自动迁移 Nagios 检查、Zabbix 触发器或 Alertmanager 的通知策略。