Monitoring RabbitMQ?

raffaele_talari — Thu, 05 Jun 2025 13:13:08 GMT

Hi there,

is it
possible to monitor a RabbitMQ (CloudFoundry service) queue size somehow?

If so, how? Would it be possible to pull queue size data using the DynatraceAPI?

Thanks in advance for your help,

Raff

Re: Monitoring RabbitMQ?

Jakub_Mierzewsk — Mon, 10 Jul 2017 09:47:37 GMT

Hi Raff,

We have RabbitMQ plugin which runs in OneAgent. If OneAgent can be installed on RabbitMQ host then we will have all metrics form plugin . If OneAgent could not be install then plugin will not work and API will be needed.

Best,
Jakub

Re: Monitoring RabbitMQ?

raffaele_talari — Tue, 11 Jul 2017 09:36:26 GMT

Hi,

just to add some details about using Dynatrace API for RabbitMQ metrics, here's a quick guide.

Hope that helps.

Ciao,

Raff

Dynatrace API – RabbitMQ

For details about monitoring
RabbitMQ please refer to these pages:

https://www.dynatrace.com/blog/introducing-rabbitmq-monitoring-beta/

API Endpoints:

-Dynatrace SaaS
ohttps://{{Tenant}}.live.dynatrace.com/api/v1/
-Dynatrace Managed URL Prefix
ohttps://{{owndomain}}/e/{{Tenant}}/api/v1/

RabbitMQ timeseries API invocation:

https://{{Tenant}}.live.dynatrace.com/api/v1/timeseries

https://{{owndomain}}/e/{{Tenant}}/api/v1/timeseries

*remember
to always put the APIToken in the API invocations. That is generated in the UI
under Settings -> Integration -> Dynatrace API

All the
available API parameters here: https://help.dynatrace.com/dynatrace-api/timeseries/how-do-i-fetch-the-metrics-of-monitored-entities/

RabbitMQ timeseries API invocation examples:

