Linux 系统运维工程师必备工具箱(第19篇)之监控工具对比:Zabbix vs Prometheus vs Nagios

初识Nagios：老牌劲旅的“爱恨情仇”

我的第一份运维工作，公司用的就是Nagios。那时候觉得它设置起来真叫一个“硬核”。记得第一次设置主机监控，需要手动编辑/etc/nagios/objects/hosts.cfg和services.cfg。比如监控一台Web服务器的80端口：

define host{
    use             linux-server
    host_name       web-server-01
    alias           Web Server 01
    address         192.168.1.10
}

define service{
    use                 generic-service
    host_name           web-server-01
    service_description HTTP Check
    check_command       check_http!-H 192.168.1.10 -p 80
    check_interval      5
    retry_interval      1
    max_check_attempts  3
}

设置完还要执行nagios -v /etc/nagios/nagios.cfg验证语法。最让人崩溃的是，Nagios的插件生态虽然丰富，但每个插件都要单独下载编译。有一次监控MySQL，我折腾了整整一个下午才让check_mysql插件跑起来。

排坑经验：Nagios的告警设置非常灵活，但它的“单点故障”问题很突出。一旦Nagios主进程挂了，整个监控就瘫痪了。后来我们引入了nagios3的分布式架构，用nsca被动模式把数据推送到中心节点，才算解决了这个问题。

拥抱Zabbix：从“手动挡”到“自动挡”

后来公司业务扩张，Nagios的设置维护成本越来越高。我们决定迁移到Zabbix。第一次接触Zabbix时，我被它的Web界面惊艳到了——终于不用天天对着设置文件了。

Zabbix的自动发现功能简直是运维福音。设置一个网络发现规则：

# 在Zabbix Server上设置自动发现
zabbix_get -s 192.168.1.10 -k system.hostname

然后通过Web界面创建“Discovery rule”，指定IP段和端口范围，Zabbix就能自动把新服务器加入监控。我至今记得第一次看到Zabbix自动发现并添加了50台服务器的场景，那种感觉就像从手动挡换到了自动挡。

排坑经验：Zabbix的数据库是它的“阿喀琉斯之踵”。有一次我们监控了2000台服务器，MySQL的history表涨到了200GB，查询变得极其缓慢。解决方案是开启Zabbix的“分区表”功能：

-- 在Zabbix数据库执行
ALTER TABLE history PARTITION BY RANGE (clock) (
    PARTITION p202301 VALUES LESS THAN (UNIX_TIMESTAMP('2023-02-01')),
    PARTITION p202302 VALUES LESS THAN (UNIX_TIMESTAMP('2023-03-01'))
);

同时调整Housekeeping的保留策略，把历史数据保留时间从90天降到30天，性能立刻提升。

转向Prometheus：云原生时代的“新宠”

随着公司业务全面容器化，传统的监控方案开始力不从心。这时Prometheus进入了我们的视野。第一次搭建Prometheus时，我被它的“拉模式”和“多维数据模型”深深吸引。

搭建Prometheus的设置文件prometheus.yml：

global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: 'kubernetes-pods'
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_label_app]
        action: keep
        regex: my-app

配合Grafana，我们实现了“秒级”的实时监控。记得有一次线上服务抖动，Prometheus的rate函数帮我们快速定位到了某个Pod的CPU使用率异常：

rate(container_cpu_usage_seconds_total{namespace="production"}[5m]) > 0.8

排坑经验：Prometheus的“拉模式”在监控大规模集群时，会面临“数据孤岛”问题。我们使用Thanos组件实现了全局视图：

# 搭建Thanos Sidecar
thanos sidecar \
    --tsdb.path /prometheus \
    --prometheus.url http://localhost:9090 \
    --objstore.config-file /etc/thanos/object-store.yaml

这样即使某个Prometheus实例挂了，历史数据依然可以从对象存储中恢复。

三者的“终极对决”

在实际交付中，我总结了一个简单的选型原则：

• Nagios：适合小型环境（<100台服务器），团队有Shell脚本能力，需要高度定制化监控的场景。
• Zabbix：适合中型环境（100-1000台服务器），需要企业级功能（如报表、SLA）的场景。
• Prometheus：适合云原生环境（Kubernetes、微服务），需要动态发现和时序数据分析的场景。
  

最后的“真心话”

监控工具没有“最好”，只有“最合适”。我见过用Zabbix监控Kubernetes集群的“四不像”方案，也见过用Prometheus监控传统物理机的“大炮打蚊子”设置。作为SRE，我们的核心能力不是“会用某个工具”，而是“理解业务需求，选择最合适的方案”。

希望我的这些“踩坑”经验，能帮大家在监控选型的路上少走一些弯路。记住：工具是死的，人是活的。把工具用对地方，才是真正的运维高手。

👨‍💻 运维老兵经验：根据实际生产环境，以上步骤建议先在测试环境验证，并做好备份。参数值需根据服务器设置调整，不要盲目照搬。