Monitoring RabbitMQ?

[raffaele_talari]

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

[Jakub_Mierzewsk · Accepted solution]

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

[raffaele_talari]

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

[hjamal21]

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