问题出现得很突然，日志倒是留得挺全。自建的巡检脚本每五分钟请求一次首页，只判断返回码是不是 200，某栏目接口挂了内页连续 500 两天，直到用户投诉才发现。
刚开始盯着「巡检结果不发通知，只在终端里打印一行日志」，折腾了半个多小时，排掉了。
排查方向其实有限，先把可能性排一排。探针只覆盖首页，内页和接口完全没有监控。还有一种是判断条件只看 200，301 和 304 也会被当成异常或正常。
另外，脚本跑在站内机器上，出口被拉黑时同样抓不到。
先按栏目抽样一批内页加进探针
for u in /post/1 /p/2 /list/; do curl -o /dev/null -s -w '%{http_code} %{url_effective}\n' https://www.example.com$u; done接着把巡检结果落到时序库并配阈值
python probe.py --urls urls.txt --push http://127.0.0.1:9091/metrics异常时直接推到告警群
curl -s -X POST https://alert.example.com/hook -d '{"text":"内页 5xx 超过 1%"}'改完先别撤，确认这几项。探针覆盖到十二个栏目后，同类故障在十分钟内就触发了告警，内页 5xx 的持续时间从两天压到半小时。
提醒一点。巡检的价值在于覆盖面而不是频率，一个只探首页的脚本每天跑一万次也发现不了内页的问题。同一份配置在测试环境跑通，不代表线上没事，两边的默认值经常不一样。