站点运营里有一類問题最尴尬：不是内容不行，也不是结构有問题，而是某段時間站点根本打不開，而你是在用戶反馈之後才知道。可用性监控看起来简單——装個探针、填個地址、配個信箱，但真正起作用的，是监控点選得對不對、频率合不合理、告警發出去之後有没有人接。
先想清楚要盯哪些東西
很多人只盯着首頁。首頁能打開不代表站点可用，尤其当首頁走缓存、栏目頁走動態渲染时，两者的故障並不同步。
- 核心入口：首頁、主要栏目頁、詳情頁模板各挑一到两個代表性地址，尽量覆盖不同的渲染路径。
- 關键流程：站内搜尋、登入、表單提交這類环节一旦失敗，首頁依然是 200，但它對用戶来说等于站点坏了。
- 域名與解析：监控 HTTP 之前，先確認 DNS 解析本身可用；解析異常时，所有 HTTP 探测會一起變红，容易誤判成服務器全挂。
- 證书有效期：到期前几天就该提醒，不要等浏览器彈安全警告。
- 服務器基础指标：磁盘使用率、内存、负载、连接數。這些指标往往是頁面變慢的前兆，比等頁面超时更早一步。
探测频率、超时和重试要配套
探测太密，日誌和设备都吃不消；太稀疏，一次几分钟的抖動可能被完整跳過。一個可行的起点是：核心入口一分钟一次，普通頁面五分钟一次，基础指标一分钟采集一次。
超时不要设得過短，網絡抖動很常见；但也不要為了减少誤报把超时设到几十秒，那會让真實故障的發現時間被拉長。比較稳妥的做法是重试两到三次、由多個探测节点共同確認後再發告警。需要注意的是，重试只能压掉偶發抖動，不能用来掩盖持續存在的慢。
告警分級要落到人
告警最大的浪費不是發多了，而是發到一個没人看的群里。可以按影响范围分三級：
- 高優先級：站点整体不可訪問、核心接口持續失敗。走电话或短信，要求有人立刻响應。
- 中優先級：個別頁面異常、静態资源加载失敗、响應時間明顯上升。用即时消息在工作時間處理。
- 低優先級：磁盘逐步增長、缓存命中率下降之類的趋势項。匯總成日报，按計划處理。
每一級都要寫清楚责任人，而不是寫一個团队名。同时给告警加收敛規則：同一個地址在短時間内重复失敗，只發一條並标注次數，避免刷屏之後大家對告警麻木。
健康检查頁別踩坑
不少框架自带 /health 之類接口，返回一行 OK，很适合给监控調用，但有几個细节要注意。第一，不要在這類頁面暴露版本号、内網地址、依赖服務清單。第二，它不该被搜尋引擎抓取收錄，最好從站点地图和導航里排除。第三，也是最重要的：它要真的检查依赖，而不是無论資料库连不上、缓存挂了都返回成功。一個永遠返回 OK 的健康检查頁，比没有還危險。
非 HTTP 层面最容易漏
- 定时任務是否按时执行，失敗後有没有通知，而不是第二天才發現資料没更新。
- 日誌是否正常轮轉，磁盘被日誌寫满是很常见的故障原因。
- 备份任務是否成功，以及备份文件大小是否在合理区間。
- 队列是否出現积压，第三方接口的失敗率是否異常。
定期演练和复盘
监控配好不等于有效。建议每個季度做一次演练：手動停掉一個非核心服務，看看告警是否按预期触發、多久送達、内容里是否包含足够定位問题的信息，比如時間、地址、狀態碼、探测节点。演练之後把誤报和漏报都记下来，調整阈值和通知范围。
监控的目标不是告警越多越安心，而是出事时你能比用戶早一步知道，並且知道该從哪里下手。
把這些内容整理成一張值班清單，配上联系人，放在团队都能看到的地方。真正需要用到它的那個凌晨，你不會想再去翻配置頁面。