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.
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. |
RabbitMQ is improving all the time, bugs are fixed and new features are added. We recommend that you always keep RabbitMQ up to date.
The RabbitMQ version can be updated from the CloudAMQP console by clicking the Update RabbitMQ button on the instance Nodes page.
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. |
Performance and reliability in Erlang are improving with each new version. We recommend that you always keep Erlang up to date.
The Erlang version can be updated from the CloudAMQP console by clicking the Upgrade Erlang button on the instance Nodes page.
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 |
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.
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.
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. |
Having lots of exchanges is not the best practice use of RabbitMQ.
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.
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. |
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.
Use Fanout Exchange instead of using Topic Exchange with only '#' bindings.
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. |
Having lots of exchanges is not the best practice use of RabbitMQ.
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.
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. |
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.
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. |
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.
Add a High Availability (HA) policy on all custom vhosts.
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. |
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.
Add more consumers or scale up your system if you can’t keep your queues short. Enable lazy queues if you run batch jobs.
This section verifies whether there are unused Queues or not.
| All Queues on the server are being used. | |
| You 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.
Remove Queues that are not in use.
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. |
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.
Set temporary queues as auto-delete, exclusive or auto-expire.
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. |
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.
Set the persistent flag when publishing otherwise messages will be lost on restart.
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. |
Mirroring auto-delete queues is probably unnecessary unless you have a very specific use case for it.
Remove the mirroring from the auto-deleted Queue, or remove the auto-delete configuration.
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. |
Sending transient messages into mirrored queues is probably unnecessary unless you have a very specific use case to do so.
Remember to set the persistent flag when publishing a message.
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. |
Classic mirrored queues are deprecated. Quorum Queues are using a more efficient and reliable algorithm for replication and will provide higher throughput.
Move your classic mirrored Queues to Quorum Queues as soon as possible.
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. |
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.
Try to lower the number of Priority Queues.
This section verifies that you are using long-lived Connections.
| RabbitMQ is using long-lived Connections. | |
| RabbitMQ is not using 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.
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 .
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. |
Connection leaks can cause RabbitMQ to run out of memory. Make sure your clients are not leaking Connections.
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.
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. |
Channel leaks can eventually cause RabbitMQ to run out of memory.
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.
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. |
Connections without Channels may be an indication that your clients are not working properly.
Make sure that your Connections are used.
This section verifies that there are no insecure Connections to RabbitMQ.
| All Connections are secure Connections. | |
| At least one Connection is an insecure Connection. |
Secure Connections are designed to protect data sent between Clients, and are important if you are sending sensitive data.
Use TLS for all connections made over the public internet. For most AMQP clients it is as simple as replacing amqp:// with amqps://.
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. |
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.
Make sure that you are using a separate Connection for the Publishers and the Consumers.
This section verifies that you do not have any outdated Clients.
| You are not using any outdated Clients. | |
| You are using 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.
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.
This section verifies that you have disabled AMQP Heartbeats.
| AMQP Heartbeats is disabled. | |
| You have not disabled AMQP Heartbeats. |
All CloudAMQP servers implement sensible TCP keepalive so AMQP Heartbeats are not necessary.
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.
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. |
Not setting a prefetch can lead to clients running out of memory and makes it impossible to scale out with more consumers.
Always configure channel prefetch. See FAQ: How to Optimize the RabbitMQ Prefetch Count for more information.