很多站点的问题不是没人发现，而是发现得太晚：访客打不开页面，先在群里问一句；搜索蜘蛛抓取失败，等到下次翻日志才知道。可用性监控的价值，就是在访客和蜘蛛之前先发现问题，把“是不是又挂了”变成“什么时候挂的、挂了多久、影响了哪些地址”。
先想清楚监控什么
监控不是越多越好。指标堆得太杂，告警就会变成噪音，最后没人看。建议先围绕三类目标选点：入口可达、核心内容可达、关键链路可达。
入口与核心页面
- 首页、主要栏目页、几个有代表性的内容页。
- 登录、注册、下单、留言等关键入口（如果站点有）。
- XML 站点地图地址，确认蜘蛛拿到的是正常响应而不是 500。
依赖项与外部条件
- 数据库、缓存、对象存储等内部依赖的响应情况。
- 证书有效期、域名解析是否正常。
- CDN 回源是否成功，边缘节点是否返回异常状态码。
监控地址要选稳定的、不含随机参数的 URL。用带会话或带筛选参数的地址做监控，很容易把正常的参数差异误判成故障。
监控方式与频率
常见做法有两层：外部探测（从机房或云节点请求页面，看状态码和响应时间）与内部自检（应用端定时写心跳、统计错误日志）。外部探测贴近真实访客视角，内部自检更容易定位到具体模块，两者结合更实用。
- 频率：核心入口 1 分钟一次，普通页面 5 到 10 分钟一次即可。
- 判定：不要只看状态码，配合响应体关键字、响应时间阈值一起判断。
- 多点：至少两个不同网络位置的探测点，避免单点网络抖动造成误报。
自查清单
- 列出必须保证可用的地址清单，标注优先级。
- 确认监控地址在 robots.txt 允许范围内，且不会产生副作用（比如触发写操作）。
- 检查探测请求是否带上了合适的 UA 与 Header，避免被安全策略当成异常流量拦下。
- 设置告警阈值和静默期，避免同一故障反复轰炸。
- 确认告警能真正到达负责人，别只发到一个没人看的邮箱。
- 为每次故障记录开始时间、恢复时间、影响范围。
- 定期回顾误报，把无意义的告警规则删掉或调松。
和抓取、运营的关系
搜索蜘蛛的抓取结果，可以当作一种“延迟的可用性反馈”：如果日志里某些地址长期返回 5xx、超时或响应时间异常，往往说明监控存在盲区。反过来，监控发现短时宕机后，也可以对照日志看看蜘蛛是否恰好在那段时间来过。这类交叉验证比单独看一份数据更有判断力。
对运营来说，稳定性直接影响更新节奏。栏目按计划更新，但如果发布时段频繁触发超时或写入失败，内容日历就会变成一张空表。把监控告警和发布流程绑定，出问题时先暂停批量操作，比事后补稿省力得多。
常见误区
- 只看首页：首页正常不代表栏目和详情页正常，缓存可能掩盖了后端问题。
- 只监控状态码：返回 200 但内容是一张错误提示页，同样属于故障。
- 告警太多：一天几十条通知，最后没人当回事。
- 只监控不记录：没有历史数据，就无法判断是偶发还是恶化趋势。
- 把监控当安全设备：可用性监控和攻击防护是两件事，别指望一套规则解决。
可用性监控不追求花哨，追求的是“出问题时有人知道，知道后能快速定位”。把关键地址、合理频率、清晰告警和简单记录这四件事做扎实，就已经比大多数站点走得远。