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.

Compatibility and requirements

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:

A New Relic account. Don't have one? Sign up for free! No credit card required.
If JMX is not running on Kubernetes or Amazon ECS, you must install the infrastructure agent on a host that's running JMX. Otherwise:
- If running on Kubernetes, see these requirements.
- If running on ECS, see these requirements.
This integration does not support the IIOP protocol.

Install and activate

To install the JMX integration, follow the instructions for your environment:

Install the infrastructure agent, and replace the INTEGRATION_FILE_NAME variable with nri-jmx.
Change the directory to the integrations folder:
```
cd /etc/newrelic-infra/integrations.d
```

Copy the sample configuration file:

sudo cp jmx-config.yml.sample jmx-config.yml

Copy the JVM configuration file:

sudo cp jvm-metrics.yml.sample jvm-metrics.yml

Optional: If you're interested in monitoring Tomcat, use this sample metrics file:
```
sudo cp tomcat-metrics.yml.sample tomcat-metrics.yml
```
Edit the jmx-config.yml file as described in the configuration settings.
Restart the infrastructure agent.
Important
If the sample files are not present in your installation, you can download them directly from the GitHub repository.

Download the nri-jmx .MSI installer image from:
https://download.newrelic.com/infrastructure_agent/windows/integrations/nri-jmx/nri-jmx-amd64.msi
To install from the Windows command prompt, run:
```
msiexec.exe /qn /i PATH\TO\nri-jmx-amd64.msi
```
In the Integrations directory, C:\Program Files\New Relic\newrelic-infra\integrations.d\, create a copy of the sample configuration file by running:
```
cp jmx-config.yml.sample jmx-config.yml
```
Edit the jmx-config.yml configuration file using the configuration settings.
Restart the infrastructure agent.

Additional notes:

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.
On-host integrations do not automatically update. For best results, regularly update the integration package and the infrastructure agent.

Tips for naming your data

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 our 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.

Example: MyorgApplicationSample

Recommendation: Use the same naming scheme for similar metrics across different applications.

Find and use data

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 event_type called 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.

Metric 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:

Name	Description
`displayName`	The JMX domain name for these metrics.
`entityName`	The JMX domain name for these metrics with the entity type “domain:” prepended.
`host`	The JMX host the metrics are being collected from.
`query`	The query used to collect these metrics.
`bean`	The bean whose attributes these metrics were collected from.
`key:<mbean_key>`	For each key in the bean name, an attribute is added to the metric set called `“key:<mbean_key>` with the value of the bean’s key.

Example NRQL query

Here's an example NRQL query taking advantage of metadata monitor all the collected JVM garbage collectors:

SELECT latest(CollectionTime)
FROM JVMSample
FACET `key:name`
WHERE `key:type` = 'GarbageCollector'

Metrics data attributes

The JMX integration collects the following metric data attributes:

Name	Description
`HeapMemoryUsage.Used`	The total Java heap memory used.
`HeapMemoryUsage.Committed`	The total Java heap memory committed to be used.
`HeapMemoryUsage.Init`	The initial Java heap memory allocated.
`HeapMemoryUsage.Max`	The maximum Java heap memory available.
`NonHeapMemoryUsage.Used`	The total Java non-heap memory used.
`NonHeapMemoryUsage.Committed`	The total Java non-heap memory committed to be used.
`NonHeapMemoryUsage.Init`	The initial Java non-heap memory allocated.
`NonHeapMemoryUsage.Max`	The maximum Java non-heap memory available.
`ThreadCount`	The number of live threads.
`CollectionCount`	The total number of garbage collections that have occurred.
`CollectionTime`	The approximate accumulated garbage collection time elapsed.

Inventory data

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.

Troubleshooting

Troubleshooting tips:

If you suspect there is a domain sending more than 200 metrics, check the log file for this message:

"Domain x has n metrics, the current limit is 200. This domain will not be reported."

If you see this error message, lower the number of metrics being sent for the reported domain.

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.

JMX monitoring integration

Compatibility and requirements

Install and activate

ECS

Kubernetes

Linux

Important

Windows

Tips for naming your data

Find and use data

Metric data

Example NRQL query

Metrics data attributes

Inventory data

Troubleshooting

Search logs for errors

Metrics limit exceeded

Missing metrics

Dashboard not appearing in Infrastructure monitoring

Troubleshooting via JMXTerm

Check the source code