• English日本語한국어
  • Log inStart now

JMX monitoring integration

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.

Compatibility and requirements

Before installing the integration, make sure that you meet the following requirements:

Quick start

If you're not running JMX in Kubernetes or ECS environments, we recommend our guided install. Our guided install uses our infrastructure agent and our CLI to set up the JMX integration, and 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, there are other install options below.

Ready to get started? Click the relevant button, depending on which data center region you use. When you're done with the install, return to this documentation to review the configuration options.

Guided install, US region

Install

If you're not using the guided install, follow the instructions for your environment:

Update your integration

This integration doesn't automatically update. For best results, regularly update the integration package and the infrastructure agent.

Post-installation tasks

When you're done with the install, you can set configuration options. Some configurations are required to get the integration to work, while some are optional.

Configure the integration

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:

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.

Config options are below. For an example configuration, see the example config file.

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.

Default JVM metrics collection file: /etc/newrelic-infra/integrations.d/jvm-metrics.yml

Tip

You can write different collection files to ease organization and maintenance. See configuration file for an example.

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:

Next, use annotations to define collection configuration. For example, here's a Tomcat deployment with annotations:

apiVersion: apps/v1
kind: Deployment
metadata:
name: tomcat-deployment
labels:
app: java
spec:
replicas: 1
selector:
matchLabels:
app: java
template:
metadata:
annotations:
newrelic.config: >-
{
"collect": [
{
"domain": "java.lang",
"event_type": "JVMSample",
"beans": [
{
"query": "type=GarbageCollector,name=*",
"attributes": [
"CollectionCount",
"CollectionTime"
]
},
{
"query": "type=Memory",
"attributes": [
"HeapMemoryUsage.Committed",
"HeapMemoryUsage.Init",
"HeapMemoryUsage.Max",
"HeapMemoryUsage.Used",
"NonHeapMemoryUsage.Committed",
"NonHeapMemoryUsage.Init",
"NonHeapMemoryUsage.Max",
"NonHeapMemoryUsage.Used"
]
},
{
"query": "type=Threading",
"attributes": [
"ThreadCount",
"TotalStartedThreadCount"
]
},
{
"query": "type=ClassLoading",
"attributes": [
"LoadedClassCount"
]
},
{
"query": "type=Compilation",
"attributes": [
"TotalCompilationTime"
]
}
]
}
]
}
labels:
app: java
spec:
containers:
- name: tomcat
image: tomcat:10.0.12
ports:
- containerPort: 9999
env:
- name: CATALINA_OPTS
value: '-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9999 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false'

Custom connectors

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:

For more about the general structure of on-host integration configuration, see Configuration.

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:

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.

Copyright © 2024 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.