记录一下那天晚上的排查过程。队列深度用一分钟一次的快照进监控，大促时上游瞬间推了三万条消息，两次采样之间积压已经消化完，看板上最大只有八百条，扩容策略一次都没触发，最后是用户侧超时先报出来。
刚开始盯着「扩容策略读的就是这份低频指标」，折腾了半个多小时，排掉了。
排查方向其实有限，先把可能性排一排。采样间隔太长，瞬时峰值落在两次采样之间。少数情况下是指标只存平均值，尖峰被平均掉。
少数情况下是队列没有暴露最老消息年龄这类更能反映压力的指标。
动手时先把瞬时深度与最老消息年龄一起打点
redis-cli LLEN queue:jobs; redis-cli --eval oldest_age.lua queue:jobs采样间隔调成五秒并保留原始点
python exporter.py --interval 5 --no-aggregate --out metrics.jsonl接着按最老消息年龄设扩容阈值
python autoscale.py --metric oldest_age_seconds --threshold 120 --max-replicas 40回放当时的流量验证能触发扩容
python replay.py --file traffic_1109.jsonl --speed 1别只看报错消失，验证要多做一步。回放同样的峰值流量时扩容在三分钟内触发，最老消息年龄始终低于两分钟，队列深度曲线能看到完整尖峰。
这里还有个坑。队列类指标必须看最老消息的年龄，只看深度会在流量脉冲下彻底失效，采样间隔也要压到秒级。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。