站点出问题的时候，最先察觉的往往不是运营者，而是用户或者蜘蛛。可用性监控的意义，就是在别人来告诉你之前先知道。它不解决内容与结构问题，但能守住最基本的底线：站点能不能打开、打开得快不快、返回的状态对不对。
监控要覆盖的几件事
- 可用性与状态码：首页、核心栏目页、重要内容页是否返回 200，监控要能区分 4xx、5xx 与连接超时。
- 响应时间：记录首字节时间与完整加载时间，先跑一段时间得出基线，再看偏离程度。
- 证书与域名：HTTPS 证书到期时间、域名到期时间，提前 30 天提醒，这类事故完全可预防。
- DNS 与解析：解析是否正常、是否配置了多个权威服务器、变更后是否已经生效。
- 内容校验：不只判断状态码，还要校验页面里是否有预期的标题或关键词，避免出现返回 200 的空壳页。
- 服务器资源：CPU、内存、磁盘、带宽的水位。磁盘写满导致的 500 最难排查，也最容易被忽略。
探测点与频率怎么定
探测点最好分布在不同网络与地区，避免单点误报把正常站点判成故障。频率不必追求极致，核心页面 1 到 5 分钟一次，次要页面 5 到 15 分钟一次就够用；频率过高只会制造噪音，还会增加服务器负担。
也要注意监控本身的开销。如果每个探测都完整加载页面和静态资源，流量与压力会明显上升，可以在部分任务里只用 HEAD 请求，或者只取首屏 HTML 做校验。
告警阈值与降噪
- 分级：核心页面不可用立即通知，次要页面异常汇总后通知。
- 连续确认：连续两次或三次失败再报警，过滤瞬时抖动。
- 静默与抑制：发布窗口、已知维护期提前设置静默，同一故障不要重复推送。
- 通知到人：明确谁值班、谁响应，避免消息发到群里却没人认领。
阈值不要照抄别人的模板。小站把响应时间阈值定得和大站一样，结果就是天天报警然后被所有人忽略；阈值应当基于自己近一个月的真实数据来设定。
收到告警之后做什么
监控只完成了一半工作。每次告警都值得留一条记录：发生时间、影响范围、处理动作、恢复时间、是否可以预防。周期性回看这些记录，往往能看出规律，比如每天同一时间备份把磁盘 IO 打满，或者某个插件在流量高峰拖慢响应。
如果确认是误报，要调整规则，而不是简单忽略。长期被忽略的告警，等于没有告警。
第三方服务还是自己搭
第三方监控上手快、探测点多，适合作为第一层；自建脚本能拿到服务器内部的资源数据，适合作为第二层，两者并不冲突。小站先用第三方把核心页面看住，再逐步补齐服务器层面的采集，比一开始就搭一套复杂系统更现实。
一份简单的落地顺序
- 列出 5 到 10 个必须保持可用的地址，涵盖首页、主要栏目与关键内容页。
- 为这些地址配置状态码与响应时间检查，并开启内容校验。
- 设定通知渠道与值班人，明确不同级别的响应要求。
- 先跑两周，统计误报次数，据此调整阈值和探测频率。
- 补充证书、域名、磁盘水位这类变化缓慢但致命的提醒项。
可用性监控属于实时防线，它和站点地图、robots 规则、状态码治理、抓取日志分析这类周期性自查是互补关系：前者发现突发问题，后者处理长期积累的结构性隐患。把监控面板和每周自查清单放在同一处，对照起来会更顺手。
监控不是为了给自己增加压力，而是把被动救火变成提前知道。覆盖核心页面，阈值贴合自己的数据，告警有人负责，这三点做到，站点运营的底盘就稳了一多半。