[rabbitmq-discuss] Management API and monitoring

[Jason McIntosh]

Just found this older post:
http://rabbitmq.1065348.n5.nabble.com/Monitoring-Message-Throughput-td17436.html

So looks like the avg_ingress_rate is over 5 seconds would get me what I'm
looking for - that should probably never be 0 if we're regularly having
publishes.  Of course I'll have to poll it every 5 seconds or it could be 0
on occasion.

Jason


On Fri, Oct 25, 2013 at 2:00 PM, Jason McIntosh <mcintoshj at gmail.com> wrote:

> Hrmm, looking at the API's now,
>
>    - incoming:
>    [
>       -
>       {
>          - stats:
>          {
>             - publish: 44,
>             - publish_details:
>             {
>                - rate: 0.4
>                }
>             },
>          - exchange:
>          {
>             - name: "phi",
>             - vhost: "phi"
>             }
>          }
>       ],
>
> Is the publish details time delayed?  e.g. for the last "5 minutes" or how
> is that reset?  I don't see a "published since" kinda of field that would
> let me calculate a rate of incoming message flow.  I can image that's a
> "transactions per minute" kinda rate, but that'll never hit 0 if the queue
> received one message since the beginning of time and nothing since.
>
> Now I did see this:
>
>    - backing_queue_status:
>    {
>       - q1: 0,
>       - q2: 0,
>       - delta:
>       [
>          - "delta",
>          - 0,
>          - 0,
>          - 0
>          ],
>       - q3: 0,
>       - q4: 0,
>       - len: 0,
>       - pending_acks: 0,
>       - target_ram_count: "infinity",
>       - ram_msg_count: 0,
>       - ram_ack_count: 0,
>       - next_seq_id: 71,
>       - persistent_count: 0,
>       - avg_ingress_rate: 0,
>       - avg_egress_rate: 0,
>       - avg_ack_ingress_rate: 0,
>       - avg_ack_egress_rate: 0,
>       - mirror_seen: 0,
>       - mirror_senders: 1
>       },
>
>
> Is the next_seq_id used perhaps?  I COULD store the previous value and if
> the value hasn't changed in 5 minutes on the monitoring side, alert on
> that, assuming that that changes based upon each message received?
>
> SO also going to release this:
> https://github.com/jasonmcintosh/rabbitmq-zabbix
>
> This is built off of some of the other monitoring stuff I've been working
> on, but focused on zabbix.  The code gives an example template that (to me)
> is a pretty solid set of monitoring items for each server, auto-discovery,
> and basic stuff to monitor rabbitmq using zabbix.  Eventually, I'd like to
> do a more push vs. pull type system, using zabbix_sender and a background
> process that regularly polls the API (perhaps even a plugin if I can learn
> enough erlang) and submits data to zabbix, instead of zabbix polling the
> server.
>
> Jason
>
>
>
> On Fri, Oct 25, 2013 at 3:59 AM, Simon MacMullen <simon at rabbitmq.com>wrote:
>
>> On 24/10/2013 5:48PM, Jason McIntosh wrote:
>>
>>> The question I have is on the queue - I'd like to be able to monitor
>>> when the queue was last "accessed" for message publishes.
>>>
>>
>> Probably your best bet is to look at the inbound message rate from the
>> mgmt API.
>>
>>
>>  I was looking
>>> at the idle_since but it looks like the date there gets reset anytime
>>> you even look at the list of queues.
>>>
>>
>> That reports on the last time anything contacted the queue to wake it up
>> - this would include publishing, consuming, (re)declaring, or listing it
>> with rabbitmqctl (not mgmt).
>>
>>
>>  One interesting thing I noticed while working on monitoring.
>>>   rabbitmqctl does not seem like a very efficient mechanism for use by
>>> monitoring tools.  I started off using ctl to get various queue and
>>> server information and found that it was extremely expensive to call
>>> repeatedly.  I tried using some python scripts to hit the management API
>>> and my CPU load went down by about 70%.  Not sure if other people have
>>> seem the same using rabbitmqctl?
>>>
>>
>> This is expected. rabbitmqctl and the management API have quite different
>> designs - in brief the management API maintains a database of current stats
>> for everything that's going on, based on stats events emitted by queues,
>> channels and connections. On the other hand when rabbitmqctl wants to know
>> something it just goes and asks the queue / channel / connection directly -
>> so it's a much simpler design but not as performant.
>>
>> Cheers, Simon
>>
>> --
>> Simon MacMullen
>> RabbitMQ, Pivotal
>>
>
>
>
> --
> Jason McIntosh
> https://github.com/jasonmcintosh/
> 573-424-7612
>



-- 
Jason McIntosh
https://github.com/jasonmcintosh/
573-424-7612
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20131025/e865adcd/attachment.htm>