Yes, that's the information I am looking for.<br><br>I'll take a look at the proxy stuff, I hadn'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"><<a href="mailto:matthias@lshift.net">matthias@lshift.net</a>></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'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 '#' and simply breaks down these stats by topic.<br>
</blockquote>
<br></div>
So the information you are interested in is "average number of messages per second published, per routing key and time period", 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 "pluggable exchange types" 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>