OpenTelemetry in the UI: JVMs page

When you compare JVMs or drill into a single JVM, you will see several timeseries charts of runtime metric data, including garbage collection and memory usage. The JVM-specific runtime metrics are specified in the OpenTelemetry semantic conventions and implemented in recent versions of the OTel auto-instrumentation agent.

For your data to appear in this section, make sure it has the following:

• The OpenTelemetry resource attribute service.instance.id, used to group JVM metrics by instance

We recommend you use the OpenTelemetry Java agent 1.13.0 or higher, which collects JVM memory usage as an asynchronous gauge. These agent versions allow you to view metrics in New Relic without the workarounds you'd need to do if you were using older agents.

If you're using older OpenTelemetry Java agents (versions 1.10.0 through 1.12.0), keep in mind that JVM memory usage switched from being collected as an asynchronous gauge to an asynchronous UpDownCounter. This has implications on the exported data. Gauges and counters export differently:

• Asynchronous gauges export as OTLP gauges.
• Asynchronous UpDownCounters export as OTLP non-monotonic sums.

If you configure your SDK to export metrics using delta aggregation temporality (which is required for counter and histogram instruments to function with New Relic), that results in asynchronous UpDownCounters exported as non-monotonic delta sums. New Relic can't perform any useful analysis of non-monotonic delta sum data.

If you have to use OpenTelemetry Java agent versions 1.10.0 through 1.12.0, the workaround is to use the View API to indicate that asynchronous UpDownCounters should be aggregated using last value aggregation instead of the default sum aggregation. This results in JVM memory usage being exported as gauge data, which is required for a useful experience in New Relic.

The way you configure the View API varies based on whether you're using the OpenTelemetry Java agent:

• If you are using the OpenTelemetry Java agent, you need to configure the View API in an extension. Extensions allow you to hook into the SDK configuration (among other things) and apply programmatic configuration that isn't available by environment variables or system properties. This example demonstrates how you can use an extension to customize the SdkMeterProvider's views.
• If you're not using the OpenTelemetry Java agent, review this simple example that shows how to register a view when configuring SdkMeterProvider.