Our JMX integration allows users to monitor any application that exposes metrics with JMX. The integration includes a default collection file that automatically collects key metrics from the JVM. You can also customize your metric collection with YAML files to collect any subset of metrics.
Read on to install the integration, and to see what data we collect.
Our integration is compatible with Java 8 or higher. If you need to use a different Java version than the one configured in
PATH, follow New Relic's configuration documentation on GitHub.
Before installing the integration, make sure that you meet the following requirements:
- If JMX is not running on Kubernetes or Amazon ECS, you must install the infrastructure agent on a host that's running JMX. Otherwise:
- This integration does not support the IIOP protocol.
Instrument your JMX-enabled application quickly and send your telemetry data with guided install. Our guided install creates a customized CLI command for your environment that downloads and installs the New Relic CLI and the infrastructure agent.
Ready to get started? Click one of these button to try it out.
Our guided install uses the infrastructure agent to set up the JMX integration. Not only that, it discovers other applications and log sources running in your environment and then recommends which ones you should instrument.
The guided install works with most setups. But if it doesn't suit your needs, you can find other methods below to get started monitoring your JMX-enabled application.
To install the JMX integration, follow the instructions for your environment:
- Advanced: Integrations are also available in tarball format to allow for install outside of a package manager.
- When the Infrastructure agent executes the
nri-jmxbinary, 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.
- On-host integrations do not automatically update. For best results, regularly update the integration package and the infrastructure agent.
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 enabled via Kubernetes: see Monitor services running on Kubernetes.
- If enabled via Amazon ECS: see Monitor services running on ECS.
- If installed on-host: edit the config in the integration's YAML config file,
Configuration options are below. For examples, see Example config.
This is where the host connection and collection file information is defined. This configuration accepts the following arguments. For an example, see Host connection file example.
collection_files: 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
- Connection arguments:
jmx_host: the host JMX is running on. Default:
jmx_pass: the password for the JMX connection. Default:
jmx_port: the port JMX is running on. Default:
jmx_remote: (JBoss specific) whether or not to use the JMX remote URL connection format, connection defaults to JBoss Domain-mode if
jmx_remote_jboss_standlone: (JBoss specific) whether or not to use the JBoss standalone connection format, only relevant if
jmx_remoteis set. Default:
connection_url:: full JMX endpoint URL. This replaces all connection arguments (above) by providing all parameters on one line. Example:
jmx_user: the username for the JMX connection. Default:
key_store: the filepath of the keystore containing the JMX client's SSL certificate.
key_store_password: the password for the SSL key store.
local_entity: collect all metrics on the local entity. Only use when monitoring localhost. Default:
timeout: the timeout for individual JMX queries, in milliseconds.
trust_store: the filepath of the keystore containing the JMX server's SSL certificate.
trust_store_password: the password for the trust store.
With secrets management, you can configure on-host integrations with New Relic infrastructure's agent to use sensitive data (such as passwords) without having to write them as plain text into the integration's configuration file. For more information, see Secrets management.
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.
Default JVM metrics collection file:
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_typeis 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.langwill 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,
attributes: A list of attributes to collect. If unspecified, collects all attributes.
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: 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,
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
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.
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/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:
For more about the general structure of on-host integration configuration, see Configuration.
Metrics are sent and stored in the form of samples. This is a list of key-value pairs that include metric data and metadata. Each sample is stored as an event in New Relic’s event database.
You are responsible for creating and naming the JMX data reported to New Relic. For this reason, New Relic strongly recommends following these conventions when naming your event types. To ensure you have a consistent naming scheme:
- Use camel case.
- Use a name that clearly identifies what data it contains.
Recommendation: Use the same naming scheme for similar metrics across different applications.
Data from this service is reported to an integration dashboard.
JMX data is attached to the user-defined event type specified in the configuration file. For example, if you are interested in monitoring Tomcat using the JMX integration, define an
TomcatSample, and query that event type.
You can query this data for troubleshooting purposes or to create custom charts and dashboards.
For more on how to find and use your data, see Understand integration data.
The metrics generated by the integration include metadata associated with the MBean they are collecting from. You can use this metadata in NRQL queries to filter and facet the data so that the query returns only the data for the desired beans. It can also be used to uniquely identify the metrics, since the metric name is not necessarily unique between all beans.
Each event contains the following metadata:
The JMX domain name for these metrics.
The JMX domain name for these metrics with the entity type “domain:” prepended.
The JMX host the metrics are being collected from.
The query used to collect these metrics.
The bean whose attributes these metrics were collected from.
For each key in the bean name, an attribute is added to the metric set called
Here's an example NRQL query taking advantage of metadata monitor all the collected JVM garbage collectors:
SELECT latest(CollectionTime)FROM JVMSampleFACET `key:name`WHERE `key:type` = 'GarbageCollector'
The JMX integration collects the following metric data attributes:
The total Java heap memory used.
The total Java heap memory committed to be used.
The initial Java heap memory allocated.
The maximum Java heap memory available.
The total Java non-heap memory used.
The total Java non-heap memory committed to be used.
The initial Java non-heap memory allocated.
The maximum Java non-heap memory available.
The number of live threads.
The total number of garbage collections that have occurred.
The approximate accumulated garbage collection time elapsed.
The JMX integration captures the configuration parameters of the JMX integration. The data is available on the Inventory page, under the config/jmx source. For more about inventory data, see Understand integration data.
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.