RabbitMQ monitoring integration
The New Relic RabbitMQ on-host integration reports metrics and configuration data from your RabbitMQ service, including important metrics relating to the cluster, vhosts, queues, exchanges, and consumers.
Important
This integration can monitor only one RabbitMQ server instance per host.
Important
This integration doesn't automatically update. For best results, regularly update the integration package and the infrastructure agent.
Configuration options
For the standard on-host installation, this integration comes with a YAML config file, rabbitmq-config.yml
. This configuration is where you can place required login credentials and configure how data is collected. Which options you change depends on your setup and preferences. It comes with a sample config file rabbitmq-log.yml.example
that you can copy and edit.
The configuration file has common settings applicable to all integrations like interval
, timeout
, inventory_source
.
Important
To read all about common settings or if you're still using our Legacy configuration or definition files, please go to our On-host integrations: Standard configuration format document.
Specific settings related to RabbitMQ are defined using the env
section of the configuration file. These settings control the connection to your RabbitMQ instance as well as other security settings and features. The next section of this document describes the list of valid settings.
Cluster environments
In cluster environments, the integration collects metrics from all the cluster with only one instance of the integration connected to one node. This instance should use METRICS=true
and INVENTORY=true
. For the rest of the nodes only Inventory should be collected using METRICS=false
and INVENTORY=true
. For more on these, see instance settings.
If you're running a cluster environment in Kubernetes, you need to deploy RabbitMQ as a StatefulSet, and configure the agent to query all the metrics from the RabbitMQ pod. Set the autodiscovery matching condition in the config file to this value:
discovery: command: exec: /var/db/newrelic-infra/nri-discovery-kubernetes match: podName: rabbitmq-0
Important
The integration restricts the collection of queues to a certain number. If the number of queues exceeds 2000, after the application of queue filters, the integration won't report any of them. We offer a workaround that will preserve all metrics, but it will disable entity registration. To apply the workaround, add the following environment variable to the configuration file:
integrations: - name: nri-rabbitmq env: # Integration configuration parameters. METRICS: true DISABLE_ENTITIES: true QUEUES_MAX_LIMIT: "0"
RabbitMQ instance settings
The RabbitMQ integration collects both Metrics(M) and Inventory(I) information. Check the Applies To column below to find which settings can be used for each specific collection:
Setting | Description | Default | Applies To |
---|---|---|---|
| Hostname or IP of the RabbitMQ management plugin. |
| M/I |
| Port number of the RabbitMQ management plugin. |
| M/I |
| User that is connecting to RabbitMQ management plugin. | N/A | M/I |
| Password to connect to RabbitMQ management plugin. | N/A | M/I |
| Timeout in seconds to timeout the connection to RabbitMQ endpoint. |
| M/I |
| RabbitMQ Management Prefix. | N/A | M/I |
| Option to connect using SSL. |
| M/I |
| Location of SSL certificate on the host. | N/A | M/I |
| Location of SSL certificate on the host. | N/A | M/I |
| Overrides the local node name instead of retrieving it from RabbitMQ. | N/A | M/I |
| Absolute path to the RabbitMQ configuration file. | N/A | M/I |
| Queue names to collect in the format of a JSON array of strings. If a queue name exactly matches (case sensitive) one of these, it will be collected. Example:
| N/A | I |
| Queue names to collect in the format of a JSON array of REGEX strings. If a queue name matches one of these, it will be collected. Example:
| N/A | M/I |
| Exchange names to collect in the format of a JSON array of strings. If an exchange name exactly matches (case sensitive) one of these, it will be collected. | N/A | M/I |
| Exchanges names to collect in the format of a JSON array of REGEX strings. If an exchange name matches one of these it will be collected. | N/A | M/I |
| Vhost names to collect in the format of a JSON array of strings. If a vhost name exactly matches (case sensitive) one of these, it will be included. This also affects only collecting entities belonging to vhosts specified. | N/A | M/I |
| Vhost names to collect in the format of a JSON array of REGEX strings. If a vhost name matches one of these the vhost and any entities belonging to this vhost will be collected. | N/A | M/I |
| Set to |
| |
| Set to |
| |
| Set to |
| |
| Configure whether inventory entries are created for entities during metrics collection. Only to be used as workaround to collect large amounts of Queues. |
| |
| Defines the max amount of Queues that can be processed, if this number is reached all queues will be dropped. If defined as |
|
The values for these settings can be defined in several ways:
- Adding the value directly in the config file. This is the most common way.
- Replacing the values from environment variables using the
{{}}
notation. This requires infrastructure agent v1.14.0+. Read more here. - Using Secrets management. Use this to protect sensible information such as passwords to be exposed in plain text on the configuration file. For more information, see Secrets management.
Labels/Custom Attributes
Environment variables can be used to control config settings, such as your , and are then passed through to the infrastructure agent. For instructions on how to use this feature, see Configure the infrastructure agent.
You can further decorate your metrics using labels. Labels allow you to add key/value pairs attributes to your metrics which you can then use to query, filter or group your metrics on.
Our default sample config file includes examples of labels but, as they are not mandatory, you can remove, modify, or add new ones of your choice.
labels: env: production role: rabbitmq
Example configuration
Examples of the configuration file:
See On-host integration configuration overview to know more about the general structure of on-host integration configuration.
Metric data
The RabbitMQ integration collects the following metric data attributes. Each metric name is prefixed with a category indicator and a period, such as queue. or node..
RabbitMQ vhost sample event
These attributes are attached to the RabbitmqVhostSample
event type:
Name | Description |
---|---|
| Number of current connections in the state blocked. |
| Number of current connections in the state blocking. |
| Number of current connections in the state closed. |
| Number of current connections in the state closing. |
| Number of current connections in the state flow. |
| Number of current connections in the state opening. |
| Number of current connections in the state running. |
| Number of current connections in the state starting. |
| Number of current connections to a given rabbitmq vhost. |
| Number of current connections in the state tuning. |
RabbitMQ node sample event
These attributes are attached to the RabbitmqNodeSample
event type:
Name | Description |
---|---|
| Average number of Erlang processes waiting to run. In RabbitMQ this is seen as |
| Node disk alarm (0 or 1). 0 shows that the alarm is not tripped and 1 shows that the alarm is tripped. In RabbitMQ this is seen as |
| Current free disk space in bytes. In RabbitMQ this is seen as |
| The total count of file descriptors. In RabbitMQ this is seen as |
| The total count of file descriptors used. In RabbitMQ this is seen as |
| Number of file descriptors used as sockets. In RabbitMQ this is seen as |
| Total number of file descriptors available as sockets. In RabbitMQ this is seen as |
| Host memory alarm (0 or 1). 0 shows that the alarm is not tripped and 1 shows that the alarm is tripped. In RabbitMQ this is seen as |
| Memory used in bytes. In RabbitMQ this is seen as |
| Number of network partitions seen per node. In RabbitMQ this is seen as |
| Erlang process limit. In RabbitMQ this is seen as |
| Erlang processes used. In RabbitMQ this is seen as |
| Node running ( |
RabbitMQ exchange sample event
These attributes are attached to the RabbitmqExchangeSample
event type:
Name | Description |
---|---|
| Number of bindings for a specific exchange. |
| Count of messages published from a channel into this exchange. In RabbitMQ this is seen as |
| Rate of messages published from a channel into this exchange per sec. In RabbitMQ this is seen as |
| Count of messages published from this exchange into a queue. In RabbitMQ this is seen as |
| Rate of messages published from this exchange into a queue per second. In RabbitMQ this is seen as |
RabbitMQ queue sample event
These attributes are attached to the RabbitmqQueueSample
event type:
Name | Description |
---|---|
| Number of bindings for a specific queue. |
| Number of active consumers that can immediately receive any messages sent to the queue. In RabbitMQ this is seen as |
| Number of consumers per queue. In RabbitMQ this is seen as consumers. |
| The ratio of time that a queue's consumers can take new messages (utilization per second). In RabbitMQ this is seen as This metric is only available on RabbitMQ version 3.3 or higher. |
| Bytes consumed by the Erlang process associated with the queue. In RabbitMQ this is seen as |
| Count of messages ready to be delivered to clients. In RabbitMQ this is seen as |
| Rate of messages ready to be delivered to clients per second. In RabbitMQ this is seen as |
| Count of messages per queue delivered to clients but not yet acknowledged. In RabbitMQ this is seen as |
| Rate of messages per queue delivered to clients but not yet acknowledged per second. In RabbitMQ this is seen as |
| Count of messages delivered to clients and acknowledged per queue. In RabbitMQ this is seen as |
| Rate of messages delivered to clients and acknowledged per second per queue. In RabbitMQ this is seen as |
| Count of messages delivered in acknowledgment mode to consumers per queue. In RabbitMQ this is seen as |
| Rate of messages delivered in acknowledgment mode to consumers per queue per second. In RabbitMQ this is seen as |
| Count of messages published per queue. In RabbitMQ this is seen as |
| Rate of messages published per second per queue. In RabbitMQ this is seen as |
| Count of subset of messages in acknowledgment mode which had the redelivered flag set per queue. In RabbitMQ this is seen as |
| Rate of subset of messages in acknowledgment mode which had the redelivered flag set per queue per second. In RabbitMQ this is seen as |
| Sum of messages delivered in acknowledgment mode to consumers, in no-acknowledgment mode to consumers, in acknowledgment mode in response to basic.get, and in no-acknowledgment mode in response to basic.get. per queue. In RabbitMQ this is seen as |
| Rate per second of the sum of messages delivered in acknowledgment mode to consumers, in no-acknowledgment mode to consumers, in acknowledgment mode in response to basic.get, and in no-acknowledgment mode in response to basic.get per queue. In RabbitMQ this is seen as |
| Count of the total messages in the queue. In RabbitMQ this is seen as |
| Rate of total messages in queue. In RabbitMQ this is seen as |
System metadata
Other metadata includes:
Name | Description |
---|---|
| The version of the RabbitMQ server. Example: 3.6.7. |
| The version of the RabbitMQ management plugin. For example: 3.6.7. |
Inventory data
The integration captures the configuration parameters of RabbitMQ in the /etc/rabbitmq/rabbitmq.conf
file. Inventory data is only captured in RabbitMQ version 3.7 or higher; the inventory data will appear on the Inventory page in the infrastructure UI, under the config/rabbitmq
source.
Caution
Be aware that any sensitive information that you put into the rabbit.conf
file will appear on the Inventory page in the infrastructure UI. This includes items such as the following from AWS:
cluster_formation.aws.secret_key,cluster_formation.aws.access_key_id
Troubleshooting
Troubleshooting tips:
Check the source code
This integration is open source software. That means you can browse its source code and send improvements, or create your own fork and build it.