内容摘要：凌晨三点，Nagios 的告警短信把我吵醒了。一台跑了三年多的 Nginx 服务器响应时间突然从 80ms 飙到 2.3 秒。爬起来连上 VPN 一看，后端一台应用服务器内存泄漏，把 swap 吃光了

凌晨三点，监控Nagios 的工具告警短信把我吵醒了。一台跑了三年多的监控 Nginx 服务器响应时间突然从 80ms 飙到 2.3 秒。爬起来连上 VPN 一看，工具后端一台应用服务器内存泄漏，监控把 swap 吃光了。工具这种事一年总会碰上几回，监控如果没有监控工具，工具等用户打电话来投诉，监控损失就不是工具一星半点了。

Web 服务器监控到底在监什么？监控说白了就几个维度：能不能连上（存活）、响应快不快（性能）、工具资源够不够（容量）、监控出错没有（日志与状态码）。工具听起来简单，监控但真要做到位，选型和配置上的坑不少。

先搞清楚你要监控的层次

很多人一上来就装 Prometheus + Grafana 全家桶，结果发现根本用不上那么复杂的东西。我见过一个小团队，三台 Web 服务器，非要搞一套完整的可观测性平台，光是维护监控系统本身的人力就超过维护业务的时间。

实际情况是：如果你只有几台机器，uptime、curl -o /dev/null -s -w '%{ http_code} %{ time_total}' 加上一个定时脚本，再配个邮件通知，基本够用。机器多了、服务拆细了，才需要考虑 Zabbix、Prometheus 这类正经的监控系统。

层次上分三块。最外层是黑盒监控——从用户视角发请求，看能不能通、多快返回。这一层用外部服务做最靠谱，因为你自己机房断了你也不知道。中间层是白盒监控——服务器上的 agent 采集 CPU、内存、磁盘 IO、连接数这些指标。最底层是日志监控——Nginx 的 error.log、access.log 里的 5xx 比例，这些数据往往比指标更早暴露问题。

几个容易踩的坑

第一个坑：只监控不告警，或者告警太吵。我见过一个配置，磁盘使用率超过 70% 就发邮件，结果运维把邮件规则全设成已读，真出事的时候没人看。阈值要分层，80% 警告、90% 严重、95% 打电话，这样才有区分度。

第二个坑：监控指标太粗。比如只看 CPU 总使用率，不看 load average 和 iowait。有次一台服务器 CPU 使用率只有 30%，但 load 到了 16，原因是大量进程卡在磁盘 IO 上。只看 CPU 根本发现不了。

第三个坑：忽略证书和域名过期。这两种故障每年都能干掉一批网站，而且完全可以在监控里提前 30 天告警。用 openssl s_client 或者专门的证书监控脚本，几分钟的事。

工具选型：别追新，追合适

Zabbix 老牌，功能全，适合传统运维团队，缺点是界面丑、配置复杂。Prometheus 是云原生时代的标配，拉模型、时序数据库、PromQL 查询灵活，但存储和长期保留需要额外方案。Netdata 单机监控体验极好，开箱即用，秒级精度，但不适合大规模集群。

我个人的组合是：Prometheus + node_exporter + blackbox_exporter 做指标和探活，Alertmanager 做告警路由，Grafana 看板。日志用 Loki，轻量，跟 Prometheus 一套查询语法。这套下来，五到五十台服务器的规模都能扛住，再大就得考虑 Thanos 或 VictoriaMetrics 做长期存储了。

监控之外的事

工具只是手段。真正决定监控有没有用的，是你能不能根据告警快速定位问题。我习惯在告警消息里直接附上排查命令和相关看板链接，比如“CPU iowait 超过 40%，请检查 iostat -x 1 输出，看板地址：xxx”。这样半夜被叫醒的人不用先翻文档再动手。

还有一点，监控系统本身也要被监控。Prometheus 挂了、Alertmanager 没发出去消息，这种事不是没发生过。用一个独立的外部探针，每分钟请求一次监控系统的健康接口，比什么都实在。

说到底，Web 服务器监控不是装个软件就完事。它是一套从采集、存储、告警到响应的完整流程。工具选对了省心，选错了添乱。花时间想清楚自己到底要监控什么、告警发给谁、收到之后怎么办，比折腾工具本身重要得多。