Nagios 运维实践：从插件机制到告警收敛的落地路径
Nagios 是运维监控领域里资历很深的一套体系，它的价值不在于界面有多现代，而在于“检查—判定—通知”这条链路足够清晰、可拆解、可替换。本页不重复安装向导，而是从极客运维的日常视角出发，围绕插件机制、对象定义、告警收敛与迁移取舍几个层面，整理一套可以在生产环境里长期维护的 Nagios 使用方式。
一、插件机制：Nagios 的检查能力边界
Nagios 本身并不直接采集指标，它调用外部插件，根据插件返回的退出码（0 OK / 1 WARNING / 2 CRITICAL / 3 UNKNOWN）与第一行文本做出状态判定。这意味着检查能力的上限由插件决定，而 Nagios 只负责调度、状态保持与通知。
- 优先使用 check_* 系列标准插件，减少自研维护成本
- 自研插件必须遵守退出码约定，输出保持单行、可读
- 检查超时与执行用户要和 Nagios 进程保持一致
- 被动检查（NSCA / NRDP）适合无法主动拉取的场景
二、对象定义：把配置当成代码来管
Nagios 的配置由一组对象定义文件组成，主机、服务、命令、联系人之间通过模板与继承关系复用。规模一大，手工编辑就容易失控，比较稳妥的做法是把对象定义纳入版本管理，用模板收敛公共属性，主机侧只保留差异项。
| 对象类型 | 典型用途 | 维护建议 |
|---|---|---|
| host | 被监控主机 | 用 hostgroup 分组，父主机设置 parents |
| service | 具体检查项 | 模板统一 check_interval 与 retry_interval |
| command | 插件调用命令 | 参数集中管理，避免散落在 service 里 |
| contact | 通知接收人 | 按值班组划分，配合 timeperiod 控制时段 |
三、告警收敛：让通知只落在该落的地方
Nagios 的告警质量取决于三件事：检查是否稳定、状态判定是否合理、通知是否被抑制。很多“告警风暴”并不是监控系统坏了，而是依赖关系没画清楚、重试次数设得太短。
- 用 parents 表达网络拓扑，避免下游主机批量误报
- service dependencies 抑制由上游故障引发的连锁告警
- max_check_attempts 与 retry_interval 配合，过滤瞬时抖动
- 通知时段用 timeperiod 控制，非值班时段只留严重级别
四、与 Prometheus 体系的取舍
在云原生环境里，Prometheus 更擅长处理高基数指标与动态服务发现，而 Nagios 在“黑盒探测 + 状态机 + 通知编排”上依然有它的位置。两者并存时，比较务实的做法是让 Nagios 负责外部可用性探测与业务拨测，把指标类监控交给 Prometheus，再通过统一的告警出口做收敛。
Nagios 适合的场景
外部端口探测、URL 可用性、证书到期、业务拨测等低频但强语义的检查。
Prometheus 适合的场景
容器指标、主机资源、应用埋点等高频、多维度的时序数据采集与查询。
五、常见问题
Q：插件手动执行正常，Nagios 里却报 UNKNOWN？
多半是执行用户、环境变量或路径不一致导致，检查 Nagios 进程的运行用户与插件权限。
Q：主机恢复了但服务状态仍然是 CRITICAL？
确认是否存在 service dependency 或 stale 状态，必要时检查被动检查结果是否及时更新。
Q：通知延迟很高怎么排查？
先看检查间隔与重试次数，再看 notification_interval 与 contact 的 timeperiod 是否覆盖当前时段。