The JMX integration defines and collects integration data using two types of YAML files: the integration configuration options and the metrics collection options. To change how the JMX integration collects your data, first add your login credentials to the integration's YAML-format configuration.
Read on to install the integration, and to see what data we collect.
Advanced: Integrations are also available in tarball format to allow for install outside of a package manager.
When the Infrastructure agent executes the nri-jmx binary, it sets the path to PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin. The java binary must be in one of those paths.
nrjmx and jmx need java binaries to be in the system PATH, which is NOT the PATH for the root user, and isn't affected if you change the PATH environment variable in /root/.bashrc. Read more on how to change the PATH system variable.
An integration's YAML-format configuration is where you can place required login credentials and configure how data is collected. Which options you change depend on your setup and preference.
There are several ways to configure the integration, depending on how it was installed:
If installed on-host: edit the config in the integration's YAML config file, jmx-config.yml.
Integration configuration files
The configuration file has common settings applicable to all integrations, such as interval, timeout, or inventory_source. To read all about these common settings refer to our configuration format document.
Important
If you're still using our legacy configuration/definition files, refer to the
standard configuration
doc
for help.
Specific settings related to JMX are defined using the env section of the configuration file. These settings control the connection to your JMX instance as well as other security settings and features. The list of valid settings is described in the next section of this document.
Config options are below. For an example configuration, see the example config file.
The JMX 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.
A comma-separated list of full file paths to the metric collection
definition files. For on-host install, the default JVM metrics collection
file is at /etc/newrelic-infra/integrations.d/jvm-metrics.yml.
N/A
M/I
COLLECTION_CONFIG
Configuration of the metrics collection as a JSON.
The filepath of the keystore containing the JMX client's SSL certificate.
N/A
M/I
KEY_STORE_PASSWORD
The password for the SSL key store.
N/A
M/I
LOCAL_ENTITY
Collect all metrics on the local entity. Only use when monitoring localhost.
false
M/I
TIMEOUT
The timeout for individual JMX queries, in milliseconds.
10000
M/I
TRUST_STORE
The filepath of the keystore containing the JMX server's SSL certificate.
N/A
M/I
TRUST_STORE_PASSWORD
The password for the trust store.
N/A
M/I
METRIC_LIMIT
Number of metrics that can be collected per entity. If this limit is
exceeded the entity will not be reported. A limit of 0 implies no limit.
200
M/I
METRICS
Set to true to enable Metrics only collection.
false
INVENTORY
Set to true to enable Inventory only collection.
false
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 or higher. Read more here or see the example below.
Using secrets management. Use this to protect sensible information (such as passwords) from being exposed in plain text on the configuration file. For more information, see secrets management.
You can customize your labels, too. Add key/value pair attributes to your metrics, which you can then use to query, filter or group your metrics on.
Our default sample config file has examples of labels. These aren't mandatory, and you can remove, modify, or add new ones of your choice.
labels:
env: production
role: jmx
Metrics collection files
The metrics collection definition files are structured YAML files which tell the integration what metrics to collect. For an example configuration, see the metrics collection file example.
You can write different collection files to ease organization and maintenance.
See configuration file for an example.
The integration collects and organizes metrics according to domains. All metrics defined per domain will be sent to New Relic and can be found in a corresponding event type. This event type is either auto-generated or can be set by the user. Each file contains a single collect: block which contains an array of domains. For each domain, the following keys are defined:
domain: The JMX domain; for example, java.lang. You can use wildcards to match multiple domains; for example, java.*. If you use a wildcard, event_type is required, and must be unique. This field is required.
event_type: The event type name for a collection from this domain. If the domain is wildcarded, this is required, and must be unique. If the domain is not wildcarded and this is undefined by the user, this will be auto generated. For example, the domain java.lang will have event type JavaLangSample. For more information, see Naming tips.
beans: An array of beans to collect in this domain.
Important
There is a limit of 200 metrics per instance in the configuration file. If you
exceed the limit for a particular instance, it will not be sent to New Relic.
If you're not seeing your data in New Relic, review the troubleshooting
procedures to identify if you have exceeded the limit.
Each domain contains an array of beans to be collected. For each bean, the following keys are defined:
query: The bean name to collect; for example,type=GarbageCollector,name=YoungGen. You can use wildcards; for example, type=GarbageCollector,name=*. This field is required.
exclude_regex: An optional list of regex patterns that match beans to exclude from collection; for example, type=GarbageCollector,name=.*.
attributes: A list of attributes to collect. If unspecified, collects all attributes.
Important
The HashMap and ArrayList data types are not supported.
Each bean can contain attributes, an optional list of beans that can be excluded from collection. For each attribute, the following keys are defined:
Important
For map attributes, you must define either an attr or an attr_regex key.
attr: An exact match of the attribute name. Composite attributes can be collected by appending the composite member name to the attribute name with a dot; for example, HeapMemoryUsage.Max.
attr_regex: A regex pattern that matches the attributes to be collected.
metric_type: The New Relic metric type to collect this attribute as. Options are:
gauge: data will be collected as an instantaneous numeric measurement.
rate: data will be collected as the change in that metric per second.
delta: data will be collected as the change in that metric since the last measurement.
attribute: data will be collected as a string literal.
If left unspecified, the JMX integration will attempt to infer the metric type based on the value returned. For example, if the metric is a number, it will collect it as gauge. If the metric is a string, it will collect it as attribute.
If metrics are collected with an incorrect metric type, you can manually specify the correct metric type in the collection file.
metric_name: The name under which the metric will appear in New Relic. If unspecified, it will default to the attribute name.
For more information about JMX queries, see the Oracle ObjectName documentation.
Collection configuration using Kubernetes annotations
You can use Kubernetes annotations to provide collection configuration. To achieve this, you need to deploy a configMap into the Kubernetes cluster that will create the configuration file for the nri-jmx application.
In this configuration file you need to specify the command for container auto-discovery, which will allow you to use placeholders in the integration configuration, including Kubernetes annotations.
Example of a configMap to monitor JVM in a Tomcat application:
nri-bundle:
newrelic-infrastructure:
integrations_config:
-name: jmx-config.yml
data:
discovery:
command:
# Use the following optional arguments:
# --namespaces: Comma separated list of namespaces to discover pods on
# --tls: Use secure (TLS) connection
# --port: Port used to connect to the kubelet. Default is 10255
JMX allows the use of custom connectors to communicate with the application. In order to use a custom connector, you have to include the custom connectors in the nrjmx classpath.
By default, the sub-folder connectors is in the classpath. If this folder does not exist, create it under the folder where nrjmx is installed.
For example, to add support for JBoss, create a folder named connectors under the default (Linux) library path /usr/lib/nrjmx/ (/usr/lib/nrjmx/connectors/) and copy the custom connector jar ($JBOSS_HOME/bin/client/jboss-cli-client.jar) into it. You can now execute JMX queries against JBoss.
Example configurations
Example file configurations for an on-host install: