Management Plugin

The rabbitmq-management plugin provides an HTTP-based API for management and monitoring of your RabbitMQ server, along with a browser-based UI and a command line tool, rabbitmqadmin. Features include:

Installation

The management plugin is included in the RabbitMQ distribution. To enable it, use rabbitmq-plugins:

    rabbitmq-plugins enable rabbitmq_management

Windows service users need to take additional steps when changing plugins.

If you wish to build the plugin from source, it can be built like any other. See the plugin development page for more information, but be aware that it seems to be problematic to build rabbitmq-mochiweb on Windows.

Requirements

rabbitmq-management uses the Mochiweb web server which requires a newer Erlang version. At least R13B01 is required, but later versions are recommended.

Getting started

To use the web UI you will need to authenticate as a RabbitMQ user (on a fresh installation the user "guest" is created with password "guest"). From here you can manage exchanges, queues, bindings, virtual hosts, users and permissions. Hopefully the UI is fairly self-explanatory.

The management UI is implemented as a single static HTML page which makes background queries to the HTTP API. As such it makes heavy use of Javascript. It has been tested with recent versions of Firefox, Chromium and Safari, and with versions of Microsoft Internet Explorer back to 6.0.

Permissions

The management plugin extends the existing permissions model somewhat. Users can be given arbitrary tags within RabbitMQ. The management plugin makes use of tags called "management", "monitoring" and "administrator". The following table shows what the different types of user can do:

Tag Capabilities
(None) No access to the management plugin
management Anything the user could do via AMQP plus:
  • List virtual hosts to which they can log in via AMQP
  • View all queues, exchanges and bindings in "their" virtual hosts
  • View and close their own channels and connections
  • View "global" statistics covering all their virtual hosts, including activity by other users within them
monitoring Everything "management" can plus:
  • List all virtual hosts, including ones they could not log in to via AMQP
  • View other users's connections and channels
  • View node-level data such as memory use and clustering
  • View truly global statistics for all virtual hosts
administrator Everything "monitoring" can plus:
  • Create and delete virtual hosts
  • View, create and delete users
  • View, create and delete permissions
  • Close other users's connections

Note that since "administrator" does everything "monitoring" does, and "monitoring" does everything "management" does, you only need to give each user a maximum of one tag.

Normal RabbitMQ permissions still apply to monitors and administrators; just because a user is a monitor or administrator does not give them full access to exchanges, queues and bindings through either AMQP or the management plugin.

All users can only list objects within a particular virtual host if they have any permissions for that virtual host.

If you get locked out due to only having non-administrator users, or no users at all, you can use rabbitmqctl add_user to create a non-administrator user and rabbitmqctl set_user_tags to promote a user to administrator.

Configuration

There are several configuration options which affect the management plugin. These are managed through the main RabbitMQ configuration file.

Note on clustering

The management plugin is aware of clusters. You can enable it on one or more nodes in a cluster, and see information pertaining to the entire cluster no matter which node you connect to.

If you want to deploy cluster nodes which do not have the full management plugin enabled, you will still need to enable the rabbitmq-management-agent plugin on each node.

HTTP API

By default the management plugin will create an HTTP-based API at http://server-name:55672/api/. Browse to that location for more information on the API. For convenience you can read the latest HTTP API documentation on our Mercurial server.

Proxy setup

It is possible to make the web UI available via any proxy that conforms with RFC 1738. The following sample Apache configuration illustrates the minimum necessary directives to coax Apache into conformance. It assumes a management web UI on the default port of 55672:

AllowEncodedSlashes On
ProxyPass        /api http://localhost:55672/api nocanon
ProxyPass        /    http://localhost:55672/
ProxyPassReverse /    http://localhost:55672/