入口页从几十个扩到几百上千个之后，靠人工一个个点开看已经不现实。很多问题不是“全站挂掉”式的，而是某一批域名解析异常、某个机房出口被限速、某个模板渲染失败，只影响一小部分入口。监控的意义，就是在影响面还小的时候把它找出来。

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

1. 可用性层

这是最基础的一层，关注入口页本身是否可访问：

• HTTP 状态码：是否为 200，有没有出现 403、404、5xx 的批量聚集；
• 响应时间：TTFB 是否整体抬升，用来判断是源站问题还是线路问题；
• 证书有效期：HTTPS 入口页到期前 15 天就该提醒；
• DNS 解析：解析记录是否被改动、解析是否按时生效。

2. 抓取层

入口页能打开，不代表蜘蛛还在来。抓取层看的是趋势：蜘蛛访问量有没有出现断崖式下跌、各状态码占比是否变化、是否存在大量请求卡在超时。这类指标按天看趋势，通常比按秒看单次告警更有意义。

3. 内容层

包括模板是否正常渲染、跳转规则是否生效、页面有没有被意外改写。批量入口页一旦模板出问题，往往是整批同时失效，所以内容层的检查要按批次抽检，而不是按单页逐个看。

二、频率与阈值：别追求“零延迟”

• 可用性探测：核心入口 1—5 分钟一次，长尾入口可以放宽到 10—30 分钟；
• 抓取数据：每天汇总一次，重点看环比变化；
• 内容抽检：按模板批次，每周抽几组；
• 告警阈值：单次失败先不报，连续 2—3 次失败再触发，能过滤掉大量网络抖动。

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

三、常见的几个误区

• 只监控一个代表域名。入口页分散在不同 IP、不同机房，单点正常不代表整体正常。
• 把蜘蛛访问量下降直接等同于被降权。线路故障、CDN 规则调整、robots 改动都会造成相似的曲线。
• 告警只发不记。没有记录就无法复盘，也判断不出是偶发还是趋势。
• 用高频探测去打自己的入口页。部分监控频率过高，本身就会消耗服务器资源，甚至触发防护规则。

四、日志留存与复盘节奏

建议至少保留 30 天的访问日志与状态码统计，抓取相关的汇总数据可以留得更久。每次处理完告警，简单记一下时间、现象、判断原因和处理方式。积累几个月之后，你会发现自己的故障模式其实就那么几类。

五、把监控结果用起来

监控不只是“出事了叫人”。稳定的可用性数据能帮你判断哪些机房值得继续用，抓取趋势能帮你判断扩量节奏是不是太快，内容抽检结果则可以反过来优化模板。把这三类数据定期放在一起看，比单看任何一项都更有参考价值。

最后提醒一句：监控的目标是让问题早一点被发现，而不是保证问题不发生。入口页的可用性和抓取表现受很多外部因素影响，任何工具都只能提高发现速度，替代不了对异常的正常判断。