After you've sent us your OpenTelemetry data and opened your service (entity) in the UI, click JVMs to identify which service instances have unusual or unhealthy performance patterns related to the behavior of the Java Virtual Machine.
You can choose several service instances to compare based on summaries of key metrics: response time, throughput, error rate, garbage collection time, and memory usage. Then, you can compare all those instances' JVM metrics collected by OpenTelemetry instrumentation using timeseries charts to spot problems.
Here's a typical workflow:
Click JVMs.
Find interesting JVMs using the table of summarized health metrics:
Use the filter bar to narrow down your search
Sort the columns of metric values to find outliers
Select those interesting JVMs.
Click Compare to see a display of the health and runtime metrics faceted by JVM.
You can also view all the runtime metrics for a single JVM by clicking the name of the instance in the table.
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 async 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 thorugh 1.12.0), keep in mind that JVM memory usage switched from being collected as an async gauge to an async up down counter. This has implications on the exported data. Gauges and counters export differently:
Async gauges export as OTLP gauges.
Async up down counters export as OTLP non-monotonic sums.
If you configure your SDK to export your metrics using delta aggregation temporality (which is required for counter and histogram instruments to function with New Relic), that results in async up down counters 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 async up down counters 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're not using the OpenTelemetry Java agent, review this simple example that shows how to register a view when configuring SdkMeterProvider.
If you’re 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 variable or system properties. This example demonstrates how you can use an extension to customize the SdkMeterProvider’s views.
To learn about OpenTelemetry in other UI pages, see the UI overview.