(9.1+) Using the RabbitMQ Management plugin
Virtual Hold's installation of RabbitMQ includes a management plugin. This plugin can be used to manage and monitor RabbitMQ using either a Web user or command-line interface.
The RabbitMQ account is only accessible from the server on which the plugin was installed.
Use Remote Desktop to connect to the server if needed.
You may create additional user accounts through the web UI if remote access is required. Refer to the documentation at https://www.rabbitmq.com/management.html for details.
Logging in to the web-based plugin
- Open a web browser and enter localhost:15672.
- When prompted, enter user "guest" and password "guest".
After logging in, you would see the following information for a High Availability installation if everything is working correctly.
For a standalone installation, the screen would be similar, except only one Node will be represented at the bottom of the page.
Configuring RabbitMQ using the Management plugin
Occasionally, it may be necessary to use the RabbitMQ management plugin to manually delete a queue or exchange to correct the configuration between Virtual Hold and RabbitMQ.
To provide context for the sections below:
- Queue Manager publishes messages to an exchange.
- An exchange is bound to one or more queues, usinga routing key as an addressing mechanism.
- Notification Server subscribes to the queue and receives messages from it.
Exchanges, queues and routing keys are identified using human readable strings. In our implementation, these names are as follows:
- control_exchange
- routing key: workers.any.notification_receiver.any
- queue: component_status
When either Queue Manager or Notification Server start, they will automatically create the exchange. When Notification Server starts, it will automatically create the queue and will bind the exchange to it using the routing key. This should all happen transparently, but if something is misconfigured, manual maintenance can be done using the RabbitMQ management plugin.
Exchange list
- From the main page, click Exchanges on the top navigation bar.
- The Exchanges page lists all configured exchanges. Most (AMQP Default through amqp.topic) are automatically configured by RabbitMQ and are not used by Virtual Hold.
- We are interested in control_exchange.
- Click the exchange name to open the Exchange details page.
Exchange details
- If necessary, an exchange can be deleted from this screen.
- If the "control_exchange" is deleted, then Queue Manager will automatically recreate it. However, the exchange won't be bound to the "component_status" queue, so status messages will not be delivered to Notification Server.
- The exchange can be manually bound from this page.
- Alternatively, the "component_status" queue can be deleted and Notification Server will automatically recreate it and bind the exchange to it.
Queues list
- From the main page, click Queues on the top navigation bar.
- The Queues page lists all configured queues.
- You should see only be one queue, "component_status"
- Click the queue name to open the details page.
Queue details
If necessary, a queue can be deleted from this screen. If the "component_status" queue is deleted, then Notification Server will automatically recreate it and bind the "control_exchange" exchange to it, and subsequent status messages from Queue Manager will be successfully delivered.
No queues?
If everything is working correctly, then the "component_status" queue is created when Notification Server starts, and is automatically deleted when there is no client subscribed to the queue. This happens when there is no Notification Server running, or if the RabbitMQ Server instance on the same host as the active Notification Server is stopped. So, if the Queues page shows that no queue exists, check that Notification Server is running and that all RabbitMQ Servers are running.
Mirroring policy
The "component_status" queue is 'mirrored' across the RabbitMQ cluster. This allows the status message published by Queue Manager running on the active Core Instance host to be received by the active Notification Server running on the Management Instance host.
If Queue Manager and Notification Server are both running, and all RabbitMQ nodes are running, and the exchange/queues/bindings are all configured, but status messages are not being delivered, then the mirroring policy is probably not correctly configured.
This mirroring policy is configured at Virtual Hold installation time. It can be examined from the RabbitMQ Management Plugin by navigating to Admin > Policies.
Configuring the RabbitMQ Management Plugin listening port
If there is a port conflict with the default RabbitMQ Management Plugin configuration, it is possible to change its port number.
- Within the Virtual Hold Technology installation directory, navigate to RabbitMQ Server > rabbitmq.config.
- Open the rabbitmq.config file in a text editor and change the listener configuration item to the desired port number.
You may now navigate to the RabbitMQ web interface using the new port, e.g.http://localhost:55555.
- The RabbitMQ Server must be restarted for the configuration change to take effect.
- This only applies to the local RabbitMQ instance. Each server must be configured individually.
Managing RabbitMQ from the command line
Some of the functionality provided by the Rabbit MQ web-based management plugin is also provided by batch scripts that are installed alongside RabbitMQ. Full documentation for these scripts is available at http://www.rabbitmq.com/manpages.html.
To run these scripts:
- Open a command shell under the RabbitMQ Server installation directory, as shown in the Start menu below:
- Verify the following environment variables are set:
Name | Description |
---|---|
RABBITMQ_CONFIG_FILE | The name of the configuration file, without the .config extension. |
RABBITMQ_CTL_ERL_ARGS | Parameters for the erl command used when invoking rabbitmqctl. |
RABBITMQ_ENABLED_PLUGINS_FILE | This file records explicitly enabled plugins. |
RABBITMQ_LOG_BASE | This base directory contains the RabbitMQ server's log files, unless RABBITMQ_LOGS or RABBITMQ_SASL_LOGS are set explicitly. |
RABBITMQ_MNESIA_BASE | This base directory contains sub-directories for the RabbitMQ server's Mnesia database files, one for each node, unless RABBITMQ_MNESIA_DIR is set explicitly. (In addition to Mnesia files this location also contains message storage and index files as well as schema and cluster details.) |
RABBITMQ_SERVER_START_ARGS | Extra parameters for the erl command used when invoking the RabbitMQ Server. |
rabbitmqctl.bat.cluster_status
This command displays all nodes in the RabbitMQ cluster. Normally, all hosts in the Virtual Hold installation will be represented in the 'running_nodes' list. If not, it is likely that one of the RabbitMQ Server instances is stopped.
rabbitmqctl.bat.list_exchanges
This command displays the exchange list. We expect to see "control_exchange".
rabbitmqctl.bat.list_queues
This command displays the queues list. We expect to see "component_status". The number indicates the number of queued messages. We expect to see 0 here because all messages should be delivered as soon as they are sent.
rabbitmqctl.bat.list_policies
This command displays the mirroring policy, which ensures messages sent on the Core host by Queue Manager can be received on the Management host by Notification Server.
rabbitmq-plugins.bat list
This command displays the enabled rabbitmq plugins. If the web interface is not working, check that you see an uppercase 'E' next to rabbitmq_management.
rabbitmq-plugins.bat enable rabbitmq_management
This command turns on the web interface to rabbitmq. This should happen automatically as part of the installation.
- Once the plugin is enabled, the RabbitMQ server must be restarted for the changes to take effect.
- This only applies to the local RabbitMQ instance. The management plugin must be enabled on each host individually.
Port number for RabbitMQ
The default port number for RabbitMQ for System Management is 5672. You have the option to specify a different port number by setting an environment variable.
Changing the RabbitMQ Port Using an Environment Variable
Follow these steps to add or change the RabbitMQ port using an environment variable:
- Stop all Virtual Hold services on all servers.
- On each server, perform the following:
- Navigate to Start > Settings > Control Panel > System > Advanced > Environment Variables.
- Add a new RABBITMQ_NODE_PORT variable and set the value to the new port number.
- Open a DOS command window and change the directory to x:\Program Files (x86)\Virtual Hold Technology\RabbitMQ Server\rabbitmq_server-X.Y.Z\sbin>.
Be sure to replace the X.Y.Z portion with your current RabbitMQ version (such as 3.4.3).
- Type the following commands:
- rabbitmq-service stop
- rabbitmq-service remove
- rabbitmq-service install
- rabbitmq-service start
- After performing these steps on all servers, you can restart all the Virtual Hold services.More Information
You can find more information for configuring RabbitMQ ports at https://www.rabbitmq.com/configure.html.
Diagnosing RabbitMQ error messages
If RabbitMQ is not running, VHT Callback software will still function, but the System Management UI might not correctly report Queue Manager or Solution status, depending on if the failed RabbitMQ instance is located on the same host as the active Queue Manager or Notification Server. If you suspect there is a problem with RabbitMQ, use the Management Plugin to investigate.
RabbitMQ Notification Server
Symptom | Solution |
---|---|
Queue Manager is sending a status, but Notification Receiver will not receive it. | Start or restart the failed RabbitMQ server on the Management instance |
RabbitMQ Queue Manager
Symptom | Solution |
---|---|
Notification Receiver is listening for a status, but Queue Manager is not sending it. | Start or restart the failed RabbitMQ server on the Core instance. |
RabbitMQ backup Notification Server or QM
Symptom | Solution |
---|---|
Active Queue Manager and Notification Server are unaffected. On a Queue Manager or Notification Server failover, status will not be correctly reported. | Start or restart the failed RabbitMQ server. |