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:

  • Declare, list and delete exchanges, queues, bindings, users, virtual hosts and permissions.
  • Monitor queue length, message rates globally and per channel, data rates per connection, etc.
  • Monitor resource usage, such as file descriptors, memory use, available disk space.
  • Manage users (provided administrative permissions of the current user).
  • Export and import object definitions (vhosts, users, permissions, queues, exchanges, bindings, parameters, policies) to JSON.
  • Force close connections, purge queues.
  • Send and receive messages (useful in development environments and for troubleshooting).

Getting started

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

rabbitmq-plugins enable rabbitmq_management
  • The Web UI is located at: http://server-name:15672/
  • The Web UI uses an HTTP API provided by the same plugin. Said API's documentation can be accessed at http://server-host:15672/api/ or our latest HTTP API documentation here).
  • Download rabbitmqadmin at: http://server-name:15672/cli/

NB: The port for RabbitMQ versions prior to 3.0 is 55672.

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.


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", "policymaker", "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
policymaker Everything "management" can plus:
  • View, create and delete policies and parameters for virtual hosts to which they can log in via AMQP
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 "policymaker" and "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 frequently 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.


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

HTTP API can be used on any node that has the rabbitmq-management plugin enabled. It then will be able to provide metrics on any (or all) cluster node. When monitoring a cluster of nodes, there is no need to contact each node via HTTP API individually. Instead, contact a random node or a load balancer that sits in front of the cluster.

For HTTP API clients in several languages, see Developer Tools.

rabbitmqadmin is a Python command line tool that interacts with the HTTP API. It can be downloaded from any RabbitMQ node that has the management plugin enabled, see http://server-name:15672/cli/


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

Load definitions at startup

The management plugin lets you export a JSON file containing definitions of all broker objects (queues, exchanges, bindings, users, virtual hosts, permissions and parameters). In some scenarios it may be useful to ensure the existence of these objects at every startup.

To do this, set the load_definitions variable to the path of a previously exported JSON file containing the definitions you want.

Note that the definitions in the file will overwrite anything already in the broker; using this option will not delete anything that is already there. However, if you start from a completely reset broker, use of this option will prevent the usual default user / virtual host / permissions from being created.

Message rates

The management plugin by default shows message rates globally, and for each queue, channel, exchange, and vhost. These are known as the basic message rates.

It can also show message rates for all the combinations of channel to exchange, exchange to queue, and queue to channel. These are known as detailed message rates. Detailed message rates are disabled by default as they can have a large memory footprint when there are a large number of combinations of channels, queues and exchanges.

Alternatively, the message rates can be disabled altogether. This can help get the best possible performance out of a CPU-bound server.

The message rate mode is controlled by the rates_mode configuration variable in rabbitmq_management. This can be one of basic (the default), detailed or none.

Statistics interval

By default the server will emit statistics events every 5000ms. The message rate values shown in the management plugin are calculated over this period. You may therefore want to increase this value in order to sample rates over a longer period, or to reduce the statistics load on a server with a very large number of queues or channels.

In order to do so, set the value of the collect_statistics_interval variable for the rabbit application to the desired interval in milliseconds and restart RabbitMQ.

HTTP request logging

To create simple access logs of requests to the HTTP API, set the value of the http_log_dir variable in the rabbitmq_management application to the name of a directory in which logs can be created and restart RabbitMQ. Note that only requests to the API at /api are logged, not requests to the static files which make up the browser-based GUI.

Events backlog

Under heavy load, the processing of statistics events can increase the memory consumption. To reduce this, the maximum backlog size of the channel and queue statistics collectors can be regulated. The value of the stats_event_max_backlog variable in the rabbitmq_management application sets the maximum size of both backlogs. Defaults to 250.


An example configuration file for RabbitMQ that switches on request logging, increases the statistics interval to 10000ms and explicitly sets some other relevant parameters to their default values, would look like this:

  {rabbit,                    [ {tcp_listeners,               [5672]},
                                {collect_statistics_interval, 10000} ] },
  {rabbitmq_management,       [ {http_log_dir,  "/tmp/rabbit-mgmt"},
                                {rates_mode,    basic}] }

Configuring the HTTP listener

It is possible to configure rabbitmq-web-dispatch to serve the management plugin on a different port or network interface, with SSL, etc. To do so, you should configure the listener configuration item; for example to change the port:

  {rabbitmq_management, [{listener, [{port, 12345}]}]},

