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. See the following pages:

For endpoint configuration requirements, see New Relic OTLP endpoint.
For instructions to configure services with OpenTelemetry, 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
`Counter`	Bytes processed	Sum	`Sum` metric, with `is_monotonic=true`
Asynchronous Counter	Observe total process CPU time	Sum	`Sum` metric, with `is_monotonic=true`
`UpDownCounter`	Items in a queue	Sum	`Sum` metric, with `is_monotonic=false`
Asynchronous UpDownCounter	Observe current memory usage	Sum	`Sum` metric, with `is_monotonic=false`
`Histogram`	Duration of http requests	Explicit Bucket Histogram	`Histogram` metric [1]
`Gauge`	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 and SDKs.

OTLP metric proto field	New Relic `Metric` field
`ResourceMetrics.Resource.attributes`	Each key/value is an attribute on the `Metric`[1]
`ScopeMetrics.InstrumentationScope.name`	`otel.library.name`
`ScopeMetrics.InstrumentationScope.version`	`otel.library.version`
`ScopeMetrics.InstrumentationScope.attributes`	Each key/value is an attribute on the `Metric`[1]
`Metric.name`	`metricName`
`Metric.description`	`description`
`Metric.unit`	`unit`
`Metric.*.data_points.start_time_unix_nano`	`timestamp`
`Metric.*.data_points.time_unix_nano`	`endTimestamp`
`Metric.*.data_points.attributes`	Each key/value is an attribute on the `Metric`[1]
`Metric.gauge.data_points`	Maps to New Relic `gauge`
`Metric.sum.data_points`	Maps to New Relic `count`, `cumulativeCount`, or `gauge` See OTLP sum metrics
`Metric.histogram.data_points`	Maps to New Relic `distribution` See OTLP histogram metrics
`Metric.exponential_histogram.data_points`	Maps to New Relic `distribution` See OTLP histogram metrics
`Metric.summary.data_points`	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.

See OTLP attribute types for details on New Relic OTLP endpoint supported attribute types.

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:

`is_monotonic`	`aggregation_temporality`	Behavior
`true`	`cumulative`	Maps to New Relic `cumulativeCount`
`true`	`delta`	Maps to New Relic `count`
`false`	`cumulative`	Maps to New Relic `gauge`
`false`	`delta`	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. Note that the New Relic summary type does not support quantiles.

Importante

While summaries are ingested and translated to a New Relic summary, they are not properly supported. New Relic assumes summaries represent a delta since the last measurement when in fact they are cumulative metrics (see aggregation temporality. Summaries are most commonly emitted by Prometheus which is a cumulative metrics system. Therefore, New Relic does not currently support the most common use case. As such, you will experience unexpected behavior for your summary metrics including failed ingest.

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.

Instrument kind to metric type mapping .css-21sua1{background:none;border:none;width:0;padding:0;}