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

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.

Important

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.

Copyright © 2024 New Relic Inc.

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