[rabbitmq-discuss] Monitoring RabbitMQ from JMX

Wed Mar 4 12:39:50 GMT 2009

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