CloudAMQP Diagnostics

This feature is available on dedicated instances

The Diagnostics tool helps you identify common errors in RabbitMQ. The tool will check your setup and give you suggestions of things to improve. For most use cases, you should aim to have 100% on all these tests. However, there are cases when breaking some rules is necessary. Expand any rule to get a more detailed description.

General

Running latest RabbitMQ version

This section verifies that you are running the latest recommended version of RabbitMQ.

When your server is running the latest recommended RabbitMQ version.
When your server is not running the latest recommended RabbitMQ version.

Why is an updated RabbitMQ version important?

RabbitMQ is improving all the time, bugs are fixed and new features are added. We recommend that you always keep RabbitMQ up to date.

How to proceed

The RabbitMQ version can be updated from the CloudAMQP console by clicking the Update RabbitMQ button on the instance Nodes page.


Running latest Erlang version

This section verifies that you are running the latest version of Erlang.

When your server is running the latest recommended Erlang version.
When your server is not running the latest recommended Erlang version.

Why is an updated Erlang version important?

Performance and reliability in Erlang are improving with each new version. We recommend that you always keep Erlang up to date.

How to proceed

The Erlang version can be updated from the CloudAMQP console by clicking the Upgrade Erlang button on the instance Nodes page.


Rate mode not set to "detailed"

This section verifies that your server has RabbitMQ Management statistics rate mode set to something other than detailed.

RabbitMQ Management statistics management.rates_mode is not set to detailed
RabbitMQ Management statistics management.rates_mode is set to detailed

Why shouldn't detailed management.rates_mode be used in production?

The management.rates_mode in the RabbitMQ management console is all about how the queues report statistics, such as message rates and queue lengths. Setting RabbitMQ Management statistics management.rates_mode = detailed has a serious performance impact and should not be used in production.

How to proceed

Send us an email at support@cloudaqmp.com to change rate_mode. Check out the official RabbitMQ Management Plugin - Message Rates documentation to learn more.


Limited number of Exchanges

This section verifies that your server has a normal amount of Exchanges. The recommended limit is less than 100 Exchanges per vhost (virtual host).

The RabbitMQ server has a healthy number of Exchanges.
The RabbitMQ server more Exchanges than recommended.

Why should we not have a lot of Exchanges?

Having lots of exchanges is not the best practice use of RabbitMQ.

How to proceed

You may want to use topics instead of many different exchanges. Reach out to support@cloudaqmp.com, we can help you look at your setup.


Not using Topic Exchange as Fanout

This section verifies that RabbitMQ is not using a Topic Exchange as a Fanout Exchange.

The server is not using a Topic Exchange as a Fanout Exchange.
The server is probably using a Topic Exchange as a Fanout Exchange.

Why should we not use the Topic Exchange as a Fanout Exchange?

Fanout Exchanges are ideal for broadcasting messages to all queues, since they are optimized for that purpose. With Fanout Exchange no routing key nor matching logic is required which in turn leads to better performance.

How to proceed

Use Fanout Exchange instead of using Topic Exchange with only '#' bindings.


Limited number of Exchanges

This section verifies that your server has a normal amount of Exchanges. The recommended limit is less than 100 Exchanges per vhost (virtual host).

The RabbitMQ server has a healthy number of Exchanges.
The RabbitMQ server more Exchanges than recommended.

Why should we not have a lot of Exchanges?

Having lots of exchanges is not the best practice use of RabbitMQ.

How to proceed

You may want to use topics instead of many different exchanges. Reach out to support@cloudaqmp.com, we can help you look at your setup.


All published messages are routed successfully

This section verifies that you have a working message flow.

All published messages are routed successfully.
You have more incoming than delivered messages. All published messages are not routed.

How to proceed

Start by checking your bindings, as unrouted messages might indicate missing bindings. Another option is to collect unroutable messages with the help of an Alternate Exchange.


High Availability-policy (HA) on all vhosts

This section verifies if you have HA-policies on all vhosts.

