Yes, that&#39;s the information I am looking for.<br><br>I&#39;ll take a look at the proxy stuff, I hadn&#39;t considered that before.� Thanks, Matthias.<br><br>Cheers,<br>Brian<br><br><br><div class="gmail_quote">On Mon, Jan 18, 2010 at 11:57 PM, Matthias Radestock <span dir="ltr">&lt;<a href="mailto:matthias@lshift.net">matthias@lshift.net</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Brian,<div class="im"><br>
<br>
Brian Sullivan wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I was wondering if there are any good ideas out there for tracking message rates on a given cluster (in our use case, it&#39;s mostly topic-routed messages). �We have been using RabbitMQ for a while now, and have been limited to tracking stats via a consumer that effectively subscribes to &#39;#&#39; and simply breaks down these stats by topic.<br>


</blockquote>
<br></div>
So the information you are interested in is &quot;average number of messages per second published, per routing key and time period&quot;, correct?<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
This works ok until the message volumes get pretty heavy - the node that the client connects to has to be routed all messages on the cluster, and this breaks down the scalability model for RabbitMQ - eventually that node will be a bottleneck.<br>


</blockquote>
<br></div>
One thing you could do at the AMQP level is introduce stat-collecting proxies between the publishers and the brokers. Take a look at the RabbitMQ tracer in src/com/rabbitmq/tools/Tracer.java in the rabbitmq-java-client repo for an example of a proxy.<br>


<br>
Another route is via the &quot;pluggable exchange types&quot; we have under development - see the bug22169 branch in the rabbitmq-server hg repo. That would allow you to define a custom exchange type that works just like an ordinary topic (or other) exchange but collects stats on publishes on a per-node basis. In the simplest case this could just dump a timestamp and routing key to a file, leaving the actual statistics calculations to some other program. Or, at the other extreme, the custom exchange could compute per-node stats itself and, furthermore, participate in the collation of stats from multiple nodes, using the distributed computing features Erlang puts at your disposal.<br>


<br>
<br>
Regards,<br><font color="#888888">
<br>
Matthias.<br>
</font></blockquote></div><br>