Why This Exists

RabbitMQ queue declaration through AMQP is the main entry point for many users, while the API is more centred around operator usage.

Classic mirrored queues are deprecated since version 3.9, and completely removed in RabbitMQ 4.0.

With the plugin, in log mode, you will be able to answer such questions by looking at Prometheus metrics with Grafana, as well as your logs:

• Are my users declaring queues?
• Are the declaration active or passive?
• Are we creating new classic mirrored queues?

With the plugin in enforce mode, you will be able to prevent AMQP queue.declare operations through a standard AMQP error, with configurable options, to:

• Prevent new classic mirrored queues creation
• Prevent exclusive queue creation
• Prevent new classic queue creation
• Let quorum queues creation happen
• Still keep the observability on!

You can figure these by looking at your code, and reconciliation of multiple teams, which is hard to do for an operator, and time consuming for a development team. 

This plugin makes those directly observable, and actionable.

Key Insights

Every queue declaration, traced

The log mode, the primary mode of the plugin, does, in essence, nothing, with a purpose.

As we can see in the logs, it will inspect every queue declaration, and label it. These labels fall in 2 categories: 

• allow conditions — those define the reason why a queue declaration is let through
• enforcement conditions — indicate why a queue would become impossible to declare.

It is, on purpose, not possible to set the plugin into enforce mode without a configuration file option and a restart, as it starts disrupting your queue declarations. It is, however, possible to pause enforcement for a virtual host through its parameters, setting in back in log mode. 

Classic queue, disabled

Because the plugin is not only for reporting on what happens, it also has an enforce mode, in which it will prevent users going through the AMQP queue.declare from creating new classic queues. It uses the standard AMQP error 406, PRECONDITION_FAILED, letting your users know that declaring a queue of that type is not allowed. And because visibility is everything, you get the same observability: metrics will tell you what is happening, and the logs will have the detailed explanations for the operator.

Queue Declaration Insight

The plugin exposes additional metrics, depending on the mode and the configuration options. Check out the docs for details.

When You Might Use It

This plugin becomes useful as soon as you want to migrate off of classic queues:

• You want to verify users are not creating new classic mirrored queues
• You need to confirm where your queue declaration happen
• You want to prevent users from using classic queues altogether
• You need to migrate to RabbitMQ 4.0 and need classic mirrored queues gone

What This Plugin Does

The plugin intercepts every queue.declare AMQP operation, and as such, might conflict with other plugins doing the same. The metrics will be exposed on the core RabbitMQ endpoint, so no additional configuration is required.

The important detail is that everything is node-local except for the virtual host level exception (which is virtual host bound). You will get visibility into what each node does, as they will not broadcast a queue.declare that is prevented.

It is equally important to note that while the AMQP queue.declare is the main entry point into queue declaration for many users, it is not the only possible way to declare a queue. This plugin, however, only focuses on the AMQP declaration route.