一、为什么需要消息追踪？
使用MQ时经常会有这样的场景：
生产者成功发送消息，消费者却找不到消息！？
为什么会出现这种消息异常丢失的情况呢？有可能是编码导致的逻辑错误，比如交换机与队列的绑定问题、交换机的转发策略问题；也有可能是不可避免的网络连接问题、集群分布问题…这时便需要一个跟踪消息的机制，来帮我们定位到消息失踪的原因。
在RabbitMQ中，可以使用 Firehose 和 rabbitmq_tracing 插件来进行消息追踪。
缺点：一旦开启，会影响性能
二、Firehose
1、Firehose原理
生产者投递给RabbitMQ的消息、消费者从RabbitMQ取出的消息，都会将这个消息的跟踪信息发送到一个默认的交换机上。
这个默认的交换机名称为 amq.rabbitmq.trace ，这是一个topic类型的交换机；发送到这个交换机上的消息的routingKey为 publish.实际发生投递原消息动作的交换机名称 或者 deliver.实际发生消费原消息动作的队列名称 。
2、Firehose 使用
开启/关闭Firehose 命令
$ rabbitmqctl trace_on [-p /虚拟机名称]
$ rabbitmqctl trace_off [-p /虚拟机名称]虽说核心是amq.rabbitmq.trace交换机，但是我们还需要手动的创建队列，然后与这个默认交换机绑定；想要看到具体的跟踪信息，还要找到我们手动创建的队列，然后在该队列里找到我们想要的跟踪信息。
三、rabbitmq_tracing
rabbitmq_tracing插件相当于Firehose插件的GUI版本。
开启/关闭rabbitmq_tracing命令
$ rabbitmq-plugins enable rabbitmq_tracing
$ rabbitmq-plugins disable rabbitmq_tracing开启插件，重启mq后打开rabbitmq的ui界面
1、format：一般选择text模式方便人去查看；json模式进行base64编码，是方便以后导出用来做程序分析的
2、pattern：用#，表示无论是发起方发送消息还是接收方接收消息，都做记录；用publish.#，表示只记录发起方发送记录；用deliver.#，表示只记录接收方处理记录
