This feature is available on dedicated instances
You can easily change some of the most common RabbitMQ configurations from the CloudAMQP Console. Changing these configurations does not require a restart of RabbitMQ, and the changes will survive a RabbitMQ restart.
|prometheus.return_per_object_metrics||If you want Prometheus to return its metrics per object instead of an aggregated value|
|heartbeat||Set the server AMQP 0-9-1 heartbeat timeout in seconds.|
|channel_max||Set the maximum permissible number of channels per connection. 0 means "no limit."|
|consumer_timeout||A consumer that has received a message and does not acknowledge that message within the timeout in milliseconds will get canceled. The channel will close, and the message will be returned to the queue (max 25,000,000).|
|vm_memory_high_watermark||When the server will enter memory-based flow-control relative to the maximum available memory (allowed values [0.40 - 0.90]).|
|queue_index_embed_msgs_below||Size in bytes below which to embed messages in the queue index (max 10,485,760).|
To restore the configuration to the default settings, click Restore to defaults and Save. We can also tweak other configurations for you. Just send us an email to firstname.lastname@example.org .
The built-in plugin for Prometheus was introduced in RabbitMQ version 3.8.0 and is used for metrics collection. When the plugin is enabled, it exposes RabbitMQ metrics via the /metrics endpoint, for example, https://[HOST]/metrics
The metrics exposed can be aggregated or per-object:
Aggregated means that metrics are aggregated by name. This mode has a lower performance overhead and should be used if having a large number of queues and connections.
Per-object means individual metric for each object-metric pair. Having this enabled can result in huge payloads and subsequently higher CPU if there are many entities. The default value is to use aggregated metrics which is easy to toggle to per-object metrics if necessary. If the metrics aren’t available, the plugin may need to be enabled from the Plugins view in the CloudAMQP Console.
The heartbeat value defines the amount of time a connection is considered unreachable if no heartbeat is received. This value defines in seconds with a default value of 120 and can be configured in clients and by RabbitMQ. The value is negotiated between the client and RabbitMQ server when connecting. All CloudAMQP servers implement sensible TCP keepalive, which is on the TCP/kernel level instead of the protocol level. Therefore we recommend turning heartbeat off by setting this value to 0. You also have to put it to 0 in the client for it to be disabled.
The channel max value is the maximum number of channels allowed open on a connection simultaneously. The client and server negotiated it upon connection, with the lower value of the two used. However, the client cannot allow for more channels than the server configuration. In general, you should establish one connection per process with a dedicated channel given to each new thread. Setting channel_max to 0 means unlimited channels, but be aware that this could be a dangerous move since applications sometimes have channel leaks.
The consumer timeout configuration was introduced in RabbitMQ version 3.8.15 to help detect stuck consumers that doesn’ acknowledge deliveries. Having a stuck consumer can affect the performance and impact the server resources, such as the disk. If a consumer is unable to send an acknowledgment within the timeout value, its channel will be closed. This value is set in milliseconds and can be set from 10,000 to 25000000.
The memory high watermark configuration defines the threshold for RabbitMQ to raise a memory alarm. RabbitMQ will block all connections that are publishing messages when a memory alarm is triggered. Publishing resumes when the memory alarm is resolved. The default value is set to 0.81, which means that 81% of the available memory can be used before triggering a memory alarm. This value is set to a minimum of 0.4 (40%) and a maximum of 0.9 (90%).
Very small messages can be kept in the queue index as an optimization instead of being written to the message store. The config queue_index_embed_msgs_below controls the message size for keeping messages in the queue index. The default value is 4096 bytes including properties and headers. Increase this value with caution as it can lead to more memory usage.