凌晨两点，监控Nagios 的系统告警短信把我吵醒。一台 Nginx 服务器的监控 443 端口响应时间从 80ms 飙到 3.2 秒。爬起来连上 VPN，系统查了十分钟，监控发现是系统某个上游接口在疯狂重试，把连接池占满了。监控这种事儿，系统没监控你根本不知道——用户只会觉得“网站又卡了”，监控然后默默离开。系统

Web 服务器监控系统说白了就干三件事：盯着服务器别挂、监控盯着服务别慢、系统盯着流量别乱。监控但真做起来，系统坑比想象的监控多。

先搞清楚你要监控什么

很多人上来就装 Zabbix，配一堆模板，结果 CPU 报警阈值设成 90%，内存报警设成 95%。这跟没设一样——等你收到告警，服务早挂了。我的经验是：CPU 持续 5 分钟超过 70% 就该看一眼，内存使用率超过 80% 就得查，磁盘空间低于 20% 必须处理。这些数字不是拍脑袋，是看你业务的实际水位线。比如跑 Java 应用的机器，堆内存本来就吃得多，你按 80% 报，一天能收几百条。

端口监控更直接。HTTP/HTTPS 端口用 curl 或 requests 定时探测，返回码不是 200 就报警。但别只探首页——首页可能是静态缓存，真正的业务接口挂了它照样返回 200。我习惯在监控脚本里带一个业务相关的 URL，比如 /api/health，让它真正走一遍数据库查询。这样探到的才是真实可用性。

日志和指标，两条腿走路

指标告诉你“慢了”，日志告诉你“为什么慢”。Prometheus 抓取 Nginx 的 stub_status，能看到活跃连接数、请求速率。但光看这些不够。有一次 QPS 正常，但 5xx 错误率悄悄涨到 3%，查 Nginx 的 error.log 才发现是后端 PHP-FPM 进程池满了。所以指标和日志得对着看。

ELK 那套太重？那就用 Loki + Promtail，轻量，跟 Grafana 集成也好。关键是把 Nginx 的 access log 里的 upstream_response_time 提取出来做聚合。P99 超过 1 秒就值得警惕。别只看平均值——平均值 200ms 可能掩盖了 5% 的请求在 5 秒以上。

告警别太吵，也别太安静

告警疲劳是监控系统最大的敌人。我见过一个团队，钉钉群里每分钟都有告警，最后没人看了。解决办法：分级。P0 打电话，P1 发短信，P2 发邮件或 IM。P0 只留给“服务完全不可用”这种级别。另外，加个抑制规则：如果一台机器宕机了，别再报它上面的所有服务端口不可达——那是噪音。

还有，告警要带上下文。别只发“CPU 高”，要发“web-03 CPU 92%，持续 8 分钟，当前负载 12.4，主要进程 php-fpm 占用 780%”。这样收到告警的人不用登录机器就能判断个大概。

自建还是买服务

小团队，直接用 UptimeRobot 或阿里云监控，免费额度够用。机器超过 20 台，或者有自定义指标需求，自建 Prometheus + Grafana + Alertmanager 更灵活。但别为了监控而监控——我见过有人用 Ansible 批量部署了 15 个监控组件，结果监控系统自己先挂了，没人知道。

最后说个实在的：监控系统本身也要被监控。Prometheus 的 scrape 间隔、Alertmanager 的静默规则、Grafana 的数据源，这些都得有健康检查。否则你以为是服务器挂了，其实是监控瞎了。