事情本身不复杂，线索都在日志里。GSC 抓取统计里服务器错误占 12%，运维的监控平台同期只报了两次 500，两边数据差了一个数量级。
第一反应是「报警阈值设在连续五分钟，蜘蛛的失败是零星分布」，验证下来不成立。
真正麻烦的地方在于，几个原因的现象几乎一样。监控只统计了首页探针，蜘蛛抓的是内页和接口。另一种情况是5xx 被 CDN 转成 200 的兜底页返回，源站日志里是 502。
另外，监控按分钟聚合取均值，短时间的错误尖峰被抹平。
动手时先按状态码统计蜘蛛请求的分布
awk '$9>=500{print $9, $7}' access.log | sort | uniq -c | sort -rn | head随后把探针从首页改到高频内页
curl -o /dev/null -s -w '%{http_code}\n' https://www.example.com/post/1给 5xx 单独加一条按比例的告警
sum(rate(nginx_http_requests_total{status=~"5.."}[5m])) > 0.01怎么算真的好了，看的是同一批现象。探针覆盖到内页后，监控当天就抓到了同一个故障，两边统计的 5xx 比例差距缩到 1 个百分点以内。
这里还有个坑。监控探的是站点还活着，搜索引擎看的是每个 URL 都能打开，两者的覆盖面完全不同。报错文案容易误导，真正的原因往往在相邻那一层的日志里。