直接看messages_ready值，它是真正“等着被消费”的消息数，是积压的核心指标；用rabbitmqctl list_queues name messages_ready messages_unacked可快速查积压总数，其中messages_ready为纯积压，messages_unacked为已投递未确认；若某队列messages_ready持续＞5000需介入，＞10000即严重积压；web界面queues页的ready列可排序定位高堆积队列，详情页中consumers为0且ready高表明消费者异常；http api get /api/queues/%2f/my_queue返回json含messages_ready和consumers字段，可用于自动告警；积压是症状而非故障，须结合趋势分析根因，而非仅清队列或重启。
直接看 messages_ready 值，它代表真正“等着被消费”的消息数，是积压的核心指标。
用 rabbitmqctl list_queues 快速查积压总数
这是最常用、无需额外工具的命令行方式：
-
rabbitmqctl list_queues name messages_ready messages_unacked—— 只显示关键三列，避免信息干扰 -
messages_ready是重点：它 = 当前排队等待投递的消息数，即“纯积压” -
messages_unacked是已投递给消费者但还没收到ack的消息，不算积压，但若长期不归零，说明消费者卡住或崩溃了 - 如果某队列
messages_ready持续 > 5000，就得介入；> 10000 就算严重积压，别等告警
在 Web 管理界面里定位积压和消费者状态
打开 http://<your_host>:15672</your_host> 后：
RabbitMQ 4.2.3
下载
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
- 进
Queues页面，表头默认就含Ready列（对应messages_ready），点击可升降序快速找出堆积最高的队列 - 点进具体队列详情页，在
Consumers区域看是否有活跃消费者；若Consumers显示0，而Ready很高，基本就是消费者挂了或没启起来 - 右上角的
Message rates图表里，对比Publish rate和Deliver rate：如果前者远高于后者，且Ready持续上涨，说明消费端明显跟不上
用 HTTP API 获取结构化数据做自动判断
适合集成进监控脚本或告警逻辑：
- GET 请求
http://localhost:15672/api/queues/%2f/my_queue（%2f是 vhost/的 URL 编码） - 响应 JSON 中直接取
messages_ready和consumers字段 - 注意认证：默认账号密码是
guest/guest，生产环境必须改掉，否则 API 调用会失败 - 示例判断逻辑：
if messages_ready > 1000 and consumers == 0→ 触发“无消费者+积压”紧急告警
容易被忽略的是：积压本身不是故障，而是症状。只清队列（rabbitmqctl purge_queue）或重启服务，不解决消费者处理慢、下游超时、反序列化失败这些根因，几分钟后又会堆满。盯住 messages_ready 的变化趋势，比单次快照更有价值。