HA-policy is available on all vhosts.
HA-policy is missing on at least one vhost.

Why should we have an HA-policy on all vhosts?

Not having an HA-policy on all vhosts will cause message loss on netsplits. You should add a HA policy on custom vhosts even if you only have one node to be able to do upgrades without message loss.

How to proceed

Add a High Availability (HA) policy on all custom vhosts.


Queues

Only short queues

This section verifies that the length of your queues is not too long.

All queues are short.
One or many queues on your RabbitMQ server are too long.

Why should we have short queues?

RabbitMQ performs best if queues are short. If it suits your use case, try keeping queues as short as possible. We recommend less than 10,000 messages in all queues.

How to proceed

Add more consumers or scale up your system if you can’t keep your queues short. Enable lazy queues if you run batch jobs.


No unused Queues

This section verifies whether there are unused Queues or not.

All Queues on the server are being used.
You have unused Queues.

Why should we not have unused queues?

Even unused queues take up some resources such as queue index, management statistics, etc. Make sure that you don't leave unused queues left behind.

How to proceed

Remove Queues that are not in use.


Temporary Queues should be auto-deleted

This section verifies if temporary Queues are auto-deleted, meaning that a Queue that with a minimum of one historic Consumer is deleted when the last Consumer unsubscribes.

All temporary Queues on the server are marked as auto-deleted Queues.
You have temporary Queues that are not automatically deleted.

Why should temporary queues be auto-deleted?

Temporary queues that are not deleted after usage might end up as unused Queues. Leaving temporary Queues (unused Queues) can eventually cause RabbitMQ to run out of memory.

How to proceed

Set temporary queues as auto-delete, exclusive or auto-expire.


Persistent messages in durable queues

This section verifies if messages are sent as persistent messages to durable queues.

All persistent messages sent are routed to durable queues.
You have sent transient messages to durable Queues, or persistent messages to Queues that are not durable.

Why should persistent messages be sent to durable queues?

Not sending persistent messages to durable queues can result in message loss during a server restart. Having durable queues with transient messages can be a client error.

How to proceed

Set the persistent flag when publishing otherwise messages will be lost on restart.


No mirrored auto-delete Queues

This section verifies that there are no mirrored auto-deleted Queues.

There are no mirrored auto-deleted Queues.
Your server has at least one mirrored Queue that is configured as an auto-deleted Queue.

Why shouldn't auto-deleted Queues be mirrored?

Mirroring auto-delete queues is probably unnecessary unless you have a very specific use case for it.

How to proceed

Remove the mirroring from the auto-deleted Queue, or remove the auto-delete configuration.


No transient messages in mirrored queues

This section verifies that you are not sending transient messages to mirrored Queues. Publishing transient messages to mirrored queues can be a client error.

You are not sending transient messages to mirrored queues.
You are sending transient messages to mirrored queues.

Why should I not send transient messages into mirrored queues?

Sending transient messages into mirrored queues is probably unnecessary unless you have a very specific use case to do so.

How to proceed

Remember to set the persistent flag when publishing a message.


All replicated queues are Quorum Queues

This section verifies that you are using Quorum Queues for replicated Queues.

All replicated Queues are Quorum Queues.
You have replicated Queues that are not Quorum Queues.

Why should replicated Queues be Quorum Queues?

Classic mirrored queues are deprecated. Quorum Queues are using a more efficient and reliable algorithm for replication and will provide higher throughput.

How to proceed

Move your classic mirrored Queues to Quorum Queues as soon as possible.


Limited use of Priority Queues

This section verifies that you are not using too many levels of Priority Queues.

You are using a normal amount of levels for Priority Queues.
You have more Priority Queue levels than recommended.

Why should I use a limited number of Priority Queues?

Each priority level uses an internal queue on the Erlang VM, which takes up some resources. In most use cases no more than 5 priority levels are necessary.

How to proceed

Try to lower the number of Priority Queues.


Connections

Using long-lived Connections

This section verifies that you are using long-lived Connections.

