入口頁從几十個扩到几百上千個之後，靠人工一個個点開看已经不現實。很多問题不是“全站挂掉”式的，而是某一批域名解析異常、某個机房出口被限速、某個模板渲染失敗，只影响一小部分入口。监控的意义，就是在影响面還小的时候把它找出来。

一、监控分三個层面，不要只盯“能不能打開”

1. 可用性层

這是最基础的一层，關注入口頁本身是否可訪問：

• HTTP 狀態碼：是否為 200，有没有出現 403、404、5xx 的批量聚集；
• 响應時間：TTFB 是否整体抬升，用来判断是源站問题還是线路問题；
• 證书有效期：HTTPS 入口頁到期前 15 天就该提醒；
• DNS 解析：解析记錄是否被改動、解析是否按时生效。

2. 抓取层

入口頁能打開，不代表蜘蛛還在来。抓取层看的是趋势：蜘蛛訪問量有没有出現断崖式下跌、各狀態碼占比是否變化、是否存在大量請求卡在超时。這類指标按天看趋势，通常比按秒看單次告警更有意义。

3. 内容层

包括模板是否正常渲染、跳轉規則是否生效、頁面有没有被意外改寫。批量入口頁一旦模板出問题，往往是整批同时失效，所以内容层的检查要按批次抽检，而不是按單頁逐個看。

二、频率與阈值：別追求“零延迟”

• 可用性探测：核心入口 1—5 分钟一次，長尾入口可以放宽到 10—30 分钟；
• 抓取資料：每天匯總一次，重点看环比變化；
• 内容抽检：按模板批次，每周抽几组；
• 告警阈值：單次失敗先不报，连續 2—3 次失敗再触發，能過滤掉大量網絡抖動。

告警太多等于没有告警。宁可漏掉一次抖動，也不要让值班的人對提示音麻木。

三、常见的几個誤区

• 只监控一個代表域名。入口頁分散在不同 IP、不同机房，單点正常不代表整体正常。
• 把蜘蛛訪問量下降直接等同于被降權。线路故障、CDN 規則調整、robots 改動都會造成相似的曲线。
• 告警只發不记。没有记錄就無法复盘，也判断不出是偶發還是趋势。
• 用高频探测去打自己的入口頁。部分监控频率過高，本身就會消耗服務器资源，甚至触發防護規則。

四、日誌留存與复盘节奏

建议至少保留 30 天的訪問日誌與狀態碼統計，抓取相關的匯總資料可以留得更久。每次處理完告警，简單记一下時間、現象、判断原因和處理方式。积累几個月之後，你會發現自己的故障模式其實就那么几類。

五、把监控结果用起来

监控不只是“出事了叫人”。稳定的可用性資料能帮你判断哪些机房值得繼續用，抓取趋势能帮你判断扩量节奏是不是太快，内容抽检结果則可以反過来優化模板。把這三類資料定期放在一起看，比單看任何一項都更有參考價值。

最後提醒一句：监控的目标是让問题早一点被發現，而不是保證問题不發生。入口頁的可用性和抓取表現受很多外部因素影响，任何工具都只能提高發現速度，替代不了對異常的正常判断。