nagios配置怎么做，nagios监控系统配置教程

Nagios 配置的核心结论是：想要让监控系统真正发挥作用，关键在于将配置从“被动写文件”转变为“主动定义监控逻辑”，Nagios 本身不监控任何东西，它只是调度引擎，所有能力都来自对象定义、插件和告警策略的组合，配置越清晰，后期维护成本越低，故障响应越及时，本文将从对象模型、资源规划、配置实战、性能优化四个维度，结合酷番云云服务器的实际使用经验，给出可直接落地的配置方案。

理解 Nagios 的配置本质

Nagios 通过 4 类核心对象 完成监控闭环：主机（host）、服务（service）、命令（command）、联系人（contact），所有配置文件的编写，本质是定义这些对象之间的关系，新手最常见的错误是试图在单个 nagios.cfg 中堆砌所有内容，这会导致维护灾难。

建议的目录结构 是：

• /usr/local/nagios/etc/objects/ 下按功能拆分：hosts.cfg、services.cfg、commands.cfg、contacts.cfg
• 使用 cfg_file 或 cfg_dir 指令在 nagios.cfg 中引用
• 对大型环境,使用 _templates.cfg 定义模板，实现继承复用

核心配置文件详解

主配置文件 nagios.cfg

关键参数必须谨慎设置：

• admin_email：接收告警的核心邮箱
• check_result_reaper_frequency：检查结果回收频率，默认 10 秒，生产环境可调至 5 秒
• max_check_result_file_age：过期结果清理时间，建议 86400 秒
• enable_environment_macros：设为 1 允许宏传递，但会加大资源消耗，非必要不开启

资源文件 resource.cfg

用于定义变量,最常见的用途是设置私有命令路径：

$USER1$=/usr/local/nagios/libexec
$USER2$=/opt/mysql_socket

在命令定义中使用

$USER1$/check_ping 这样的写法，能避免硬编码路径，提升脚本迁移效率。

对象定义模板

模板是配置维护的利器,例如先定义一个通用主机模板：

define host {
    name                            generic-host
    check_command                   check-host-alive
    max_check_attempts              3
    check_period                    24x7
    notification_period             24x7
    contact_groups                   admins
    register                        0
}

所有真实主机只需继承该模板,并覆盖 IP 地址与别名即可。

业务级监控配置实战

场景：监控一台 Web 服务器的 80 端口和磁盘利用率

命令定义（commands.cfg）：

define command {
    command_name    check_tcp_port
    command_line    $USER1$/check_tcp -H $HOSTADDRESS$ -p $ARG1$
}
define command {
    command_name    check_disk_root
    command_line    $USER1$/check_disk -w $ARG1$ -c $ARG2$ -p /
}

主机定义（hosts.cfg）：

define host {
    use                 generic-host
    host_name           web-01
    alias               Production Web Server
    address             192.168.1.10
}

服务定义（services.cfg）：

define service {
    use                 generic-service
    host_name           web-01
    service_description HTTP Port
    check_command       check_tcp_port!80
}
define service {
    use                 generic-service
    host_name           web-01
    service_description Root Disk Usage
    check_command       check_disk_root!20%!10%
}

关键经验：服务中的 符号用于向命令传参，参数顺序必须与 command_line 中的 $ARG1$、$ARG2$ 一一对应，很多配置失效问题都源于参数顺序颠倒。

告警通知策略优化

默认的告警机制往往会在大故障时造成“通知风暴”，专业配置必须控制三要素：

• 

  notification_interval 重通知间隔，默认 60 分钟，建议核心业务改为 30 分钟

• max_check_attempts 连续失败多少次后才生成告警，建议服务器设为 3，避免临时网络抖动产生噪音
• notification_options 定义什么样的事件才通知，c,r 表示仅恢复和 PROBLEM 状态

个性化联系人 可针对不同层级接收不同告警：技术人员接收全部，业务人员仅接收服务不可用，联系人通过 contactgroups 关联主机或服务，实现权限隔离。

性能优化与常见坑

当监控节点超过 500 台时，默认配置会出现检查延迟。核心解法是开启被动检查与设置异步检查。

• 被动检查：在外部脚本通过 send_nsca 推送结果，NRDS 架构下服务端无需主动 SSH，大幅降低负载
• use_aggressive_host_checking 在服务故障时快速判断主机状态，避免 SEQUENTIAL 检查阻塞队列
• 将 check_interval 从默认 5 分钟拉长到 10 分钟，配合异常时自动降级（flap_detection 开启），能减少无效探测

还有一个容易被忽略的坑：系统时间漂移，Nagios 对不同主机进行并行检查时，依赖本地时间戳，你必须部署 NTP 统一时间，否则服务状态会频繁误报。

酷番云经验案例

我们在酷番云上部署 Nagios 时，遇到一个实际场景：客户有 30 台云服务器承担 Web 和数据库业务，最初配置了 150 个服务检查，但每次发布代码时都会产生大量连接超时告警，后来分析出原因是云服务器默认带宽上限戳穿了 ICMP 丢包阈值。

我们给出的方案是：

• 调整 check_ping 参数，将 -w 3000.0,80% -c 5000.0,100% 放宽为 -w 5000.0,90% -c 7000.0,100%
• 对 MySQL 服务检查改为通过 酷番云内网 IP 的端口探测，避开公网带宽波动



• 将主机和服务模板中默认的 max_check_attempts 从 3 提升到 5，配合 notification_interval 从 60 减到 30

最终告警噪音减少了 80%，而真实故障仍然能在 15 秒内触发通知。这验证了一个观点：Nagios 配置不是机械写文件，而是需要结合基础资源特性进行调优。

长期维护与配置管理

• 使用版本控制：将整个 /usr/local/nagios/etc 纳入 Git，每次变更均可回滚
• 自动化校验：加入 CI 流程，执行 nagios -v /usr/local/nagios/etc/nagios.cfg 验证配置再发布
• 监控配置本身：通过 check_file_age 检查配置文件是否被意外修改，确保安全合规

相关问答模块

问题1：Nagios 配置完成后，无法在 Web 界面看到主机，最可能的原因是什么？

答：最常见的三个原因，第一，nagios.cfg 中未配置 cfg_file 或 cfg_dir 引用，你写了新文件但主配置不知道，第二，对象没有正确设置 register 值，模板定义需要 register 0，普通对象不能为 0，第三，配置语法通过了，但 Web 服务权限错误，检查 /usr/local/nagios/var/rw/nagios.cmd 文件属主是否为 nagios 用户，同时开启 check_external_commands=1，建议用 nagios -v 命令先做全量校验，再逐步排查。

问题2：Nagios 一直发送重复告警，如何合理抑制？

答：关键在于理解 max_check_attempts 和 notification_interval 的作用。max_check_attempts 是告警前的连续失败次数，设置大一点（如 5）可以过滤瞬时故障。notification_interval 控制告警发送后的重复频率，设为 0 表示只发一次，适合非关键业务，可以为不同时段的告警设置不同的 notification_period，例如夜间只发送给值班人员，也能减少不必要的打扰。