In the previous article we looked at the installation and basic configuration of RabbitMQ. In this article we will look in more detail at the Management Portal.
The RabbitMQ management plugin provides a browser based user interface to administer the message broker as-well as a HTTP-based API for management and monitoring of your RabbitMQ server.
The management plug-in 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.
- Send and receive messages.
- Monitor Erlang processes, file descriptors, memory use.
- Export / import object definitions to JSON.
- Force close connections, purge queues.
The management portal is split into different screens that are selectable with the menu bar at the top of the screen. The first screen you will see is the overview page. This acts as a dashboard view showing you how many messages are in the broker, and the message throughput rate.
This screen is useful to have up on a large display so you can see at a glance how RabbitMQ is performing. If, for example, any of your message consumer applications go down, you will start to see a large buildup of undelivered messages which is a good indication that something has gone wrong.
In the image above, you can see on the overview screen that 1 messages was placed onto the queue at 10:49.00. In the chart below this you can see the message rates which is split into Published messages, Delivered messages, Redelivered messages, Acknowledged messages and Delivered messages where no acknowledgement was required.
The next tab in the management portal is the connections page. When you have consumer applications connecting to RabbitMQ to process messages, they will show up here as connections. A connection represents a real TCP connection to the message broker, where as a channel, which we will see in a moment, is virtual connection inside the connection. This means you can use as many virtual connections (channels) as you want inside your application without overloading the message broker with TCP connections.
The next screen in the management portal is a screen to view the active message broker channels. Some applications need multiple connections to a RabbitMQ broker server. However, it is undesirable to keep many TCP connections open at the same time because doing so consumes system resources and makes it more difficult to configure firewalls. RabbitMQ connections are multiplexed with channels that can be thought of as “lightweight connections that share a single TCP connection”.
For applications that use multiple threads / processes for processing, it is very common to open a new channel per thread/process and not share channels between them.
Communication on a particular channel is completely separate from communication on another channel, therefore every RabbitMQ method also carries a channel number that clients use to figure out which channel the method is for (and thus, which event handler needs to be invoked, for example).
The next screen in the management portal is the exchanges views. This gives you a list of all the current defined exchanges on the server as well as the type of exchange and details such as indicating if they are durable or not.
Exchanges are AMQP entities where messages are sent in the message broker. Exchanges take a message and then route it to zero or more queues. The type of routing depends on the exchange type used and different exchange rules called bindings.
Each exchange is also declared with a number of different attributes. The most important attributes to us are:
- Name: The name of the exchange.
- Durability: This flag determines whether messages sent to the exchange survive a broker / server restart by persisting the messages to disc.
- Auto-delete: This flag determines if the exchange is deleted when all queues have finished using it.
- Arguments: These are message broker dependent.
The types of exchanges supported are Direct, Fanout, Topic, and Headers. These were previously discussed in the chapter on the AMQP messaging standard.
If you click on any of the exchanges in the list you will be taken into a screen that shows more information about that particular exchange. This includes information about the messaging rate for the exchange and the binding information.
In the preceding screenshot you can see details of the bindings for this exchange. For the exchange named “Topic_Exchange” there are 2 queues that are bound to it. One of the queues has a routing key of “payment.card” and the other queue has a routing key of “payment.purchaseorder”. From this screen you can manually bind other queues to the exchange or unbind current queues.
The next screen in the management portal is the queues view. This screen lists all the queues that are defined on the server. From the screen you can also add new queues. This screen is useful as a dashboard to show you what is going on at the queue level. You can see when queues are idle and the status of messages in the queue, such as if they are ready for consumption, whether they have been acknowledged etc.
Just as with the exchanges screen you can also click on any individual queue to see that status of that queue individually. This will give you a view similar to that seen in the following screen shot where you can look at the message rate and what exchanges that queue is bound too.
To create a new user, you go to the ‘Add a user’ section on the screen, as shown in the preceding screen shot, and add a new username and password. You can then set a series of comma separated list of tags to apply to the user. The tags that are currently supported by the management plug-in are:
- management: User can access the management plugin.
- policymaker: User can access the management plugin and manage policies and parameters for the vhosts they have access to.
- monitoring: User can access the management plugin and see all connections and channels as well as node-related information.
- administrator: User can do everything monitoring can do, manage users, vhosts and permissions, close other user’s connections, and manage policies and parameters for all vhosts.
You can set any tag here but the above four tags are just for convenience. Once a user has been created you have to then set permissions for that user. When a RabbitMQ client connects to a RabbitMQ server, it specifies a virtual host within which it intends to operate. A first level of access control is enforced at this point, with the server checking whether the user has any permission to access the virtual hosts, and rejecting the connection attempt otherwise.
For the purposes of the examples in this series we will be using the default virtual host. For more information about virtual hosts and their permissions, you can read more on the RabbitMQ website for Access Control.
In the next article we will take a look at configuring RabbitMQ from the command line.