站点出故障，最怕的不是故障本身，而是几个小时过去了，运营和运维都还不知情。监控与告警做扎实，出问题能第一时间发现，恢复之后也有数据可以复盘。下面这份自查清单不涉及具体工具选型，只讲清楚“监控什么、怎么告警、容易踩哪些坑”。
一、先确认监控覆盖了哪些层
只监控首页能不能打开是不够的。域名、证书、页面、接口、服务器资源，每一层都可能单独出问题，而任何一层掉线，访客看到的都是同一个结果——站点不能用了。
- 域名与 DNS：解析是否正常、TTL 设置是否合理、解析记录有没有被改成错误的 IP。
- HTTPS 证书：到期时间建议提前 30 天告警，中间证书同样要检查，别只盯着主证书。
- HTTP 层：状态码、响应时间、首字节时间。列表页、详情页、搜索结果页这些关键路径单独配置，不要只测首页。
- 页面内容：状态码 200 不代表页面正常，可以在探测时校验页面是否包含某个特征词，防止“空白 200”或报错页被当成正常页面。
- 核心接口与后台任务：登录、提交、站内搜索、定时任务以及队列积压情况。
- 服务器资源：CPU、内存、磁盘使用率、数据库连接数。磁盘不要等到 95% 才告警，按增长速度留出处理时间。
二、探测频率和探测点要克制
监控本身也是一种流量。探测频率过高、探测点过多，源站出问题时反而更容易被压垮。
- 关键页面 1 到 5 分钟探测一次通常够用，非关键页面可以放宽到 10 分钟以上。
- 多地探测适合判断是不是局部网络问题，但要注意所有探测点同时打过来会形成小规模压力。
- 给监控请求设置固定的 User-Agent 和来源 IP，方便在日志里区分，必要时在限流规则里放行。
- 确认监控请求不会被当成异常爬虫拦截，也不会进入统计口径，污染正常的访问数据。
三、告警策略决定你会不会去看告警
告警最大的问题往往不是太少，而是太多。一个每次都响、响完发现没事的渠道，很快就会没人看。所以阈值、持续时间、通知对象都要提前设计。
- 分级：会影响访客访问的走电话或即时通讯，性能轻微波动走邮件或日报。
- 持续时间：连续 2 到 3 次探测失败再告警，避免一次网络抖动就把人叫起来。
- 收敛：同一问题短时间内只发一条，恢复时再补一条恢复通知。
- 静默期：计划内的维护、发版、迁移提前设置静默，否则告警风暴会让你错过真正的问题。
- 值班与升级：明确第一联系人，多久没响应就升级给第二个人。
四、几个常见误区
- 只监控首页，某个栏目或功能挂了完全不知道。
- 只看状态码，不看响应内容和响应时间，页面慢到十几秒也算“正常”。
- 所有告警发到同一个群，重要信息被日常噪声淹没。
- 没有历史数据，出问题后只能凭印象判断“以前是不是也这样”。
- 监控配置改过之后没人复核，某个页面早就下架了，监控还在一直告警。
五、可以照着做的落地清单
- 列出站点最关键的 5 到 10 个页面和接口，逐个加入监控。
- 为证书、域名、磁盘设置到期和容量类提醒。
- 确认探测频率、探测点数量和来源标识是否合理。
- 给告警分级，指定接收人和升级路径。
- 维护、发版前设置静默，结束后复核告警是否恢复正常。
- 每季度回顾一次告警记录，把长期误报的规则调整或删掉。
监控的意义不是让告警响个不停，而是让真正的问题在你收到用户反馈之前就浮出来。
把这几项过一遍，通常能发现一些早就该修但一直没人注意的空当。监控配置不需要一次做到完美，先覆盖关键路径，再逐步补齐，比一步到位更现实。