<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
I've been tasked with monitoring a queue used by two applications,
which are considered black boxes from my point of view (App A puts
messages into a queue, App B consumes them; I have no control over
the code for either app). I need to measure the rate of messages
(messages/second) moving successfully from App A to App B through
the queue. We're concerned with both pileups in the queue (producer
working normally, consumer halted) and lack of new messages
(producer halted). The end result will be a Nagios check plugin,
which alerts when messages/second throughput falls below a given
level, and also produces performance data for graphing.<br>
<br>
I've been examining the JSON results from the management API
(/api/queues/vhost_name/queue_name), and have come to the following
conclusions:<br>
<br>
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.<br>
<br>
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.<br>
<br>
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" (<a
href="http://rabbitmq.1065348.n5.nabble.com/Monitoring-Message-Throughput-td17436.html#a17438"
target="_blank">http://rabbitmq.1065348.n5.<wbr>nabble.com/Monitoring-Message-<wbr>Throughput-td17436.html#a17438</a>)
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? And I assume
that means these values wouldn't be useful for a low-utilization,
bursty queue (i.e., say, a 30-message burst every few minutes)?<br>
<br>
Are these correct?<br>
<br>
It would be really helpful if someone could explain exactly what
avg_in/egress_rate and avg_ack_in/egress_rate mean in the JSON
output - I've done a bunch of testing with a Pika client connected
to RabbitMQ 2.8.7 on my workstation, but I can't seem to draw a
clear connection between what my client is doing and what
avg_ingress_rate and avg_egress_rate show in the JSON, or what the
avg_ack_[in|e]gress_rate show, when I watch everything
simultaneously. <br>
<br>
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, but
no reference to any updates to it:<br>
<a
href="http://grokbase.com/t/rabbitmq/rabbitmq-discuss/10ag2hejbb/ticket-23-new-comment-monitoring-message-throughput"
target="_blank">http://grokbase.com/t/<wbr>rabbitmq/rabbitmq-discuss/<wbr>10ag2hejbb/ticket-23-new-<wbr>comment-monitoring-message-<wbr>throughput</a><br>
<br>
Any guidance/advice/pointers would be greatly appreciated. I've been
working on this monitoring for two days now, and I can't find
anything that I'm confident is a correct solution...<br>
<br>
Thanks,<br>
Jason Antman<br>
</body>
</html>