站点运营里有一類工作很容易被忽略：不是把站点建好，而是確認它一直活着。很多团队直到用戶投诉、或者發現蜘蛛抓取量断崖式下滑，才回头去查服務器——這时候故障可能已经持續了几個小时。监控與告警要做的事，就是把“發現問题”從被動變成主動。
先明确要监控什么
监控不是指标越多越好，而是覆盖住那些一旦異常就會影响用戶和蜘蛛的關键点。
- 可用性：首頁、核心栏目頁、重要内容頁能否正常返回 200，不同地区节点结果是否一致。
- 响應時間：TTFB、完整頁面加载耗时、資料库查询耗时，重点看是否在缓慢劣化。
- 错誤率：5xx 占比、超时次數、连接被拒的次數，短時間内的尖峰尤其要關注。
- 抓取侧信号：蜘蛛請求量、抓取时返回的狀態碼分布、抓取超时比例，這些是站点健康度在外部的間接反映。
- 资源水位：磁盘、内存、CPU、資料库连接數、带宽使用量，配合日誌轮轉一起看。
- 到期類事項：HTTPS 證书剩余天數、域名有效期、CDN 與第三方服務的配額。
告警怎么设才不會被忽略
阈值加持續时長
只看單次探测结果很容易誤报，網絡抖動、CDN 邊缘节点偶發異常都會触發。比較實用的做法是阈值加持續时長：例如连續 3 次探测失敗，或 5 分钟内 5xx 比例超過设定值时才告警。這样既不會漏掉真實故障，也不會让值班的人對通知麻木。
分級與通知渠道
- 站点完全不可用、證书即將過期——电话或短信，必须有人立刻處理。
- 响應時間明顯變慢、错誤率上升——即时通讯群通知，工作時間内處理。
- 资源水位缓慢上涨、周度趋势變化——日报或周报，排進例行工作。
同时要给每條告警指定责任人，否則群里消息刷屏但没人動手是常態。
避免噪声淹没真問题
計划内的维護、發布、压测要提前設定静默窗口；同一故障的重复告警要合並；已经處理完的告警要有明确的關閉记錄，否則下一次遇到同样的問题還是從头排查。
定期自查清單
- 监控覆盖的 URL 清單是否跟着改版更新過？改版後舊探针可能一直失敗，持續占用注意力。
- 探针是否被 WAF、CDN 或風控当成異常請求拦截，從而制造“站点挂了”的假象？
- 告警接收人里是否還有已经离职或調岗的同事？通知發不出去等于没有监控。
- 是否只盯着首頁，忽略了子域名、重要内容目錄、接口和静態资源？
- 监控指标和訪問日誌能否對得上？两邊資料長期背离，說明有一方口径错了。
- 每次真實故障後，是否记錄了發生時間、影响范围、處理動作和改進項？
监控的價值不在于仪表盘好看，而在于故障發生时，你是第一個知道的人，而不是最後一個。
不需要一次把所有指标补齐。先把可用性和證书到期這两件事盯住，再逐步加上响應時間、错誤率和抓取信号，配合一份能落地的處理记錄，站点运营的稳定性會明顯可控一些。