站点出問题的时候，最先察觉的往往不是运营者，而是用戶或者蜘蛛。可用性监控的意义，就是在別人来告诉你之前先知道。它不解决内容與结构問题，但能守住最基本的底线：站点能不能打開、打開得快不快、返回的狀態對不對。
监控要覆盖的几件事
- 可用性與狀態碼：首頁、核心栏目頁、重要内容頁是否返回 200，监控要能区分 4xx、5xx 與连接超时。
- 响應時間：记錄首字节時間與完整加载時間，先跑一段時間得出基线，再看偏离程度。
- 證书與域名：HTTPS 證书到期時間、域名到期時間，提前 30 天提醒，這類事故完全可预防。
- DNS 與解析：解析是否正常、是否配置了多個權威服務器、變更後是否已经生效。
- 内容校驗：不只判断狀態碼，還要校驗頁面里是否有预期的标题或關鍵詞，避免出現返回 200 的空壳頁。
- 服務器资源：CPU、内存、磁盘、带宽的水位。磁盘寫满導致的 500 最难排查，也最容易被忽略。
探测点與频率怎么定
探测点最好分布在不同網絡與地区，避免單点誤报把正常站点判成故障。频率不必追求极致，核心頁面 1 到 5 分钟一次，次要頁面 5 到 15 分钟一次就够用；频率過高只會制造噪音，還會增加服務器负担。
也要注意监控本身的開销。如果每個探测都完整加载頁面和静態资源，流量與压力會明顯上升，可以在部分任務里只用 HEAD 請求，或者只取首屏 HTML 做校驗。
告警阈值與降噪
- 分級：核心頁面不可用立即通知，次要頁面異常匯總後通知。
- 连續確認：连續两次或三次失敗再报警，過滤瞬时抖動。
- 静默與抑制：發布窗口、已知维護期提前設定静默，同一故障不要重复推送。
- 通知到人：明确谁值班、谁响應，避免消息發到群里却没人認领。
阈值不要照抄別人的模板。小站把响應時間阈值定得和大站一样，结果就是天天报警然後被所有人忽略；阈值應当基于自己近一個月的真實資料来设定。
收到告警之後做什么
监控只完成了一半工作。每次告警都值得留一條记錄：發生時間、影响范围、處理動作、恢复時間、是否可以预防。周期性回看這些记錄，往往能看出規律，比如每天同一時間备份把磁盘 IO 打满，或者某個插件在流量高峰拖慢响應。
如果確認是誤报，要調整規則，而不是简單忽略。長期被忽略的告警，等于没有告警。
第三方服務還是自己搭
第三方监控上手快、探测点多，适合作為第一层；自建脚本能拿到服務器内部的资源資料，适合作為第二层，两者並不冲突。小站先用第三方把核心頁面看住，再逐步补齐服務器层面的采集，比一開始就搭一套复杂系統更現實。
一份简單的落地顺序
- 列出 5 到 10 個必须保持可用的地址，涵盖首頁、主要栏目與關键内容頁。
- 為這些地址配置狀態碼與响應時間检查，並開啟内容校驗。
- 设定通知渠道與值班人，明确不同級別的响應要求。
- 先跑两周，統計誤报次數，據此調整阈值和探测频率。
- 补充證书、域名、磁盘水位這類變化缓慢但致命的提醒項。
可用性监控属于實时防线，它和站点地图、robots 規則、狀態碼治理、抓取日誌分析這類周期性自查是互补關系：前者發現突發問题，後者處理長期积累的结构性隐患。把监控面板和每周自查清單放在同一處，對照起来會更顺手。
监控不是為了给自己增加压力，而是把被動救火變成提前知道。覆盖核心頁面，阈值贴合自己的資料，告警有人负责，這三点做到，站点运营的底盘就稳了一多半。