站点出故障，最常见的情况不是没人修，而是没人知道。頁面返回 500、證书過期、DNS 解析漂移、CDN 回源失敗，這些在後台往往没有任何提示，直到某天發現蜘蛛来訪量掉了一半，才回头去翻日誌。把监控和告警当作日常运营的一部分，比事後抢救省力得多。
一、先明确要盯的“静默故障”
所谓静默故障，指的是不會主動报错、但已经在影响訪問和抓取的問题。常见的有几類：
- 域名或 DNS 记錄被誤改，部分地区解析失敗，其他地区一切正常
- HTTPS 證书到期或證书鏈不完整，訪問直接报错
- 服務器磁盘寫满、資料库连接數打满，頁面開始零星返回 5xx
- CDN 缓存規則或回源配置調整後，部分 URL 打不開
- robots.txt 或防火墙規則誤伤，蜘蛛被整段拦掉
- 站点地图地址變更後，蜘蛛取到的是舊地址或 404
這些問题共同的特点是：前台可能只是“慢了一点”或者“偶尔打不開”，但只要持續几個小时，抓取和收錄就會跟着受影响。
二、监控分层：從域名到頁面
基础设施层
- DNS 解析结果與 TTL 變化，最好從多個地区做解析探测
- 證书剩余有效期，提前 30 天開始提醒
- 服務器 CPU、内存、磁盘、带宽的使用曲线
- 資料库與缓存的连接狀態
應用與關键頁面层
- 首頁、主要栏目頁、几個高频落地頁的 HTTP 狀態碼與首字节時間
- 全站 5xx 與 4xx 的比例變化
- 登入、搜尋、提交表單等關键功能的可用性
抓取與發現相關
- 服務器日誌中蜘蛛請求條數的日环比、周同比
- 站点地图的抓取成功率與返回碼
- robots.txt 是否可正常訪問，内容是否為预期版本
- 重点新發頁面的首次被抓時間
抓取類指标不必精确到個位，看趋势就够。如果连續两三天蜘蛛訪問量明顯下滑，同时 5xx 比例上升，基本可以判断是站点侧的問题，而不是内容本身不受欢迎。
三、告警配置的几個實用原則
- 分級處理：把“整站打不開”和“某個次要頁面變慢”分開，前者电话通知，後者進日报。
- 阈值別设太紧：响應時間從 800ms 變成 1.2s 不一定值得半夜叫人，连續三次失敗再告警更稳。
- 設定恢复通知：知道問题什么时候結束，才能確認處理真的有效。
- 告警要带上下文：寫明具体 URL、狀態碼、發生時間，而不是一句“站点異常”。
- 定期清理失效告警項：改版後舊监控還在跑，會制造大量噪音。
- 明确接收人和响應時間：至少准备一個备份接收人。
提醒：告警不是越多越好。如果每天收到几十條，最後的结果通常是全部标為已讀。
四、異常發生後的處理顺序
- 確認影响范围：全站還是單頁，單一地区還是所有地区。
- 回看最近變更：代碼發布、配置調整、DNS、證书、CDN 規則，多數問题出在這里。
- 優先恢复服務，再定位原因，必要时先回滚。
- 恢复後复查抓取：观察蜘蛛日誌、站点地图抓取和重点頁面狀態碼是否回归正常。
- 记錄故障處理過程，补充或調整监控項，避免同样的問题再来一次。
五、日常自查清單
- 證书、域名、服務器到期時間是否都有人盯，並且提前提醒
- 關键頁面是否纳入定时拨测，覆盖多個地区
- 蜘蛛日誌是否有留存，能否對比周同比與月同比
- 告警接收人、升級路径是否寫進文档，而不是只存在某個人脑子里
- 近一個月是否有告警被長期忽略，原因是什么
站点监控的意义不是让运营變得紧張，而是把問题從“事後發現”提前到“刚發生就知道”。對依赖自然流量的站点来说，稳定的可訪問性和持續的抓取，比任何技巧都更重要。