[rabbitmq-discuss] Management plugin preview release
Simon MacMullen
simon at rabbitmq.com
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
More information about the rabbitmq-discuss
mailing list