[rabbitmq-discuss] Monitoring RabbitMQ from JMX

Fri Mar 6 00:13:00 GMT 2009

Carl, Alexis, Ben,

Thank you for your very helpful replies. Unfortunately I haven't been
able to work on this as much as I had hoped this week.

My idea about proxying commands through rabbit_control did not work.
The action functions print to the display instead of returning the
results tuple. However, I am able to connect to the rabbit node
directly from Java and call the functions. This works out to be easier
(one less process to manage).

I totally agree with Ben's suggestion for dividing up this problem. I
can use JInterface for #1, but if I get the abstractions right for #2
and #3 then it should be able to replace #1 with an SNMP layer at a
later date.

I hope to make more progress on this next week. One of my next steps
is to look at what we're currently monitoring and determine if there
are equivalents in Rabbit.

Thanks again for your help. I'll report back when I have something
more substantial.

Thanks,
Chris

On Wed, Mar 4, 2009 at 4:39 AM, Ben Hood <0x6e6562 at gmail.com> wrote:
> Chris,
>
> On Tue, Mar 3, 2009 at 6:40 PM, Chris Pettitt <cpettitt at gmail.com> wrote:
>> I'm currently exploring monitoring options for RabbitMQ. There is a monitoring
>> page on the RabbitMQ site [1] from July 2008 that describes some potential
>> solutions, but it's not clear if anything has been done since that discussion.
>
> Apart from discussing this further (you might want to google threads
> on this list about monitoring), nothing has been done. It is a
> medium-ish priority, but ATM we are very busy at LShift and hence have
> very little time to do anything.
>
>> I'd like to expose monitoring through JMX. Is there anything that does
>> that already
>> or that can be adapted to such a purpose?
>
> As Carl has pointed out, QPid have exposed some functionality via JMX.
> But AFAIK this has not been done for Rabbit.
>
>> If not, I've thought about a few ways I could implement it, but I would be
>> happy to get feedback from the folks on this list. Here are some thoughts:
>>
>> 1. I could write a JMX system to talk to rabbit_amqqueue directly
>> using JInterface.
>> I prototyped this approach successfully, but it seems wrong to depend on the
>> functions in rabbit_amqqueue directly, especially if they are not a public API.
>>
>> 2. I could write a small Erlang process that proxies requests to the action
>> function in rabbit_control. The benefit of this is that rabbit_control
>> aggregates monitoring across several modules and the client is less sensitive
>> to changes to rabbit_amqqueue and other modules. Using an Erlang process is
>> also nice because I wouldn't have to spawn rabbitmqctl for each request. With
>> this solution the JMX system could communicate with the process using either
>> JInterface or pipes (though I prefer the former unless there is a good reason
>> to avoid it).
>>
>> Thoughts? Is there a good alternative I'm missing?
>
> I would divide the problem up into three parts to solve separately:
>
> 1. Define how you want to remote the calls;
> 2. Define what functionality you want to expose;
> 3. Have a look at what internal APIs are available to you and whether
> you can write a wrapper to subsume them;
>
>
> ad 1) Using JInterface seems fine to me;
> ad 2) Tricky - you will limited to what rabbit_amqqueue exposes;
> ad 3) Using rabbit_amqqueue is not evil per se, it's just that it is
> subject to change (explicitly or subtly), so it's something you may
> need to keep in sync. We wouldn't be so-and-so's and deliberately
> break your stuff, but you would have to clear on the fact that
> compatibility would be a best-effort thing rather than a guarantee to
> support stuff going forwards.
>
> Having said all of that, you may get the most mileage out of us were
> you to look into OTP's SMTP capabilities ;-)
>
> HTH,
>
> Ben
>