周一发现 3 天前的通知任务还堆着 31 万条，Prometheus 里只有 worker 存活和任务成功率两个指标，队列长度从来没采集。日志里能对上时间点，这种反而好排。
监控只盯进程是否活着，worker 正常、心跳正常，积压不触发任何告警。队列长度要单独从 broker 拉，没有 exporter 就没有数据。这一点先确认清楚，后面就不用反复试。
rabbitmqctl list_queues name messages consumers redis-cli LLEN celery redis-cli ZCARD delayed_jobs
「队列积压无监控」排查到最后往往是很小的一处差异，前面那些复杂猜测可以先放一放。线上出问题先对时间点，跟发布、备份、任务执行的时刻排一排，能省掉一半功夫。
日志级别临时调高可以，记得改回去，长期开着既占磁盘又掩盖真问题。
处理上按这个顺序：用 rabbitmq_exporter 或 redis_exporter 暴露队列长度；Prometheus 里按队列名做 sum 配一条持续 5 分钟超过 1 万的告警；再加最老消息年龄的指标 比长度更早发现问题；面板按队列拆开看 确认积压能定位到具体队列。
结果对不对很好判断，人为停掉一个消费者 3 分钟后收到积压告警 面板上能看到对应队列的长度曲线。