事后统计发现故障当天降级执行了 4.1 万次，Prometheus 里搜不到任何降级相关指标，值班只看到接口耗时正常，以为没受影响。用户在群里反馈价格不对才被发现。日志里能对上时间点，这种反而好排。
降级写在 catch 块里，只有一行 log.debug，线上日志级别是 info，连日志都没留下。降级没有独立指标，监控只看成功率和耗时。这一点先确认清楚，后面就不用反复试。
curl -s localhost:8081/actuator/prometheus | grep degrade grep -c 'degrade=true' /var/log/app/app.log
「降级无监控」改完先别急着全量，挑一台机器放半天，真有问题这段时间就能看出来。能分两步做的操作就别合成一步，中间看一眼返回值，出问题好判断。
报错里带路径的，先去看那个路径在不在、权限对不对。
处理上按这个顺序：给每个降级分支加一个带接口名的 counter；降级比例超过 5% 持续 2 分钟就发告警；把降级次数打到业务大盘 和成功率放同一行；日志级别改成 warn 并带上失败原因。
结果对不对很好判断，人为打挂下游后 1 分钟内能看到降级计数增长并收到告警，恢复后计数停止上涨。