OpenTelemetry metrics are largely compatible with New Relic dimensional metrics. We support OpenTelemetry metrics v0.10. All of the supported metric types include an independent set of associated attributes (name-value pairs) which map directly to dimensions you can use to facet or filter metric data at query time. OpenTelemetry metrics are accompanied by a set of resource attributes that identify the originating entity that produced them and map to dimensions for faceting and filtering.

The OpenTelemetry data model for metrics defines a number of different metric types: sum, gauge, histogram, and summary.

### Sum metrics

OpenTelemetry sums are a scalar metric that is the sum of all data points over a given time window. Sums have a notion of temporality indicating whether reported values incorporate previous measurements (cumulative temporality) or not (delta temporality).

In addition, sums can either be monotonic (only go up or only go down) or non-monotonic (go up and down).

#### Delta sums

Delta sums are handled differently depending on whether they are monotonic or non-monotonic:

- Monotonic delta sums are mapped to the count metric type.
- Non-monotonic delta sums are not supported. Things measured in this fashion do not generate meaningful data as they are most likely summed to be used. For more discussion, see this community pull request and our docs on gauges versus counters.

#### Cumulative sums

Cumulative sums are handled differently depending on whether they're monotonic or non-monotonic.

- Non-monotonic cumulative sums are mapped to the gauge metric type.
- Monotonic cumulative sums are mapped to our cumulativeCount metric type. This is true with the exception of accounts that were sending cumulative monotonic sums before April 4, 2023, which continue to be mapped to the
`gauge`

metric type: see our transition guide.

#### Sum configuration examples

To understand how to configure aggregation temporality, see these examples using the Java and Go OpenTelemetry SDKs.

### Gauge metrics

OpenTelemetry gauge metric data points represent a sampled value at a given time. These values are converted to the New Relic gauge metric type. OpenTelemetry gauges do not have an aggregation temporality, but the sampled values can be aggregated at query time.

### Histogram metrics

OpenTelemetry histograms compactly represent a population of recorded values along with a total count and sum. Optionally, histograms may include a series of buckets with explicit bounds and a count value for that bucket's population.

All OpenTelemetry histograms are converted to New Relic's distribution metric type, which is backed by a scaled exponential base 2 histogram (see NrSketch for a more thorough explanation).

#### Delta histograms

For exponential histograms, we are able to do a direct translation to NrSketch.

For explicit bounds histograms, counts from OpenTelemetry histogram buckets are assigned to New Relic's distribution metric buckets using linear interpolation. Also, OpenTelemetry has negative and positive infinity bound buckets which we represent in New Relic as zero-width buckets. We do this because we do not have a representation for negative and positive infinity. For example, an OpenTelemetry bucket with bounds `\[-∞, 10)`

will be represented by a `\[10,10)`

zero width New Relic bucket. You may see exaggerated bucket counts at the endpoints of your distribution due to this translation.

#### Cumulative histograms

Cumulative histograms are converted to a Delta histogram. For more on the translation process, see Cumulative metrics.

### Summary metrics

OpenTelemetry summary metric data points are used to represent quantile summaries (for example, P99 latency). These map directly to the New Relic summary metric type, however the only quantiles we maintain are the 0.0 and 1.0 quantiles for min and max. If percentiles are something you wish to capture, prefer Histogram metrics.

Summary metric data points include count, sum, and quantile values, with 0.0 as min and 1.0 as max. OpenTelemetry provides summary metrics for compatibility with other formats.

### Start time

The `startTimeUnixNano`

field is optional according to the OpenTelemetry specification. When this field is provided, it is used for the timestamp on the resulting New Relic metric, and the `duration`

is calculated as `timeUnixNano - startTimeUnixNano`

. The `duration`

field is used to calculate the queryable `endTimeStamp`

attribute on the New Relic metric, but it serves no other semantic purpose.

If `startTimeUnixNano`

is not provided, then `timeUnixNano`

is used for the timestamp field on the resulting New Relic metric, and the duration field is set to zero.

### Array values for attributes

OpenTelemetry metrics and other signals may include attributes that consist of a homogenous array of primitive types. New Relic supports non-nested homogeneous arrays with less than 65 elements.

### Exemplars

OpenTelemetry defines exemplar values that allow other signals, like traces, to be connected to a metric event and provide context. Exemplars are not supported by New Relic.

### How to query metrics

Consider these tips for building metric NRQL queries in New Relic.

#### Query cumulative sums stored as cumulativeCounts

Here are some ways to query your data:

#### Query cumulative sums stored as gauges

New Relic customers that reported cumulative sums before April 4, 2023, have their cumulative sums converted to our `gauge`

type. For details on how this is changing, see our Cumulative metrics transition guide.

If your cumulative sums are stored as the `gauge`

type, here are some ways to query your data:

#### Query gauge metrics

When New Relic converts cumulative sums to gauges, you can query them using either the `latest()`

or `derivative()`

NRQL functions. The function you choose depends on whether you want to see the raw value or compute the rate of change.

#### Query histogram metrics

New Relic histograms translated from OpenTelemetry metrics have the same query semantics as other New Relic histograms. Namely, the `histogram()`

NRQL function can be used to represent the histogram with a configurable number of buckets and bucket width. We translate cumulative histograms into delta histograms, so they are queried the same way a delta histogram would be queried. Note for explicit bounds histograms, that you may see larger bucket counts at the endpoint buckets. This is because we are adding negative and positive infinity bound OpenTelemetry buckets into a zero width New Relic bucket.

#### Important

The `TIMESERIES`

keyword is not supported for New Relic histograms unless charing `percentiles()`

.