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.
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.
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.
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.
Configuration of the metrics collection as a JSON.
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.
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.
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:
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.
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:
# 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 file configurations for an on-host install: