[rabbitmq-discuss] Monitoring Message Throughput

[Matt Todd]

I agree with both Garrett and Gavin with some minor additions:

I think pure throughput should include messages failed to be ack'd and
having to be resent since it is technically output. They could be reported
separately and combined manually for those that don't mind the difference.

I think it would be cool to see something similar to Unix load that reports
on the last minute averages, the last 5 minute's average, and the last 15
minute's average. But, this goes back to the discussion on counters and how
easy it is for us to do this on our end since many tools do this for us
already.

So, in this regard, it would be much more useful for the data to just be
handed back to us whenever we request it as a pure count. Let us do the
hard/interesting work of calculating averages over specific time intervals,
etc.

RE: throughput, I think we should show both enqueued and dequeued throughput
separately, but do definitely want to include both.

Matt



On Sat, Feb 6, 2010 at 4:17 PM, Matthias Radestock <matthias at lshift.net>wrote:

> Nico,
>
> Nico Meyer wrote:
> > are there any good solutions to monitor the message throughput of
> > RabbitMQ? Preferably broken down by queues. I have quickly checked the
> > monitoring solutions on the webpage, but none seem to have that feature.
> > Also there is probably not enough data exported by RabbitMQ to do this.
>
> The closest you can get at the moment is the various socket stats
> reported by 'rabbitmqctl list_connections', but that is clearly quite a
> long way from per-queue message throughput stats.
>
> We will add more stats (and more ways of getting at them) in the future,
> so your input is appreciated in defining what exactly it is that you and
> other users are looking for. So, regarding your specific request ...
>
> By "throughput" do you mean:
> - rate at which messages are enqueued?
> - rate at which messages are dequeued?
>
> If it's "messages enqueued", what happens to messages that are part of a
> transaction? Are they included in the figure immediately or only when
> the tx has committed?
>
> If it's "messages dequeued", what happens to message redeliveries (e.g.
> when a message has been delivered but then the client disconnected w/o
> acking them and the message is subsequently redelivered to another
> client)? Are they included in the figure?
>
> Also,
> - are you interested in message counts, i.e. messages per second, or
> data volumes, i.e. octets per second?
> - over what period of time should the figures be averaged?
> - do the stats of a durable queue need to survive a broker restart?
> - do the stats still need to be accessible after a queue has been deleted?
> - what stats other than per-queue throughputs would you like to see?
>
> I realise these are a lot of questions. But answering them will help us
> shape our future stats architecture.
>
>
> Regards,
>
> Matthias.
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>



-- 
Matt Todd
Highgroove Studios
www.highgroove.com
cell: 404-314-2612
blog: maraby.org

Scout - Web Monitoring and Reporting Software
www.scoutapp.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100210/7a7bdd56/attachment.htm