[rabbitmq-discuss] Monitoring A Queue

[Simon MacMullen]

Hi!

On 15/10/12 17:10, Jason Antman wrote:
> I've been examining the JSON results from the management API
> (/api/queues/vhost_name/queue_name), and have come to the following
> conclusions:
> 1) There are no monotonically increasing counters of the number of
> messages in to the queue and number of messages out of the queue.
> Therefore, there's no way for me to figure the rate on an arbitrary time
> scale.

I'm afraid so, yes. message_stats.publish and message_stats.deliver_get 
are an approximation of what you want, but they only count messages from 
currently open channels. This may change in future, we're aware of it as 
a limitation.

But you may be able to get away with using those if your applications 
tend to keep connections open for a long time.

> 2) The "messages" element in the JSON array is the number of messages
> currently sitting in the queue, not a counter of the number that have
> passed through it.

Yes.

> 3) The API does provide backing_queue_status.avg_ingress_rate and
> backing_queue_status.avg_egress_rate. Going by Matthew's post to
> "Monitoring Message Throughput"
> (http://rabbitmq.1065348.n5.nabble.com/Monitoring-Message-Throughput-td17436.html#a17438)

It's worth noting that that thread is quite old - it predates the 
management plugin for a start.

> from February, 2010, I gather that these values are averaged over
> approx. 10 seconds. I'm also assuming that ingress is *every* message
> into the queue, and egress is... *every* message grabbed from the queue,
> regardless of ACK? So even if consumers are not acking any messages,
> this rate will still show them?

Maybe. The trouble is that those stats are maintained by the backing 
queue for its own purposes, they're only coincidentally useful for 
anyone else.

One issue is that the backing_queue_status only counts messages that 
actually make it into the backing queue. Messages can fly through the 
queue and never touch the backing queue if there is an autoack consumer 
ready to receive them.

> Are these correct?
>
> It would be really helpful if someone could explain exactly what
> avg_in/egress_rate and avg_ack_in/egress_rate mean.

Hope this helps.

> I also found some reference to a Ticket 23 (though I don't see any links
> to the RMQ ticketing system) that dealt with monitoring:
> http://grokbase.com/t/rabbitmq/rabbitmq-discuss/10ag2hejbb/ticket-23-new-comment-monitoring-message-throughput

Oh, that was someone who lost control of their ticketing system(!) and 
starting spamming us. Ignore it.

Cheers, Simon

-- 
Simon MacMullen
RabbitMQ, VMware