报错是这么冒出来的。监控面板里只有一个索引量总数，掉 8000 条的那天曲线几乎没有变化，因为同时在涨的是参数页，半个月后才从报表里看出问题。
中间走过弯路，把「数据源取的是平台页面，延迟大且容易解析失败」当成主因，改完现象没变。
真正麻烦的地方在于，几个原因的现象几乎一样。总数掩盖了结构变化，一边掉一边涨互相抵消。也可能是监控只抓取总量，没有按目录拆分。
少数情况下是没有设置按目录的环比阈值告警。
动手时先按目录统计收录量的构成
curl -s 'https://www.example.com/api/index-stats' | python -m json.tool | head -20给核心目录设环比阈值
sum(index_count{dir="post"}) < 0.85 * sum(index_count{dir="post"} offset 7d)每天把总量与分目录数字落一张表
python snapshot.py --out state/index_daily.csv怎么算真的好了，看的是同一批现象。按目录拆开后，第二批参数页上涨的第一天就触发了告警，正文目录的下滑被提前十天发现。
总量曲线是给老板看的，排查问题必须按目录拆开，否则涨跌抵消会掩盖真正的故障。监控比日志更早给出信号，事后回看经常能提前半小时发现异常。