NAV

CloudAMQP changelog🔗

This is the technical changelog of CloudAMQP.

The Datadog service event attribute can now be set to a custom value for log integrations created after July 1. The service attribute will be overridden by the custom value of the service tag. If a service tag is not set the service attribute will be set to the cluster name.

From August 5, 2025 LavinMQ instances created via the API and Terraform will have automatic version updates enabled by default.

To opt-out your instance from automatic version updates, you can change your maintenance settings either using the API or the Console.

When you add a VPC peering, CloudAMQP automatically adds firewall rules for the peered CIDR block. These rules now include the MQTT ports: 1883 and 8883

We had a mismatch of API metric naming that caused queue unacked and queue ready alarms to not trigger on LavinMQ clusters.

A fix was deployed to handle this on 2025-05-08 11:45 UTC, no change is needed for customers with these alarms.

LavinMQ issue related to queue metrics naming inconsistency: https://github.com/cloudamqp/lavinmq/issues/1098

All our metrics are scraped and forwarded every 60s, except CPU and memory, which were scraped every 30 seconds

Today we are deploying a fix to ensure these are scraped at a 60s interval as well.

This could affect some metrics integrations, i.e. getting fewer metric points for CPU and memory, but we do not expect this to cause any issues.

If you experience any issues please contact us.

We encountered an issue where we tried to send a string value on a field that is suppose to be a float. The bug resulted in an error for the integration that was STRING_VALUE cannot be converted to Double.

We have now identified the issue and a fix has been deployed.

Context

The CloudWatch V2 integration supports batching values, which is done by collecting a number of metric values and from that calculate the minimum value, maximum value, sum of all of them and number of metrics and send that to CloudWatch. We do this to reduce the amount of metrics which reduces the cost for our customer but without loosing value insights into how the cluster is doing. When calculating these values, the Minimum and Maximum values sometimes was sent as strings which resulted in an error in the integration since only int and floats are allowed for these values.

CloudAMQP has upgraded to a higher-performance disk type on Azure. This provides consistent performance regardless of disk size.

Consequently, new Happy Hare (hare) plan instances and above will now be provisioned with smaller default disk sizes.

Azure disk expansion can now be performed live on CloudAMQP clusters, eliminating downtime.

The following issue has been remediated:

Going forward, only the specific alarm(s) where the sole recipient was removed, will be disabled.

The Erlang Ecosystem Foundation has published Exposed EPMD: A Hidden Security Risk for RabbitMQ and the BEAM Ecosystem to highlight the security risks with exposing epmd to the Internet.

At CloudAMQP we have strict firewalls on all instances, and a 24/7 security scanner to detect any faulty configuration. Thus port 4369 is not accessable from to the Internet, nor is other cluster distribution ports like 25672.

No change needed for CloudAMQP customers.

A small number (58) of accounts on shared LavinMQ plans reported having negative message counts. This was due a bug in our accounting system that tracked the number of published/delivered messages.

Fix has been deployed.

The LavinMQ 2.0.2 rollout on shared servers enabled counting of get/delivered messages for shared accounts. We now count just as we do on the RabbitMQ shared clusters thanks to the introduction of deliver_get metrics (LavinMQ pull request #793)

Note that both basic.deliver and basic.get counts, e.g. if you poll with basic.get it will count even if there's no message in the queue. We recommend you subscribe to a queue and get the messages delivered as they become available. Read more about Consume vs. Get.

Message limit is counted as published + deliver_get and checked against the monthly limit.

In the CloudAMQP Console, for users with the member role or the monitor role ("tagged roles"), you can assign tags to the user, in order to grant access to instances. Before 2024-10-17, changing a user's role from a tagged role to another tagged role, did not keep the assigned tags. Now the tags are kept.

The following attributes was added to Instance API: List nodes: disk_size, additional_disk_size