JMX (Java Management Extensions) is ideal for monitoring applications built using Java. With Dynatrace, you can monitor any metric in your JVM that is exposed via an MBean.
JMX and PMI extensions are also available in Infrastructure Monitoring mode You can use them to monitor any infrastructure component and backing service written in Java and have all the collected metrics reported by Dynatrace.
A-Z, a-z
, numbers 0-9
, or -/_
.Selecting the process, host, or Management Zone doesn't limit the extension monitoring scope. JMX/PMI extensions monitor all Java processes accessible to OneAgent. The metric defined for the same MBean and attribute will be also available in other Java processes across your application, which can quickly exhaust your custom metric limit.
You can also select individual hosts on which to run your new JMX extension, instead of running it globally across your whole environment.
When the metrics list is downloaded, click the Add metric button to start creating your extension.
Select the domain.
Key properties filter the list of available MBeans. Note that property values can contain wildcards. Select Exact match to filter MBeans list only to the entries matching the exact key property values.
Select one MBean from the list or leave All matching MBeans option. If more than one MBean is matched, this will cause the aggregation of attributes from all matching MBeans into one metric. You will define the aggregation type below.
The attributes available in the list are only the numeric ones. To see other attributes, for example attributes of the String
type, select Include non-numeric attributes. Note that selected attributes must be parsable to double, or boolean type. Otherwise, Dynatrace OneAgent will not collect any data from such a metric.
You can define a custom display name for the metric.
Select the metric unit.
Select the aggregation method if you're pulling an attribute from a number of matching Mbeans.
Delta calculates the change in values of the given attribute. Rate calculates the rate of changes per seconds. When you select both, you can convert an absolute attribute (eg. Request Count) to a rate (eg. Requests per Second). Value = attribute / query interval.
Creating the PMI extension is very similar to the JMX extension. PMI Module translates to JMX Mbean and statistics to attributes. All other settings behave accordingly.
After you add the metric, you can still edit or delete its definition. You must click the Save button to register the extension and start collecting data from all Java processes that contain defined MBeans. After you save the extension, you cannot edit or delete the metrics, as this way we're able to maintain the continuity of your data. You can still add the new metrics. This time however, you won't be able to select the base Java process, because you will use a process where the extension is already deployed.
The Dynatrace JMX extensions are highly customizable beyond the capabilities of the editor. You can download your extension and edit its JSON file that describes your JMX metrics and how you want to display them. For reference and examples, see Customizing JMX Plugins.
JMX metrics are available for all Java-based processes monitored by OneAgent.
Once your extension is uploaded, Dynatrace automatically begins querying the defined metrics for all Java processes. To find the metrics, go to a relevant process page and click Further details.
For example, for a extension named HornetQ
, go to the process you selected when creating the extension, click Further details and then select the HornetQ tab named automatically after the extension name. You'll find all the defined metrics there.
JMX monitoring is highly dynamic. If a particular metric doesn’t exist in your JVM, it's not an error—the metric simply isn't available.
You may notice that the number of metrics in the plugin.json
file of your JMX/PMI extension differs from the number of billed custom metrics. This is because JMX/PMI extensions provide "splittings" which can be used to define additional dimensions for reported metrics. For each value of a selected property, a separate timeseries metric is created at runtime. The actual number of timeseries metrics depends on the number of distinct values for the selected property.
The following sample shows how to define a metric that provides multiple timeseries with a single metric:
"metrics": [{"timeseries": {"key": "XY.Size","unit": "Count","displayname": "Queue Consumer Count","dimensions": ["rx_pid","name"]}"source": {"domain": "com.sample","keyProperties": {"type": "XY","name": "*"},"attribute": "Size","splitting": {"name": "name","type": "keyProperty","keyProperty": "name"}}}]
In this example, MBeans com.sample:type=XY,name=A
and com.sample:type=XY,name=B
will result in two timeseries metrics (A
and B
).
Since such values typically aren't known in advance, and are subject to change, this can lead to an unexpectedly high number of consumed custom metrics. If the values of the property are known in advance, or if only some of the values are of interest, we recommend that you specify one metric for each value and not use splitting.
There can be no more than 5,000
metrics per JMX extension. This limit is necessary to prevent underperforming or metric-heavy extensions from overwhelming the monitoring system.