• EnglishEspañol日本語한국어Português
  • Log inStart now

OpenTelemetry metrics in New Relic

OpenTelemetry provides a dimensional metrics data model, an API for recording metric telemetry, and an SDK for aggregating and exporting metric data.

This page describes how New Relic handles OpenTelemetry metrics it receives via the New Relic OTLP Endpoint. Integrating OpenTelemetry metrics with New Relic requires configuring the metric source to export to this endpoint - please review endpoint configuration requirements. For information on configuring services with OpenTelemetry metrics see OpenTelemetry APM monitoring.

Instrument kind to metric type mapping

The OpenTelemetry metrics API defines several instrument kinds. Instruments record measurements, which are aggregated and exported via OTLP as a particular metric type. The table below describes the default behavior on how each OpenTelemetry instrument aggregates and exports. See OTLP Metric Mapping for details on how each metric type is treated in New Relic.

Instrument kind

Example usage

Default aggregation

Exported metric type


Bytes processed


Sum metric, with is_monotonic=true

Asynchronous Counter

Observe total process CPU time


Sum metric, with is_monotonic=true


Items in a queue


Sum metric, with is_monotonic=false

Asynchronous UpDownCounter

Observe current memory usage


Sum metric, with is_monotonic=false


Duration of http requests

Explicit Bucket Histogram

Histogram metric [1]


Change events for CPU fan speed

Last Value

Gauge metric

Asynchronous Gauge

Observe current room temperature

Last value

Gauge metric

See OpenTelemetry metrics supplementary guidelines for details on choosing the correct instrument type.

[1] Histogram instruments can also be aggregated to exponential histogram metrics. See OTLP histogram metrics for more details.

OTLP metric mapping

New Relic maps OTLP metrics to the Metric data type. The table below describes how fields from the Metric proto messages are interpreted. See Instrument kind to metric type for details on how the various metric types are produced by OpenTelemetry APIs / SDKs.

OTLP metric proto field

New Relic Metric field


Each key/value is an attribute on the Metric[1]






Each key/value is an attribute on the Metric[1]












Each key/value is an attribute on the Metric[1]


Maps to New Relic gauge


Maps to New Relic count, cumulativeCount, or gauge

See OTLP sum metrics


Maps to New Relic distribution

See OTLP histogram metrics


Maps to New Relic distribution

See OTLP histogram metrics


Maps to New Relic summary

See OTLP summary metrics

[1]: In case of conflict in resource attributes, scope attributes, metric point attributes, and top level metric fields, the order of precedent (highest to lowest) is: top level Metric.* fields > Metric.*.data_points.attributes > ScopeMetrics.InstrumentationScope.attributes > ResourceMetrics.Resource.attributes.

OTLP sum metrics

OTLP sum metrics represent the sum of measurements over time. Sums include an aggregation_temporality field and an is_monotonic field, which indicates whether the values are monotonically increasing (i.e. can only go up) or not (i.e. can go up and down). The following table describes how New Relic treats different sum varieties:






Maps to New Relic cumulativeCount



Maps to New Relic count



Maps to New Relic gauge



Not supported since data is not meaningful. See this discussion for details.

OTLP histogram metrics

OTLP histogram metrics and exponential histogram metrics summarize a population of measurements with information like sum, count, min, max, and buckets describing the distribution of measurement values. The histogram variety (also called explicit bucket histogram) has buckets with explicit boundaries. The exponential variety has buckets with boundaries described by an exponential formula. Both varieties include an aggregation temporality field.

Both varieties of histograms are translated to New Relic distribution, which is backed by an internal base 2 exponential histogram representation. This representation closely mirrors the OpenTelemetry exponential histogram format. For this reason, New Relic prefers exponential histogram (see Metric mistogram aggregation for details on configuring OTLP to prefer exponential histograms). The OpenTelemetry explicit bucket histogram variety is translated to the exponential representation using linear interpolation. See NrSketch for a detailed explanation.

Buckets with boundaries at negative and positive infinity are represented in New Relic as zero-width buckets. For example, an OpenTelemetry bucket with bounds [-∞, 10) is represneted in New Relic as [10, 10). As a result, you may see exagerated bucket counts at the ends of your distribution.

OTLP summary metrics

OTLP summary metrics are similar to histograms in that they summarize a population of measurements, including sum and count. However, where histograms include buckets to describe the distribution of measurements, summaries include quantiles. These quantiles are of limited use since they cannot undergo spatial or temporal reaggregation. Summaries included in OpenTelemetry for legacy support, and OpenTelemetry APIs and SDK do not produce summaries.

Summaries are translated to New Relic summary.

Aggregation temporality

The OpenTelemetry notion of aggregation temporality defines whether a particular metric data point aggregates a cumulative set of measurements (typically since application start) or the delta set of measurements since last export. OTLP sum metrics and histogram metrics have an aggregation_temporality field which describes the semantics of their points.

Although we accept both cumulative and delta temporality metrics, New Relic is generally a delta metrics system, and we encourage users to configure your OTLP exporter to prefer delta temporality.

When temporality is cumulative, metrics are converted to a delta representation (with the cumulative value retained for cumulativeCount, using a stateful translation is a stateful process in which compute the delta from two consecutive cumulative cumulative points of the same series. The Metric.*.data_points.start_time_unix_nano is used to detect series resets.

Exemplars support

OpenTelemetry metric exemplars are not currently supported by New Relic.

Copyright © 2024 New Relic Inc.

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