Introduction

RabbitMQ is an open source message broker software that implements the Advanced Message Queueing Protocol (AMQP). RabbitMQ server is written in the Erlang programming language.

The basic architecture of a message queue is simple:

1. Client applications called producers create messages and publishes them to an exchange on a Rabbit.
2. An exchange accepts messages from the producer application and routes them to message queues. The exchange takes the routing decision by taking different message attributes into accoun, such as routing key, depending on the exchange type.
3. Bindings have to be created from the exchange to queues. The exchange routes the message into the queues, depending on message attributes such as routing keys and bindings.
4. The messages stay in the queue until other applications, called consumers, connect to that queue and subscribe to the messages.

5. The consumer(s) subscribes to the messages.

Figure 1 : Architecture of a RabbitMQ server

A RabbitMQ Cluster connects multiple nodes to form a single logical broker. Virtual hosts, exchanges, queues, bindings, users and permissions are mirrored across all nodes in a cluster.

Typically, a publisher sends a message to any node in the cluster. The message is then added to a queue attached to that node. By default, contents of a queue within a RabbitMQ cluster are located on a single node (the node on which the queue was declared). This is in contrast to exchanges and bindings, which can always be considered to be on all nodes. Queues can optionally be made mirrored across multiple nodes. Each mirrored queue consists of one master and one or more mirrors. The master is hosted on one node commonly referred as the master node. Each queue has its own master node. All operations for a given queue are first applied on the queue's master node and then propagated to mirrors. This involves enqueueing publishes, delivering messages to consumers, tracking acknowledgments from consumers and so on.

Messages published to the queue are replicated to all mirrors. Consumers are connected to the master regardless of which node they connect to, with mirrors dropping messages that have been acknowledged at the master.

The high availability of queues and messages and the balancing of load across workers are some of the reasons why RabbitMQ clusters are widely used in mission-critical environments today. In such environments, the sudden unavailability of the cluster, irregularities in load balancing across nodes in the cluster, and slowness in delivery of messages by queues, can significantly delay inter-application communication, badly hit user productivity, and negatively impact both user experience and revenue. To avoid this, administrators must closely monitor the availability and overall performance of the RabbitMQ cluster and its core components, proactively detect anomalies, and promptly initiate measures to pre-empt them. This is where eG Enterprise helps!

eG Enterprise is capable of monitoring RabbitMQ clusters out-of-the-box. eG's intelligent agents can instantly detect and promptly alert administrators to issues in the availability, status, and performance of a cluster as a whole and also of individual nodes, exchanges, queues, and virtual hosts in the cluster. This topic details how eG Enterprise monitors the RabbitMQ cluster and what metrics it reports.