RabbitMQ 消息问题排查应优先启用 rabbitmq_tracing 插件（3.7+ 内置），结合 CorrelationId 或自定义 header 打标，在 trace 日志中按 SEND/DELIVER/ACK 事件定位断点，并辅以 rabbitmqctl、Prometheus 和 Micrometer 等工具交叉验证。
Java 应用通过 RabbitMQ 发送或消费消息时，若出现消息丢失或延迟，单靠日志和代码排查往往效率低下。启用并正确使用 RabbitMQ 的 message-tracing 插件（现已被官方弃用，推荐改用 firehose + rabbitmq_tracing 或更现代的 prometheus + rabbitmq_exporter），能精准定位消息生命周期中的异常节点——但要注意：它只适用于开发/测试环境，生产环境应优先考虑轻量级可观测方案。
确认插件状态并启用 tracing
RabbitMQ 3.7+ 版本中，rabbitmq_tracing 是内置插件（替代旧版 message-tracing），需手动启用：
- 执行命令：
rabbitmq-plugins enable rabbitmq_tracing - 访问管理界面 → Tracing 标签页 → 点击 Enable tracing，可全局开启或按 vhost/vhost+exchange/routing_key 精细控制
- 注意：开启后所有匹配的消息会写入
trace文件（默认路径：/var/log/rabbitmq/rabbit@xxx-trace.log），磁盘和 I/O 开销明显，切勿长期开启
在 Java 客户端打标便于追踪
单纯开启 tracing 只能看到消息流转路径，但难以关联具体业务请求。建议在发送端为消息添加唯一标识：
- 使用
CorrelationId或自定义 header（如x-msg-id、x-request-id）标记每条消息 - 示例（Spring AMQP）：
MessageProperties props = new MessageProperties();<br>props.setHeader("x-msg-id", UUID.randomUUID().toString());<br>props.setCorrelationId("req-abc123");<br>Message msg = new Message(payload.getBytes(), props); - 消费端记录该 ID，并与 trace 日志中的
msg_id或headers字段对齐，快速定位某次调用的完整链路
解析 trace 日志定位关键断点
trace 日志按时间顺序记录每条消息的关键事件，典型行格式如下：
立即学习“Java免费学习笔记（深入）”；
[2024-05-20 10:23:45.123] SEND to exchange 'order' with routing key 'order.created' → queue 'q.order.process'
[2024-05-20 10:23:45.128] DELIVER from queue 'q.order.process' to consumer 'consumer-001'
[2024-05-20 10:23:47.992] ACK by consumer 'consumer-001'
- 若看到
SEND但无后续DELIVER→ 检查路由规则、队列是否绑定、消息是否被 TTL 或死信策略拦截 - 若有
DELIVER但长时间无ACK→ 消费者处理卡顿、未手动签收、或 autoAck=false 时抛异常未捕获导致消息重回队列 - 若出现
REJECT或REQUEUE→ 查看消费者逻辑是否主动拒绝或配置了defaultRequeueRejected=true
配合其他工具交叉验证
tracing 日志是“快照”，无法反映实时堆积或资源瓶颈。需结合以下手段综合判断：
- 使用
rabbitmqctl list_queues name messages_ready messages_unacknowledged查看队列积压与未确认数 - 开启
rabbitmq_prometheus插件，监控rabbitmq_queue_messages_ready、rabbitmq_queue_ack_latency_seconds等指标 - Java 应用侧加入 Micrometer 埋点，统计
spring.rabbitmq.template.send-and-receive调用耗时与失败率 - 网络层抓包（如
tcpdump -i any port 5672）确认 TCP 连接是否频繁重连或丢包
