Linux 系统资源监控与告警：Zabbix、Nagios 与 Prometheus 告警配置

1. 从凌晨三点值班电话说起

"王工！数据库服务器CPU飙到200%了！"接到值班电话的瞬间，你像消防员听到警报般从床上弹起。这样的深夜惊魂，正是今天我们要解决的痛点——如何构建智能的监控告警系统，让告警信息既不会"狼来了"，又能在真正危险时准时送达？

2. Zabbix：企业级监控的瑞士军刀

2.1 典型配置示例

（技术栈：Zabbix 6.0 + SMTP邮件通知）

# /etc/zabbix/zabbix_server.conf 关键配置
AlertScriptsPath=/usr/lib/zabbix/alertscripts  # 告警脚本存放目录
StartAlerters=5  # 并发告警处理进程数

# 创建邮件告警脚本
cat > /usr/lib/zabbix/alertscripts/send_email.sh <<'EOF'
#!/bin/bash
to=$1
subject=$2
body=$3
echo -e "To: ${to}\nSubject: [ZABBIX] ${subject}\n\n${body}" | sendmail -t
EOF
chmod +x /usr/lib/zabbix/alertscripts/send_email.sh

# Web界面配置步骤：
1. 进入"管理"-"报警媒介类型"
2. 创建名为"Email-Alert"的媒介类型
3. 脚本名称填写send_email.sh
4. 参数配置：{ALERT.SENDTO}、{ALERT.SUBJECT}、{ALERT.MESSAGE}

2.2 告警升级策略配置

# 在触发器配置中设置多级通知：
触发器表达式: system.cpu.load[all,avg5] > 5
   → 默认严重级别: 一般
   → 关联动作：
     1级告警（持续5分钟）→ 邮件通知运维组
     2级告警（持续15分钟）→ 短信通知值班工程师
     3级告警（持续30分钟）→ 电话通知技术主管

3. Nagios：经典永不褪色

3.1 基础告警配置

（技术栈：Nagios Core 4.4 + NRPE）

# /usr/local/nagios/etc/objects/commands.cfg
define command{
    command_name    check_nrpe_disk
    command_line    $USER1$/check_nrpe -H $HOSTADDRESS$ -c check_disk -a '-w 20% -c 10% -p /'
}

# /usr/local/nagios/etc/objects/hosts.cfg
define service{
    use                     generic-service
    host_name               web-server-01
    service_description     Disk Usage
    check_command           check_nrpe_disk
    contacts                ops-team
    notification_interval   30     # 重发告警间隔（分钟）
    max_check_attempts      3      # 连续异常次数超过阈值才告警
}

3.2 防止"告警轰炸"的秘籍

# 时间段定义（避免深夜发送非紧急告警）
define timeperiod{
    timeperiod_name  work-hours
    alias           Normal Work Hours
    monday          09:00-18:00
    tuesday         09:00-18:00
    wednesday       09:00-18:00
    thursday        09:00-18:00
    friday          09:00-18:00
}

# 在服务定义中增加：
    notification_period      work-hours
    notification_options     w,u,c,r  # 仅警告、未知、严重、恢复时通知

4. Prometheus：云原生时代的监控新贵

4.1 完整的告警规则配置

（技术栈：Prometheus 2.40 + Alertmanager）

# prometheus/rules/node_alerts.yml
groups:
- name: host-alerts
  rules:
  - alert: HighCpuLoad
    expr: 100 * (1 - avg by(instance)(rate(node_cpu_seconds_total{mode="idle"}[5m]))) > 85
    for: 10m
    labels:
      severity: critical
    annotations:
      summary: "{{ $labels.instance }} CPU负载过高"
      description: "实例 {{ $labels.instance }} 的5分钟平均CPU使用率已达{{ $value }}%"

# alertmanager/config.yml
route:
  receiver: default-receiver
  group_by: [alertname, cluster]
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h

receivers:
- name: default-receiver
  webhook_configs:
  - url: http://alert-gateway:9095/webhook
    send_resolved: true

4.2 告警路由的"智能过滤"

# 分级路由配置示例
route:
  receiver: 'slack-general'
  routes:
  - match_re:
      severity: ^(critical|disaster)$
    receiver: 'sms-pager'
  - match:
      team: db
    receiver: 'webhook-dba-team'
    continue: true

5. 三大工具全方位PK

5.1 应用场景选择指南

• Zabbix：需要传统IT设施的全面监控
• Nagios：轻量化基础设施监控需求
• Prometheus：K8s等云原生环境监控

5.2 功能对比表

6. 血泪经验总结

6.1 防坑指南

• Zabbix触发器表达式务必测试边界值
• Nagios的check_interval必须大于检测超时时间
• Prometheus的for持续时间要大于采集间隔
• 所有告警必须设置抑制规则（Mute）

6.2 最佳实践路线图

graph TD
    A[确定监控范围] --> B[选择监控指标]
    B --> C{基础设施类型}
    C -->|传统服务器|D[Zabbix]
    C -->|混合云环境|E[Prometheus]
    C -->|轻量级设备|F[Nagios]
    D --> G[配置自动发现]
    E --> H[使用ServiceMonitor]
    F --> I[自定义插件]
    G --> J[分级告警策略]
    H --> J
    I --> J