Configuration of RabbitMQ for Customerdata service and Trace Event Publisher

At this moment we use a publisher subscribe configuration:

Publish/subscribe: deliver a message to multiple consumers. First the Customerdata service or Trace Event Publisher will emit an event(publish) which will be consumed by all the other listeners that are subscribed to this queue.

Configure RabbitMQ through the management user interface:

1. add an Exchange
   1. 

   2. You are free to define a name for the exchange, please consider a functional name that it's clear what this exchange is for.

      Please note that we selected the Virtual host '/'. It is possible to configure multiple Virtual hosts on one RabbitMQ installation(more info). For production environments we would advise not to use multiple Virtual Hosts on one RabbitMQ server for performance reasons.

2. Add a queue
   1. 
   2. You are free to define a name for the queue, please consider a functional name that it's clear what this queue is for.
3. Now bind the Exchange to the queue
   1. 
4. Configure the Customerdata service to use the queue: Configure Customerdata service as Queue Producer
5. When configuring a production environment please see the RabbitMQ - production-checklist for additional settings (the settings above are the minimal settings needed to configure RabbitMQ for the Blueriq Customerdata events).

Clustering and High Availability

RabbitMQ has support for Clustering and high availability. For the Blueriq Customerdata service or the Trace Event Publisher as a publisher to the queue is does not matter how you configure these features on RabbitMQ as long as the Customerdata service can still publish the events to the queue, you as a customer are free to configure these features of RabbitMQ suitable to your requirements.

Information about the RabbitMQ clustering and high availability can be found here:

• RabbitMQ - Clustering
• RabbitMQ - Highly Available (Mirrored) Queues
• RabbitMQ - High availability with Pacemaker and DRBD

How to maintain the queue

Overview

In the RabbitMQ Management interface, go to queues and click on the queue that is just created to gain some insight.
Here you are able to see what is on the queue. It might be possible for messages to have a 'unacked' status. Whenever messages are unacked this means there is no application running that is consuming these messages. Make sure the application that should consume these messages is running.

For more information about troubleshooting see 'How to troubleshoot'

Upgrade

To check if there are any upgrades possible, please check to following page: Upgrade 
Before doing so, consider making a backup

Backup

To create a backup go to the directory where RabbitMQ is installed (RabbitMQ Server\rabbitmq_server-<version>\sbin. From the commandline run rabbitmqctl eval 'rabbit_mnesia:dir().' or go to %APP_DATA%\RabbitMQ\db and backup this folder.
For more information on how to make a backup, please go to: backup

Alerts

There is an option to get alerts/monitoring when something fails with RabbitMQ, this requires some work.
For more information on how to get alerts, please go to: http://www.rabbitmq.com/how.html#management and https://wiki.openstack.org/wiki/OpsGuide-Maintenance-RabbitMQ

How to troubleshoot

Queue does no longer accept messages

By default, RabbitMQ will not accept any new messages when it detects that it's using more than 40% of the available memory. The OS and file system use system memory to speed up operations for all system processes. Failing to leave enough free system memory for this purpose will have an adverse effect on system performance due to OS swapping, and can even result in RabbitMQ process termination.

Information about the RabbitMQ troubleshooting can be found here:

• RabbitMQ troubleshooting

For a problem concerning aggregates, please contact Blueriq support and please ensure sufficient information, like the aggregate / screenshots / log files.

Security settings

RabbitMQ's security is based on authentication and authorization. In other words, users need to have access rights to a queue, and need to have read and/or write permission to work with events on the queue. By default, the guest user that is automatically created when RabbitMQ server first starts up, is prohibited from connecting to the broker remotely; it can only connect over a loopback interface (i.e. localhost). This applies both to AMQP 0-9-1 and to any other protocols enabled via plugins. Any other users you create will not (by default) be restricted in this way.

This means that, customer data service or trace event publisher needs to be added as a user through RabbitMQ's management console.

This newly created user needs to have access to the relevant virtual host, otherwise the connection will be rejected.

Further, this newly created user needs to have access to the relevant exchange, known as topic permission in the management console.

RabbitMQ distinguishes between configure, write and read operations on a resource. The configure operations create or destroy resources, i.e. exchanges and queues, or alter their behaviour. The write operations inject messages into a resource. And the read operations retrieve messages from a resource. Since the customer data service pushes events on a queue the newly created user needs write permission.

In order to perform an operation on a resource the user must have been granted the appropriate permissions for it. In the figure below you can see a user guest that has been granted access to virtual host /, with read and write access to an exchange named CustomerDataService.

Permissions are expressed as a triple of regular expressions - one each for configure, write and read - on per vhost basis. The user is granted the respective permission for operations on all resources with names matching the regular expressions.