[rabbitmq-discuss] Monitoring A Queue
simon at rabbitmq.com
Wed Oct 17 14:15:23 BST 2012
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
> 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
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
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.
> 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"
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
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:
Oh, that was someone who lost control of their ticketing system(!) and
starting spamming us. Ignore it.
More information about the rabbitmq-discuss