站点出故障，最怕的不是故障本身，而是几個小时過去了，运营和运维都還不知情。监控與告警做扎實，出問题能第一時間發現，恢复之後也有資料可以复盘。下面這份自查清單不涉及具体工具選型，只讲清楚“监控什么、怎么告警、容易踩哪些坑”。
一、先確認监控覆盖了哪些层
只监控首頁能不能打開是不够的。域名、證书、頁面、接口、服務器资源，每一层都可能單獨出問题，而任何一层掉线，訪客看到的都是同一個结果——站点不能用了。
- 域名與 DNS：解析是否正常、TTL 設定是否合理、解析记錄有没有被改成错誤的 IP。
- HTTPS 證书：到期時間建议提前 30 天告警，中間證书同样要检查，別只盯着主證书。
- HTTP 层：狀態碼、响應時間、首字节時間。列表頁、詳情頁、搜尋结果頁這些關键路径單獨配置，不要只测首頁。
- 頁面内容：狀態碼 200 不代表頁面正常，可以在探测时校驗頁面是否包含某個特征词，防止“空白 200”或报错頁被当成正常頁面。
- 核心接口與後台任務：登入、提交、站内搜尋、定时任務以及队列积压情况。
- 服務器资源：CPU、内存、磁盘使用率、資料库连接數。磁盘不要等到 95% 才告警，按增長速度留出處理時間。
二、探测频率和探测点要克制
监控本身也是一種流量。探测频率過高、探测点過多，源站出問题时反而更容易被压垮。
- 關键頁面 1 到 5 分钟探测一次通常够用，非關键頁面可以放宽到 10 分钟以上。
- 多地探测适合判断是不是局部網絡問题，但要注意所有探测点同时打過来會形成小規模压力。
- 给监控請求設定固定的 User-Agent 和来源 IP，方便在日誌里区分，必要时在限流規則里放行。
- 確認监控請求不會被当成異常爬虫拦截，也不會進入統計口径，污染正常的訪問資料。
三、告警策略决定你會不會去看告警
告警最大的問题往往不是太少，而是太多。一個每次都响、响完發現没事的渠道，很快就會没人看。所以阈值、持續時間、通知對象都要提前设計。
- 分級：會影响訪客訪問的走电话或即时通讯，性能轻微波動走邮件或日报。
- 持續時間：连續 2 到 3 次探测失敗再告警，避免一次網絡抖動就把人叫起来。
- 收敛：同一問题短時間内只發一條，恢复时再补一條恢复通知。
- 静默期：計划内的维護、發版、迁移提前設定静默，否則告警風暴會让你错過真正的問题。
- 值班與升級：明确第一联系人，多久没响應就升級给第二個人。
四、几個常见誤区
- 只监控首頁，某個栏目或功能挂了完全不知道。
- 只看狀態碼，不看响應内容和响應時間，頁面慢到十几秒也算“正常”。
- 所有告警發到同一個群，重要信息被日常噪声淹没。
- 没有歷史資料，出問题後只能凭印象判断“以前是不是也這样”。
- 监控配置改過之後没人复核，某個頁面早就下架了，监控還在一直告警。
五、可以照着做的落地清單
- 列出站点最關键的 5 到 10 個頁面和接口，逐個加入监控。
- 為證书、域名、磁盘設定到期和容量類提醒。
- 確認探测频率、探测点數量和来源标识是否合理。
- 给告警分級，指定接收人和升級路径。
- 维護、發版前設定静默，結束後复核告警是否恢复正常。
- 每季度回顾一次告警记錄，把長期誤报的規則調整或删掉。
监控的意义不是让告警响個不停，而是让真正的問题在你收到用戶反馈之前就浮出来。
把這几項過一遍，通常能發現一些早就该修但一直没人注意的空当。监控配置不需要一次做到完美，先覆盖關键路径，再逐步补齐，比一步到位更現實。