[rabbitmq-discuss] Management plugin preview release

Wed Sep 8 11:21:42 BST 2010

On 07/09/10 20:59, Dave Greggory wrote:
> Glad to see this out there. It's great to be able to finally see send/receive
> rates.
>
> Couple of questions.
>
> 1. Across what time frame are Send/receive rates calculated (ie rolling 5 minute
> intervals, etc)?

At the moment they're instantaneous. Yeah, I know that's lame. In the 
future they'll become moving averages of some sort. And there will be 
graphs :)

> 2. Where does this leave the Status plugin? Will that become discontinued or is
> that plugin's functionality complementary to this one? I'm asking because we
> have set up a lot of monitoring based on that plugin's output.

Ultimately I see the management plugin replacing the status plugin. 
However the status plugin is pretty simple and it's hardly taking any of 
our time to keep it working, so I imagine that state of affairs could 
persist for quite a while. I doubt it'll see any development though.

Having said that, if you're using the JSON page generated by the status 
plugin then the management plugin can provide the same stuff with a 
couple of queries, so you'll probably find porting quite easy if you 
want to do that.

> Feature requests:
> Forgive me if these are already there, I haven't installed it yet.
>
> 1. Rabbit MQ App Memory usage, Node Memory allocation, Queue Memory Use
 > 2. Queue stats

Those are all there.

> 3. Ability to clear queues (a la BQL's purge queue<queue-name>)

I hadn't thought of that. I'll add it to the list.

> 4. Importing / exporting broker state (a la BQL)

That seems to be a popular request. It's on the list too.

> 5. Ability to isolate plugin failures from taking down RabbitMQ - (ie run the
> plugin on a single RAM node in a cluster that no apps connect to, but from this
> node monitor the status of other nodes in the cluster)

At the moment the management plugin isn't very sensible in the context 
of clustering, but that will get fixed. I would hope the plugin should 
not be capable of taking down Rabbit though. If it ever does I most 
certainly want to hear about it!

> 6. Configurable permissions to lock down what can be done through the plugin

The short-term plan is to add a superuser bit to define whether users 
can manipulate non-AMQP objects (users / vhosts / permissions) at all. 
For AMQP objects the existing permission  system is used. Would this be 
adequate?

Cheers, Simon

-- 
Simon MacMullen
Staff Engineer, RabbitMQ
SpringSource, a division of VMware