RabbitMQ is using long-lived Connections.
RabbitMQ is not using long-lived Connections.

Why should RabbitMQ have long-lived Connections?

RabbitMQ is optimized for long-lived connections. Each connection establishment is pretty heavy and uses many TCP packets. Keep connections open if possible.

How to proceed

Have long-lived connections if possible, and use channels for each task. If you have a client that is unable to keep a connection long-lived, you can use AMQP Proxy .


No Connection leak

This section verifies that there is no Connection leak at the moment.

Your RabbitMQ does not have a connection leak
Your RabbitMQ may have a connection leak.

Why is it important not to have a Connection leak?

Connection leaks can cause RabbitMQ to run out of memory. Make sure your clients are not leaking Connections.

How to proceed

Check if you have more than 10 Connections from the same host which may indicate a Connection leak. This is, however, a normal case if you deploy many clients on the same IP.


No Channel leak

This section verifies that there is no Channel leak at the moment.

Your RabbitMQ does not have a Channel leak.
Your RabbitMQ may have a Channel leak.

Why is it important not to have a Channel leak?

Channel leaks can eventually cause RabbitMQ to run out of memory.

How to proceed

Make sure your clients are not leaking Channels.

Check if you have connections with more than 1,000 Channels, which may indicate a Channel leak. Identify why you have so many Channels for that Connection.


Channels on all Connections

This section verifies that there are Channels on all Connections.

Your RabbitMQ has Channels on all Connections.
Your RabbitMQ does not have Channels on all Connections.

Why is it important to have Channels on all Connections?

Connections without Channels may be an indication that your clients are not working properly.

How to proceed

Make sure that your Connections are used.


No insecure Connections

This section verifies that there are no insecure Connections to RabbitMQ.

All Connections are secure Connections.
At least one Connection is an insecure Connection.

Why is it important to secure Connections?

Secure Connections are designed to protect data sent between Clients, and are important if you are sending sensitive data.

How to proceed

Use TLS for all connections made over the public internet. For most AMQP clients it is as simple as replacing amqp:// with amqps://.


Separate Connections for Publishers and Consumers

This section verifies that Connections for Publishers and Consumers are separated.

All Connections for Publishers and Consumers are separated.
Not all Connections for Publishers and Consumers are separated.

Why should I separate Connections for Publishers and Consumers?

If you use the same Connection for Publishers and Consumers you won't be able to consume if the Connection is in flow control, which will worsen the flow problem.

How to proceed

Make sure that you are using a separate Connection for the Publishers and the Consumers.


Clients

No outdated Clients

This section verifies that you do not have any outdated Clients.

You are not using any outdated Clients.
You are using outdated Clients.

Why should I not use outdated Clients?

Not all RabbitMQ Client libraries/versions are well behaved. Outdated Clients are Clients that have many issues or do not follow the AMQP standard.

How to proceed

There are probably other options for a Client library in your selected language. Reach out to support@cloudamqp.com if you need help to select a new Client library for your application.


AMQP Heartbeats disabled

This section verifies that you have disabled AMQP Heartbeats.

AMQP Heartbeats is disabled.
You have not disabled AMQP Heartbeats.

Why do I not need to enable AMQP Heartbeats?

All CloudAMQP servers implement sensible TCP keepalive so AMQP Heartbeats are not necessary.

How to proceed

Disable AMQP Heartbeats by setting the heartbeat value to 0 both in your clients and in the your server configuration. Go to Configuration in the CloudAMQP Console to disable Heartbeats in your RabbitMQ config.


Channel Prefetch set on Consumer Channels

This section verifies that a Channel Prefetch is set on Consumer Channels.

A Prefetch is set on the Consumer Channel.
Channel Prefetch is missing on Consumer Channels.

Why should I set Channel Prefetch on Consumer Channels?

Not setting a prefetch can lead to clients running out of memory and makes it impossible to scale out with more consumers.

How to proceed

Always configure channel prefetch. See FAQ: How to Optimize the RabbitMQ Prefetch Count for more information.