One thing that would be cool is a counter could be added per queue (at least) that increments per message delivered. �If we could pull that out like queue depth using rabbitmqctl or Alice, it would go a long way to getting deeper metrics into behavior.<br>
<br><div class="gmail_quote">On Tue, Jan 19, 2010 at 2:57 AM, Matthias Radestock <span dir="ltr"><<a href="mailto:matthias@lshift.net">matthias@lshift.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Brian,<br>
<div class="im"><br>
Brian Sullivan wrote:<br>
> I was wondering if there are any good ideas out there for tracking<br>
> message rates on a given cluster (in our use case, it's mostly<br>
> topic-routed messages). �We have been using RabbitMQ for a while now,<br>
> and have been limited to tracking stats via a consumer that effectively<br>
> subscribes to '#' and simply breaks down these stats by topic.<br>
<br>
</div>So the information you are interested in is "average number of messages<br>
per second published, per routing key and time period", correct?<br>
<div class="im"><br>
> This works ok until the message volumes get pretty heavy - the node that<br>
> the client connects to has to be routed all messages on the cluster, and<br>
> this breaks down the scalability model for RabbitMQ - eventually that<br>
> node will be a bottleneck.<br>
<br>
</div>One thing you could do at the AMQP level is introduce stat-collecting<br>
proxies between the publishers and the brokers. Take a look at the<br>
RabbitMQ tracer in src/com/rabbitmq/tools/Tracer.java in the<br>
rabbitmq-java-client repo for an example of a proxy.<br>
<br>
Another route is via the "pluggable exchange types" we have under<br>
development - see the bug22169 branch in the rabbitmq-server hg repo.<br>
That would allow you to define a custom exchange type that works just<br>
like an ordinary topic (or other) exchange but collects stats on<br>
publishes on a per-node basis. In the simplest case this could just dump<br>
a timestamp and routing key to a file, leaving the actual statistics<br>
calculations to some other program. Or, at the other extreme, the custom<br>
exchange could compute per-node stats itself and, furthermore,<br>
participate in the collation of stats from multiple nodes, using the<br>
distributed computing features Erlang puts at your disposal.<br>
<br>
<br>
Regards,<br>
<br>
Matthias.<br>
<br>
_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<a href="http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
</blockquote></div><br>