rabbitmq——trace

在使用rabbitmq的过程中，难免会出现某条消息异常丢失的情况。出现这种状况的原因可能是因为生产者或消费者与rabbitmq的断链，而它们与rabbitmq又采用了不同的确认机制；也可能是因为exchange与queue之间不同的转发策略，甚至是exchange后没有queue，生产者又不感知或者没有采取相应的措施；另外rabbitmq本身的集群策略也可能导致消息的丢失。这个时候就需要rabbitmq有一个较好的机制跟踪记录消息的投递过程，以此协助开发和运维人员进行问题的定位。

rabbitmq的官网介绍了两种trace的方式，一种称之为“firehose”，另一个是rabbitmq_tracing插件。这两种方式都能对经过rabbitmq的消息进行跟踪记录。

1. firehose

firehose的机制是将生产者投递给rabbitmq的消息，rabbitmq投递给消费者的消息按照指定的格式发送到默认的exchange上。这个默认的exchange的名称为amq.rabbitmq.trace，它是一个topic类型的exchange。发送到这个exchange上的消息的routing key为 publish.exchangename 和 deliver.queuename。其中exchangename和queuename为实际exchange和queue的名称，分别对应生产者投递到exchange的消息，和消费者从queue上获取的消息。

简单使用步骤：

• 通过命令开启firehose

rabbitmqctl trace_on

这个命令还可以通过参数 -p 指定 vhost。

• 创建queue并绑定到exchange（amq.rabbitmq.trace）

这里通过两个routing key收取所有生产者发送的消息和发送给消费者的消息。

• 测试验证

创建一个名为hello的queue，生产者通过默认的exchange——amq.direct发送消息，内容为hello world。

那么可以看到创建的trace-example队列里有两条消息，一条为生产者发送给rabbitmq的消息，一条为消费者从hello队列中消费的消息。

从上面的使用流程可以看出：这种机制可以记录rabbitmq中消息的流入流出情况，但是不够友好的是需要自行创建queue，从queue中取出消息来查看消息的收发情况。

2. rabbitmq_tracing plugin

rabbitmq_tracing插件同样能跟踪rabbitmq中消息的流入流出情况，通过这个插件我们可以在管理界面上进行简单操作，rabbitmq会将消息的收发情况记录到日志中。

简单使用：

• 启用插件

rabbitmq-plugins enable rabbitmq_tracing

• 增加trace

如上图所示，增加两个trace，一个记录所有生产者发送到rabbitmq的消息，一个记录所有消费者消费的消息。

• 测试验证

使用前面创建的queue并发送消息。

点击from_p.log可以看到这样的日志：

日志中记录的是rabbitmq已经接收的来自生产者的消息，具体包括当前节点的名称，exchange的名称，routing key以及具体的消息内容

而to_c.log中可以看到：

这里记录的是消费者从queue中消费的消息。具体包括消息是从哪个exchange发来的，queue的名称，以及消息的内容等等。

注：这个日志里记录的仅仅是rabbitmq发送给消费者的消息，而不管该消息是否需要被确认，或者该消息是否已经被确认。另外没有被消费者消费的消息不会被记录。

通过这样一个例子可以验证这一点：创建一个fanout类型的exchange，创建两个queue并绑定到这个exchange上，其中一个queue上有消费者同时开启ack机制，然后往exchange上发送消息，结果如图所示：

另外，这两个日志默认存储在/var/tmp/rabbitmq-tracing下。

=====================================================

总结，firehose可以理解为rabbitmq提供了接口供远程访问，例如定制开发一个客户端远程连接到rabbitmq上创建队列并绑定到amq.rabbitmq.trace上收取trace的消息并进行处理。而rabbitmq_tracing插件则使用相对方便许多，也能较好的协助运维人员对rabbitmq进行运维。