or to make the management plugin use HTTPS:

  [{listener, [{port,     15671},
               {ssl,      true},
               {ssl_opts, [{cacertfile, "/path/to/cacert.pem"},
                           {certfile,   "/path/to/cert.pem"},
                           {keyfile,    "/path/to/key.pem"}]}

See the rabbitmq-web-dispatch guide for more details.

Sample retention policies

The management plugin will retain samples of some data such as message rates and queue lengths. You can configure how long such data is retained.

      %% List of {MaxAgeInSeconds, SampleEveryNSeconds}
      [{global,   [{605, 5}, {3660, 60}, {29400, 600}, {86400, 1800}]},
       {basic,    [{605, 5}, {3600, 60}]},
       {detailed, [{10, 5}]}]

There are three policies:

  • global - how long to retain data for the overview and virtual host pages
  • basic - how long to retain data for individual connections, channels, exchanges and queues
  • detailed - how long to retain data for message rates between pairs of connections, channels, exchanges and queues (as shown under "Message rates breakdown")
This configuration (which is the default) retains global data at a 5 second resolution (sampling happens every 5 seconds) for 10 minutes and 5 seconds, then at a 1 minute resolution for 1 hour and 1 minute, then at a 10 minute resolution for about 8 hours. It retains basic data at a 5 second resolution for 1 minute and 5 seconds, then at a 1 minute resolution for 1 hour, and detailed data only for 10 seconds.

Cross-origin resource sharing (CORS)

The management API will by default not allow access to websites hosted on different origins. Allowed origins must be explicitly white-listed in configuration.

    [{cors_allow_origins, ["", ""]}]},

It is possible to allow any origin to use the API. It is however not recommended if the API is reachable from the outside world.

    [{cors_allow_origins, ["*"]}]},

The CORS pre-flight requests are cached by the browser. The management plugin defines a timeout of 30 minutes by default. You can modify this value in the configuration. It is defined in seconds.

    [{cors_allow_origins, ["", ""]},
     {cors_max_age, 3600}]},

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.

When clustered the management plugin performs cluster-wide queries which means it can be affected by various network events such as partitions.

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 15672:

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

Restarting Statistics Database

Statistics database is stored entirely in memory. All of its contents is transient and should be treated as such. Prior to version 3.6.7 stats database is stored on a single node. Starting from version 3.6.7, each node has its own statistics database containing a fraction of stats recorded on this node. It is possible to restart the stats database.

The statistics database is stored in the memory of the stats process previously to RabbitMQ 3.6.2, and stored in ETS tables from RabbitMQ 3.6.2. To restart the database with versions earlier than 3.6.2, use

rabbitmqctl eval 'exit(erlang:whereis(rabbit_mgmt_db), please_terminate).'
Starting with RabbitMQ 3.6.2 and up to 3.6.5, use
rabbitmqctl eval 'supervisor2:terminate_child(rabbit_mgmt_sup_sup, rabbit_mgmt_sup),
These commands must be executed on the node hosting the database. Starting with RabbitMQ 3.6.7, the database can be reset per node using
rabbitmqctl eval 'rabbit_mgmt_storage:reset().'
To reset entire management database on all nodes
rabbitmqctl eval 'rabbit_mgmt_storage:reset_all().'
There is also HTTP API endpoints to reset a database For entire database
  DELETE /api/reset
For a single node
  DELETE /api/reset/:node

Memory Management

The memory usage of the management database can be obtained with rabbitmqctl:
rabbitmqctl status
or a GET request to /api/nodes/name via the HTTP API.

Stats are emitted periodically, regulated by the statistics interval described above, or when certain components are created/declared (e.g. a new connection or channel is opened, or a queue declared) or closed/deleted. Message rates do not directly affect management database memory usage.

Total amount of memory consumed by the stats database depends on the event emission interval, effective rates mode and retention policies.

Increasing the rabbit.collect_statistics_interval value to 30-60s (note: the value should be set in milliseconds, e.g. 30000) will reduce memory comsuption for systems with large amounts of queues/channels/connections. Adjusting retention policies to retain less data will also help.

The memory usage of the channel and stats collector processes can be limited by setting the maximum backlog queue size using the parameter stats_event_max_backlog. If the backlog queue is full, new channel and queue stats will be dropped until the previous ones have been processed.

The statistics interval can also be changed at runtime. Doing so will have no effect on existing connections, channels or queues. Only new stats emitting entities are affected.

rabbitmqctl eval 'application:set_env(rabbit, collect_statistics_interval, 60000).'

The statistics database can be restarted (see above) and thus forced to release all memory.