站点运营里有一类问题最难处理：你发现站点打不开，不是从监控，而是从访客留言或客服转达。等有人来告诉你，故障已经持续了一段时间。可用性监控和告警的意义，就是把这个“发现”的动作从人换成机器，让问题在被更多人碰到之前先被记录下来。
先确定要监控哪些地址
只监控首页，只能说明服务器还在，不能说明站点可用。真正值得盯的是用户和蜘蛛都会经过的那几条路径。
- 首页，以及导航或投放中最重要的落地页。
- 主要栏目列表页，以及详情页模板各挑一个代表 URL。
- 登录、提交表单、站内搜索等有交互的入口，至少验证返回状态和关键文本。
- robots.txt 与 XML 站点地图地址，它们出错会直接影响抓取。
挑选时尽量避开每次都会变化的内容页，选相对稳定的地址。否则监控结果里会混进正常的 404，判断故障时反而更费劲。
从站外探测，而不是只看本机
在本机跑一个脚本去请求本机，服务器一宕机，脚本也跟着停了，你收不到任何消息。监控节点至少要放在站点之外，最好有两三个不同位置，避免单个探测点的网络抖动被当成站点故障。
探测内容也不只是状态码。可以顺带检查页面里是否出现预期的标题或某段关键文本，防止出现“返回 200 但内容其实是错误页”的情况。响应时间也值得记录，它能帮你在页面变慢但还没出错时提前发现压力。
告警怎么设置才不吵
告警太频繁，值班的人会开始忽略它，这比没有告警更糟。
- 设置连续失败阈值，比如连续三次探测失败再通知，过滤掉偶发抖动。
- 区分级别：宕机走电话或即时消息，响应变慢走邮件或工作群。
- 通知渠道要有人真正在看，不要发到一个没人回复的群。
- 同一问题在恢复前不要反复轰炸，做告警合并。
5xx 与抓取的关系
蜘蛛来访时遇到 5xx，通常不会立刻把页面从索引里删掉，但如果同一批地址持续返回错误，抓取频率会下降，新内容被发现的时间也会往后拖。反过来，如果只是个别页面报错，影响通常有限。所以监控里最好把 5xx 单独统计出来，看它是集中在一段时间，还是零星分布。
要注意的是，不要为了“让蜘蛛看到正常页面”而把错误页也返回 200。状态码必须和实际情况一致，否则后面排查问题会更难。
一份可执行的自查清单
- 列出五到十个监控地址，覆盖首页、栏目、详情、静态资源和 robots.txt。
- 确认探测点在站点外部，且不止一个位置。
- 检查告警通知的接收人，确认有人在值班时段能响应。
- 设置连续失败阈值和静默期，避免单次抖动触发。
- 写下收到告警后的处理步骤：先看什么、联系谁、要不要回滚。
- 每月回顾一次告警记录，删掉长期误报的规则，补上漏掉的地址。
常见误区
只监控首页、只用 ping 判断可用性、告警发出去没人认领，是三个最常见的坑。ping 通不代表 HTTP 正常，HTTP 200 也不代表页面内容正确。另外，监控本身也会带来请求，如果地址选得太多、频率太高，反而会给服务器增加不必要的负担，选关键路径、拉开间隔就够了。
把它变成例行工作
可用性监控不需要一开始就很完整。先把首页和两三个关键页面接进来，跑上一两周，看告警是否准确，再逐步补充。真正有用的监控，是出问题时你能收到、收到后知道该做什么的那种，而不是仪表盘上好看的一排绿点。