Zabbix与Prometheus在Linux的安装与采集实战指南

52JinY 助手

这两年在中小团队里落地监控，我最常被问到的问题就是：Linux 上到底该选 Zabbix 还是 Prometheus？我踩过的坑不少，正好借这个帖子把安装与采集配置的关键点梳理清楚，顺带聊聊各自适用场景与组合玩法。

先说 Zabbix。它的优势是“开箱即用”，自带前端、告警、发现规则和模板，适合想快速覆盖全栈

监控。安装上，CentOS/RHEL 系列直接用官方仓库装 zabbix-server、zabbix-web、zabbix-agent2，MySQL/PG 随你选；Debian/Ubuntu 也有 apt 源。新手容易忽略两点：一是时区与 PHP 的时区没对齐，前端会各种时间错位；二是历史/趋势表没做分区，几个月后表膨胀到跑不动。生产上我会一开始就用 TimescaleDB 或 MySQL 分区，把 history_uint/history/log 做好保留策略，7~14 天历史配合 90 天趋势就够多数业务用。

采集配置方面，Agent2 的插件生态比老 Agent 丰富，Linux 基础指标基本模板套上就能跑：CPU、内存、Load、磁盘、网卡、进程存活、端口监听。服务层我更推荐走主动模式（active checks）加 Proxy 扇出，尤其多机房/内网复杂的场景，省心且减少防火墙打洞。自动发现（LLD）要学会“限流”：文件系统、网卡、Docker 容器一旦无脑全开，低配机房就会被采集风暴拖慢。阈值策略也别迷信默认模板，我通常按业务节律改：CPU 短抖不告警，Load 连续 5 分钟超核数才拉；磁盘用 iowait 和队列深度做并行判断，误报会少很多。

再看 Prometheus。它的优势是拉取模型+时序数据库一体化，生态围绕 Exporter 和服务发现，K8s 里简直原生公民。Linux 主机装 node_exporter 是起点，生产别忘了启用 textfile collector，用 cron 写入自定义业务指标，很灵。配置上，prometheus.yml 先分 job：node、process、blackbox、mysqld 等，再用 relabel_keep 丢弃噪声标签，避免高基数。Retention 别贪长，单机 15～30 天是甜点区，长期就走远端存储：Thanos/Cortex/Mimir；我个人偏 Thanos，组件直观，Sidecar 接 Prom 本地再聚合，查询体验稳定。

告警链路上，Alertmanager 是 Prom 的灵魂。路由要围绕“业务-环境-严重级别”三维设计，group_by 控制批量合并，inhibit 规则屏蔽连带噪声（例如主机 down 时抑制该主机上的进程告警）。模板里把 runbook 链接、影响面、自愈建议写清楚，夜间少被电话吵醒是真生产力。Grafana 出图时，面板变量控制在 2～3 个以内，标签炸裂会让查询成本直线上升；Recording rules 预计算复杂表达式，别让每个图都现算。

选型与组合是门学问。单体或小规模物理/虚机，团队以运维为主、要快速落地与统一告警，Zabbix 上手快、心智负担低；云原生或对指标维度、临时实例多的环境，Prom 更顺手。混合方案也很常见：Zabbix 做“资产+可用性+传统告警”，Prometheus 做“高维度指标与趋势”，Grafana 统一大屏，告警最终都汇到企业 IM。想打通两边数据，可以用 zabbix_exporter 暴露 Zabbix 指标给 Prom，或用 webhook 把 Alertmanager 的事件投递到 Zabbix 事件中心，谁主谁辅看团队技能栈。

最后几条踩坑清单：不管哪套，先算采集频率×指标量×实例数，预估写入与存储；给采集进程单独的 cgroup/系统用户，避免被 OOM 连坐；NTP 校时必须硬性要求，时序错一分种，排障多半翻车；从“少而准”的告警起步，每周回顾一次噪声，迭代三周后再扩面。监控不是一次性工程，是和业务一起演进的系统。选你团队能养得起的，而不是看上去最酷的。