把抓取日志做成每日简报，六十行脚本的事

2026 年 3 月我们给三个站上了日志简报，每天早上 9 点一条消息推送到项目群，四个数字，六十行脚本。上线两个月，比之前做的那个交互式日志看板有用得多，因为看板没人打开。

简报只放四个数

蜘蛛请求总数，和过去 7 日均值比；各搜索引擎的占比，Google 和百度分开；新增 404 的数量；抓取最多的三个目录和最少的一个核心目录。

四个数之外的东西都不放。日志里能算的指标有几十个，全放进去就没人看了。我们的原则是：一条消息能在手机屏幕上读完，超过这个长度就是失败。

怎么算

统计窗口取前一天 0 点到 24 点，避开当天日志没写完的问题。蜘蛛请求要按 IP 反查验证，不能只信 UA，否则一堆假蜘蛛会把数字抬高。

和过去 7 日均值对比，波动超过正负 30% 的标红。这个阈值是试出来的：低于 30% 的波动基本都是正常起伏，天天标红等于没标。

脚本结构

读日志、筛蜘蛛、聚合、生成 markdown、推送到群机器人，五步。中间任何一步失败都要抛异常，不能静默跳过。

我们踩过一个坑：日志文件某天没轮转，脚本读到空文件，照样推送了一条“今日抓取 0 次”。第二天团队以为站挂了，查了半天。现在脚本会先校验文件行数，低于阈值直接报错。

数据不准的时候怎么发现

简报最怕数字全对但没人看。我们的办法是每天加一句备注，把和昨天差异最大的那项写出来，比如“百度蜘蛛请求掉了 42%”或者“新增 404 集中在 docs/v1 目录”。

写这句要两分钟，但团队会在群里接话。数字本身没人讨论，一句结论有人讨论。

还有一点，简报只发工作日。周末日志量本来就低，发出来只制造噪音，周一早上合并成一条就行。

为什么不做看板

看板的问题是没人主动打开。我们做过一个，数据比简报全，可交互，上线一个月后台访问记录不到 20 次，还都是我们自己点的。

群消息不一样，它推到你面前。有异常的时候大家会在群里讨论，没异常的时候看一眼就过。这个交互成本低得多。

用下来的感受

两个月里发现过两次真正的异常：一次是 CDN 配置改动导致百度蜘蛛全部被拦，一次是站点地图生成失败影响了新页面抓取。都是当天就发现了，没有拖到周报。

它不是诊断工具，只是提醒你去看。真要分析还是得回到日志和 GSC，但有人提醒和没人提醒，差别很大。