Zabbix 跑起来的利用第一天，我盯着那个绿色的对服 “ZBX” 图标亮起，心里踏实了一半。监控服务器监控这事，管理没它之前全靠 SSH 上去 `top`、利用`df -h` 一条条敲，对服出问题全凭运气发现。监控有了 Zabbix，管理至少 CPU 飙到 90% 的利用时候，手机能先响一声。对服

装 Zabbix 不复杂，监控但坑不少。管理CentOS 上 yum 装 server、利用frontend、对服agent，监控数据库用 MySQL 或者 PostgreSQL 都行。我习惯用 MySQL，导入 schema 那一步记得选对版本——`schema.sql`、`images.sql`、`data.sql` 三个文件按顺序灌进去，漏一个前端就白屏。Web 端配置完 `zabbix.conf.php`，登录进去默认 Admin/zabbix，第一件事改密码，别偷懒。

Agent 端更简单，被监控的机器上装个 `zabbix-agent`，配置文件里改两行：`Server=` 指向 Zabbix Server 的 IP，`Hostname=` 跟 Web 端添加主机时填的名字一致。重启 agent，Web 端 “Configuration → Hosts” 里点 “Add host”，关联模板 `Template OS Linux by Zabbix agent`，等一分钟，绿色 ZBX 亮起来，数据就开始往里灌了。

监控项才是 Zabbix 真正干活的地方。默认模板给了一堆：CPU 负载、内存使用、磁盘空间、网络流量。但默认的磁盘监控只盯挂载点使用率，不盯 inode。我遇到过 `/var` 分区 inode 爆了但空间还剩 40% 的情况，网站直接 500。后来自己加了个 `vfs.fs.inode[/var,pfree]` 的 item，触发器设成低于 20% 告警，再没翻过车。

触发器表达式看着吓人，其实逻辑很直白。比如 “CPU 负载持续 5 分钟超过 4”：
{ Host:system.cpu.load[percpu,avg1].avg(5m)}>4
`avg(5m)` 就是取 5 分钟平均值，避免秒级毛刺疯狂报警。严重程度分信息、警告、一般严重、严重、灾难，我一般把磁盘空间低于 10% 设成 “严重”，CPU 高负载设成 “警告”——半夜被吵醒和早上起来看一眼，区别很大。

告警媒介得配。Email 最稳，但国内服务器发邮件经常被拒。我后来用企业微信机器人，Zabbix 里写个 shell 脚本，`curl` 往 webhook 推 JSON，群里直接 @所有人。脚本里判断一下 `$1` 是 “PROBLEM” 还是 “RESOLVED”，消息颜色不一样，一眼能分清是出事还是恢复了。

数据存多久是个现实问题。默认 history 存 90 天，trend 存 365 天。磁盘不够就调小，但别低于 7 天，不然排查问题没依据。我见过有人把 history 设成 1 天，结果周末磁盘满了他周一才发现，日志早没了。Housekeeper 记得开，不然数据库膨胀到几十 G，备份都头疼。

Zabbix 不是装完就完事。模板要改，触发器要调，告警要压。我现在的做法是：新加一台机器，先挂默认模板跑一周，看基线数据，再根据实际业务调阈值。数据库服务器和前端服务器的 CPU 告警线肯定不一样，一刀切就是给自己找麻烦。

它不完美。Web 界面偶尔卡，API 文档写得像天书，自动发现有时候抽风。但比起自己写脚本轮询、自己画图、自己发邮件，Zabbix 至少把 80% 的重复劳动省了。剩下 20%，写写自定义脚本、调调 SQL，也就补上了。