站点运营里有一类工作很容易被忽略：不是把站点建好，而是确认它一直活着。很多团队直到用户投诉、或者发现蜘蛛抓取量断崖式下滑，才回头去查服务器——这时候故障可能已经持续了几个小时。监控与告警要做的事，就是把“发现问题”从被动变成主动。
先明确要监控什么
监控不是指标越多越好，而是覆盖住那些一旦异常就会影响用户和蜘蛛的关键点。
- 可用性：首页、核心栏目页、重要内容页能否正常返回 200，不同地区节点结果是否一致。
- 响应时间：TTFB、完整页面加载耗时、数据库查询耗时，重点看是否在缓慢劣化。
- 错误率：5xx 占比、超时次数、连接被拒的次数，短时间内的尖峰尤其要关注。
- 抓取侧信号：蜘蛛请求量、抓取时返回的状态码分布、抓取超时比例，这些是站点健康度在外部的间接反映。
- 资源水位：磁盘、内存、CPU、数据库连接数、带宽使用量，配合日志轮转一起看。
- 到期类事项：HTTPS 证书剩余天数、域名有效期、CDN 与第三方服务的配额。
告警怎么设才不会被忽略
阈值加持续时长
只看单次探测结果很容易误报，网络抖动、CDN 边缘节点偶发异常都会触发。比较实用的做法是阈值加持续时长：例如连续 3 次探测失败，或 5 分钟内 5xx 比例超过设定值时才告警。这样既不会漏掉真实故障，也不会让值班的人对通知麻木。
分级与通知渠道
- 站点完全不可用、证书即将过期——电话或短信，必须有人立刻处理。
- 响应时间明显变慢、错误率上升——即时通讯群通知，工作时间内处理。
- 资源水位缓慢上涨、周度趋势变化——日报或周报，排进例行工作。
同时要给每条告警指定责任人，否则群里消息刷屏但没人动手是常态。
避免噪声淹没真问题
计划内的维护、发布、压测要提前设置静默窗口；同一故障的重复告警要合并；已经处理完的告警要有明确的关闭记录，否则下一次遇到同样的问题还是从头排查。
定期自查清单
- 监控覆盖的 URL 清单是否跟着改版更新过？改版后旧探针可能一直失败，持续占用注意力。
- 探针是否被 WAF、CDN 或风控当成异常请求拦截，从而制造“站点挂了”的假象？
- 告警接收人里是否还有已经离职或调岗的同事？通知发不出去等于没有监控。
- 是否只盯着首页，忽略了子域名、重要内容目录、接口和静态资源？
- 监控指标和访问日志能否对得上？两边数据长期背离，说明有一方口径错了。
- 每次真实故障后，是否记录了发生时间、影响范围、处理动作和改进项？
监控的价值不在于仪表盘好看，而在于故障发生时，你是第一个知道的人，而不是最后一个。
不需要一次把所有指标补齐。先把可用性和证书到期这两件事盯住，再逐步加上响应时间、错误率和抓取信号，配合一份能落地的处理记录，站点运营的稳定性会明显可控一些。