站点运营里有一类问题最尴尬：不是内容不行，也不是结构有问题，而是某段时间站点根本打不开，而你是在用户反馈之后才知道。可用性监控看起来简单——装个探针、填个地址、配个邮箱，但真正起作用的，是监控点选得对不对、频率合不合理、告警发出去之后有没有人接。
先想清楚要盯哪些东西
很多人只盯着首页。首页能打开不代表站点可用，尤其当首页走缓存、栏目页走动态渲染时，两者的故障并不同步。
- 核心入口：首页、主要栏目页、详情页模板各挑一到两个代表性地址，尽量覆盖不同的渲染路径。
- 关键流程：站内搜索、登录、表单提交这类环节一旦失败，首页依然是 200，但它对用户来说等于站点坏了。
- 域名与解析：监控 HTTP 之前，先确认 DNS 解析本身可用；解析异常时，所有 HTTP 探测会一起变红，容易误判成服务器全挂。
- 证书有效期：到期前几天就该提醒，不要等浏览器弹安全警告。
- 服务器基础指标：磁盘使用率、内存、负载、连接数。这些指标往往是页面变慢的前兆，比等页面超时更早一步。
探测频率、超时和重试要配套
探测太密，日志和设备都吃不消；太稀疏，一次几分钟的抖动可能被完整跳过。一个可行的起点是：核心入口一分钟一次，普通页面五分钟一次，基础指标一分钟采集一次。
超时不要设得过短，网络抖动很常见；但也不要为了减少误报把超时设到几十秒，那会让真实故障的发现时间被拉长。比较稳妥的做法是重试两到三次、由多个探测节点共同确认后再发告警。需要注意的是，重试只能压掉偶发抖动，不能用来掩盖持续存在的慢。
告警分级要落到人
告警最大的浪费不是发多了，而是发到一个没人看的群里。可以按影响范围分三级：
- 高优先级：站点整体不可访问、核心接口持续失败。走电话或短信，要求有人立刻响应。
- 中优先级：个别页面异常、静态资源加载失败、响应时间明显上升。用即时消息在工作时间处理。
- 低优先级：磁盘逐步增长、缓存命中率下降之类的趋势项。汇总成日报，按计划处理。
每一级都要写清楚责任人，而不是写一个团队名。同时给告警加收敛规则：同一个地址在短时间内重复失败，只发一条并标注次数，避免刷屏之后大家对告警麻木。
健康检查页别踩坑
不少框架自带 /health 之类接口，返回一行 OK，很适合给监控调用，但有几个细节要注意。第一，不要在这类页面暴露版本号、内网地址、依赖服务清单。第二，它不该被搜索引擎抓取收录，最好从站点地图和导航里排除。第三，也是最重要的：它要真的检查依赖，而不是无论数据库连不上、缓存挂了都返回成功。一个永远返回 OK 的健康检查页，比没有还危险。
非 HTTP 层面最容易漏
- 定时任务是否按时执行，失败后有没有通知，而不是第二天才发现数据没更新。
- 日志是否正常轮转，磁盘被日志写满是很常见的故障原因。
- 备份任务是否成功，以及备份文件大小是否在合理区间。
- 队列是否出现积压，第三方接口的失败率是否异常。
定期演练和复盘
监控配好不等于有效。建议每个季度做一次演练：手动停掉一个非核心服务，看看告警是否按预期触发、多久送达、内容里是否包含足够定位问题的信息，比如时间、地址、状态码、探测节点。演练之后把误报和漏报都记下来，调整阈值和通知范围。
监控的目标不是告警越多越安心，而是出事时你能比用户早一步知道，并且知道该从哪里下手。
把这些内容整理成一张值班清单，配上联系人，放在团队都能看到的地方。真正需要用到它的那个凌晨，你不会想再去翻配置页面。