站点出问题，最尴尬的情况往往不是“修不好”，而是“没人知道”。访客打不开页面只会默默关掉标签，搜索引擎蜘蛛抓取失败也只在日志里留一行记录。等到有人来反馈，可能已经过去几个小时甚至几天。把可用性监控和告警纳入日常运营，能把发现故障的时间从“天”压到“分钟”。
先想清楚：哪些故障必须第一时间知道
不是所有异常都值得半夜叫你起来。先把优先级排出来，通常这几类属于必须立刻感知的：
- 首页以及几个核心栏目页无法访问；
- 服务器返回 5xx 的比例明显升高；
- 响应时间从几百毫秒涨到几秒；
- HTTPS 证书即将到期或已经失效；
- 域名解析异常，访问被指向错误地址；
- 磁盘写满导致日志或数据无法写入；
- 数据库连接失败，页面只输出报错信息。
把这几点写下来，后面的监控配置才有依据，不然很容易买一堆服务却没人看。
从最小可用集合开始，而不是先搞大屏
很多团队一开始就想做可视化大屏，结果监控项配了一堆，告警渠道却没接通。更务实的做法是先跑通一条链路：一台便宜的探针或第三方监控服务，定时请求几个关键 URL，记录 HTTP 状态码、响应时间，并做一次内容校验。这条链路跑顺了，再逐步加项。
状态码监控要看什么
- 连续两次失败再告警，避免偶发网络抖动触发误报；
- 4xx 和 5xx 分开统计，前者多半是链接问题，后者才是服务问题；
- 关注趋势而不只是单点，比如 5xx 从每天几条变成每小时几条。
内容校验比状态码更接近真实体验
有些故障页面会返回 200，但正文区域变成了“系统维护中”，或者干脆把数据库报错信息输出到页面上。只监控状态码会完全看不到这类问题。做法很简单：在监控请求里检查页面是否包含某个固定关键词，比如站点名称或主标题，找不到就告警。
告警要送到人真正会看的地方
邮件是最容易漏的渠道。比较稳妥的组合是：聊天工具机器人负责日常通知，重要故障再通过短信或电话触达。可以按影响面分三级：
- P1：核心页面不可访问、大面积 5xx，立即用电话或短信叫人；
- P2：单一路径异常、响应时间明显劣化，走聊天工具；
- P3：证书临期、磁盘使用率偏高，汇总成日报或周报。
别让告警变成“狼来了”
告警最大的敌人是噪音。几个常见做法：设置合理的重试次数和静默期，同一个故障在恢复前只提醒一次；计划内的维护、迁移、压测提前挂上维护窗口；定期回看那些“告警了但没事”的记录，把误报规则调掉。一个长期被忽略的告警群，等于没有监控。
告警之外，还需要一份定期巡检清单
监控只能覆盖你想到的路径，定期巡检是兜底。下面这份清单可以按自己的节奏执行：
- 每周看一眼可用率与平均响应时间的趋势，别只看当天；
- 每月确认一遍证书到期时间，尤其是自动续期是否真的生效；
- 每月确认备份任务在跑，并抽一次实际恢复；
- 每季度模拟一次故障，验证告警能否送达、多久送达；
- 每次故障记录时间、影响范围、原因和处理动作，方便复盘。
这些动作单独看都很小，但坚持下来，站点出问题时你手里就有历史数据可对比，而不是凭感觉猜。
日志留多久，也影响你能查多深
服务器访问日志和错误日志建议做轮转，保留一段时间用于复盘。留得太短，故障过后查不到证据；留得太长，又容易把磁盘写满。这里可以结合站点规模定一个折中值，比如访问日志保留两周到一个月，错误日志保留更久一些，并监控磁盘使用率。
监控和告警不会让站点不出故障，它的价值在于把“被动挨骂”变成“主动处理”。先保证核心页面有人盯着，再慢慢补齐其它监控项，比一次性堆满配置更现实。