Querying
the average size of the queues in the specified timeframe expressed in Unix
time milliseconds (useful link for UTC to milliseconds and conversion: https://currentmillis.com/)

https://{{Tenant}}.live.dynatrace.com/api/v1/timeseries?Api-Token={{ApiToken}}&timeseriesId=ruxit.python.rabbitmq:queues_count&startTimestamp=1492905600000&endTimestamp=1492992000000&aggregationType=avg

Available RabbitMQ metrics (timeseriesId=):

"ruxit.python.rabbitmq:ad_queues_no_consumers",
oAuto-delete
queues without consumers.
"ruxit.python.rabbitmq:channels_count"
oThe
number of channels (virtual connections). If the number of channels is high,
you may have a memory leak in your client code.
"ruxit.python.rabbitmq:cluster_channels"
oThe
number of virtual connections (AMPQ connection).
"ruxit.python.rabbitmq:cluster_connections"
oThe
number of TCP connections to the message broker. Frequently opened and closed
connections can result in high CPU usage. Connections should be long-lived.
Channels can be opened and closed more frequently.
"ruxit.python.rabbitmq:cluster_consumers”
oThe
number of consumers.
"ruxit.python.rabbitmq:cluster_exchanges"
oThe
number of exchanges.
"ruxit.python.rabbitmq:cluster_messages_ack"
oThe
rate at which messages are acknowledged by the client/consumer.
"ruxit.python.rabbitmq:cluster_messages_deliver_get"
oThe
rate per second of the sum of messages: (1) delivered in acknowledgment mode to
consumers, (2) delivered in n0-acknowledgment mode to consumers, (3) delivered
in acknowledgment mode in response to basic.get, (4) delivered in
n0-acknowledgment mode in response to basic.get.
"ruxit.python.rabbitmq:cluster_messages_publish"
oThe
rate at which messages are incoming to the RabbitMQ cluster.
"ruxit.python.rabbitmq:cluster_messages_ready"
oThe
number of messages that are ready to be delivered. This is the sum of messages
in the messages_ready status.
"ruxit.python.rabbitmq:cluster_messages_redeliver",
"ruxit.python.rabbitmq:cluster_messages_return_unroutable",
"ruxit.python.rabbitmq:cluster_messages_unacknowledged",
oThe
number of messages delivered to clients, but not yet acknowledged. This is the
sum of messages in the messages_unacknowledged status.
"ruxit.python.rabbitmq:cluster_nodes_failed",
oThe
number of unhealthy nodes. Please be aware that not every RabbitMQ version
provides this metric.
"ruxit.python.rabbitmq:cluster_nodes_ok",
oThe
number of healthy nodes. Please be aware that note every RabbitMQ version
provides this metric.
"ruxit.python.rabbitmq:cluster_queues_crashed",
"ruxit.python.rabbitmq:cluster_queues_down",
"ruxit.python.rabbitmq:cluster_queues_flow",
"ruxit.python.rabbitmq:cluster_queues_idle",
"ruxit.python.rabbitmq:cluster_queues_running",
"ruxit.python.rabbitmq:connections_count",
oThe
number of connections.
"ruxit.python.rabbitmq:consumers",
oThe
number of consumers.
"ruxit.python.rabbitmq:disk_free_left_to_limit"
oThe
percentage of available RabbitMQ disk space. Indicates how much available disk
space remains before the disk_free_limit is reached. Once all available disk
space is used up, RabbitMQ blocks producers and prevents memory-based messages
from being paged to disk. This reduces, but doesn’t eliminate, the likelihood
of a crash due to the exhaustion of disk space.
"ruxit.python.rabbitmq:fd_usage"
oThe
percentage of available file descriptors. RabbitMQ installations running
production workloads may require system limits and kernel-parameter tuning to
handle a realistic number of concurrent connections and queues. RabbitMQ
recommends allowing for at least 65,536 file descriptors when using RabbitMQ in
production environments. 4,096 file descriptors is sufficient for most
development workloads. RabbitMQ documentation suggests that you set your file
descriptor limit to 1.5 times the maximum number of connections you expect.
"ruxit.python.rabbitmq:mem_usage"
oThe
percentage of available RabbitMQ memory. 100% means that the RabbitMQ memory
limit vm_memory_high_watermark has been reached. (by default, vm_memory_high_watermark is set to 40% of
installed RAM). Once the RabbitMQ server has used up all available memory, all
new connections are blocked. Note that this doesn’t prevent the RabbitMQ server
from using more than its limit—this is merely the point at which publishers are
throttled.
"ruxit.python.rabbitmq:messages_ready",
oThe
number of ready messages.
"ruxit.python.rabbitmq:messages_unacknowledged",
oThe
number of unacknowledged messages.
"ruxit.python.rabbitmq:node_status",
oThe
status of the node.
"ruxit.python.rabbitmq:proc_usage",
oThe
percentage of available Erlang processes. The maximum number of processes can
be changed via the RABBITMQ_SERVER_ERL_ARGS environment variable.
"ruxit.python.rabbitmq:queues_count",
oRabbitMQ’s
queues are most efficient when they’re empty, so the lower the Queued messages
count, the better.
"ruxit.python.rabbitmq:sockets_usage",
oThe
percentage of available Erlang sockets. The required number of sockets is
correlated with the required number of file descriptors. For more details, see
the” Controlling System Limits on Linux” section at www.rabbitmq.com.
"ruxit.python.rabbitmq:status-failed",
on/a
"ruxit.python.rabbitmq:status-ok",
on/a
"ruxit.python.rabbitmq:topN_queue_ack",
on/a
"ruxit.python.rabbitmq:topN_queue_consumers",
on/a
"ruxit.python.rabbitmq:topN_queue_deliver_get",
on/a
"ruxit.python.rabbitmq:topN_queue_messages_ready",
on/a
"ruxit.python.rabbitmq:topN_queue_messages_unacknowledged",
on/a
"ruxit.python.rabbitmq:topN_queue_publish",
on/a

API invocation of available metrics for Dynatrace Plugins:

https://{{Tenant}}.live.dynatrace.com/api/v1/timeseries?Api-Token={{ApiToken}}&filter=PLUGIN

Re: Monitoring RabbitMQ?

hjamal21 — Tue, 02 Oct 2018 09:55:43 GMT

Can anybody confirm if we need to restart the Rabbit MQ instances after the oneagent deployment?

topic Re: Monitoring RabbitMQ? in Extensions

Monitoring RabbitMQ?

Re: Monitoring RabbitMQ?

Re: Monitoring RabbitMQ?

Re: Monitoring RabbitMQ?