站点出問题的时候，第一個知道的往往不是站長，而是訪客或者抓取程序。一次資料库连接異常、一次證书過期、一次磁盘寫满，可能几小时後才在後台留言里被提醒。站点健康监控的意义不是追求零故障，而是把發現故障的時間缩短，让排查有據可依。
先想清楚要监控哪些指标
监控不是装個探针就完事，先列清楚哪些異常會影响訪客和抓取，再决定监控方式。
- 可用性：首頁和几個關键栏目頁能否正常返回 200，是否存在間歇性 502、504。
- 响應時間：首字节時間與整頁加载時間的歷史基线，超過基线多少算異常，要有曲线可對比。
- 證书與域名：HTTPS 證书到期時間、域名到期時間、DNS 解析是否正常。
- 服務器资源：磁盘剩余空間、内存、CPU 负载、資料库连接數與慢查询。
- 抓取侧信号：蜘蛛訪問量突然归零或暴增、大量 5xx 返回、robots 文件被改動。
- 业務侧信号：表單提交失敗、站内搜尋無结果、留言量異常下滑。
指标不需要一口气做全，先把「挂了能立刻知道」這一层做扎實，再逐步补充。
阈值和告警分級，比监控本身更重要
告警太敏感，最後所有人都會把它当成噪音划掉；太迟钝，又失去了意义。比較實际的做法是分两到三級。
- 紧急：站点不可訪問、證书已過期、資料库無法连接，直接电话或即时通讯找值班人。
- 重要：响應時間持續超過阈值、磁盘剩余空間低于 10%、抓取量異常波動。
- 提示：證书還有 15 天到期、备份任務延迟、個別内頁返回 4xx。
阈值不要拍脑袋定。先观察一到两周的正常波動范围，把阈值设在正常值之上一点，减少誤报。同时给同類告警做聚合，避免一次故障刷出几十條重复消息。
告警發出去之後，得有人接
- 明确第一响應人，以及联系不上时的第二顺位。
- 告警渠道至少保留两個，避免單一渠道故障導致全部静默。
- 记錄每次告警的處理過程，形成简短的事後记錄，方便复盘同類問题。
- 定期做一次演练式告警測試，確認接收端真的能收到。
很多团队不是没有监控，而是监控發到了没人看的群，或者告警信箱早就不再登入。
一次可以照着做的自查
- 列出對訪客影响最大的 3 到 5 個頁面，作為可用性探测目标。
- 確認探测节点位置，尽量覆盖主要訪問来源地区，不要只從本地探测。
- 检查證书與域名到期時間，把提醒设在到期前 30 天和 15 天。
- 配置磁盘、内存、資料库连接數的阈值告警。
- 把站点地图和几個重要 URL 加入定时检查，返回碼異常时通知。
- 確認告警接收人是在职人員，离职帳號及时移除。
- 每月回看一次告警记錄，統計誤报比例，調整阈值。
容易忽略的几個细节
- 监控頁面本身被缓存，内容更新後仍返回舊版本，被誤判為正常。
- 只监控首頁，栏目頁和内頁挂掉很久都没人發現。
- 用搜尋结果判断站点狀態，滞後且不准确。
- 服務器日誌没有留存或轮轉策略，出問题後無據可查。
监控和告警做得再细致，也不能保證站点永不出問题，但能让你在問题扩大之前先動手。把它当成日常运营的一部分，比出事後熬夜排查要省力得多。