--- title: OpenTelemetry metrics in New Relic source: https://docs.newrelic.com/docs/opentelemetry/best-practices/opentelemetry-best-practices-metrics --- OpenTelemetry provides a dimensional metrics [data model](https://opentelemetry.io/docs/specs/otel/metrics/data-model/), an [API](https://opentelemetry.io/docs/specs/otel/metrics/api/) for recording metric telemetry, and an [SDK](https://opentelemetry.io/docs/specs/otel/metrics/sdk/) for aggregating and exporting metric data. This page describes how New Relic handles OpenTelemetry metrics it receives via the [New Relic OTLP endpoint](https://docs.newrelic.com/docs/opentelemetry/best-practices/opentelemetry-otlp). See the following pages: - For endpoint configuration requirements, see [New Relic OTLP endpoint](https://docs.newrelic.com/docs/opentelemetry/best-practices/opentelemetry-otlp). - For instructions to configure services with OpenTelemetry, see [OpenTelemetry APM monitoring](https://docs.newrelic.com/docs/opentelemetry/get-started/apm-monitoring/opentelemetry-apm-intro). ## Instrument kind to metric type mapping [#instrument-mapping] The OpenTelemetry metrics API defines [several instrument kinds](https://opentelemetry.io/docs/specs/otel/metrics/api/#instrument). 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](#otlp-mapping) for details on how each metric type is treated in New Relic. | Instrument kind | Example usage | Default aggregation | Exported metric type | | -------------------------------------------------------------------------------------------------------------- | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [`Counter`](https://opentelemetry.io/docs/specs/otel/metrics/api/#counter) | Bytes processed | [Sum](https://opentelemetry.io/docs/specs/otel/metrics/sdk/#sum-aggregation) | [`Sum` metric](https://github.com/open-telemetry/opentelemetry-proto/blob/a05597bff803d3d9405fcdd1e1fb1f42bed4eb7a/opentelemetry/proto/metrics/v1/metrics.proto#L217-L226), with `is_monotonic=true` | | [Asynchronous Counter](https://opentelemetry.io/docs/specs/otel/metrics/api/#asynchronous-counter) | Observe total process CPU time | [Sum](https://opentelemetry.io/docs/specs/otel/metrics/sdk/#sum-aggregation) | [`Sum` metric](https://github.com/open-telemetry/opentelemetry-proto/blob/a05597bff803d3d9405fcdd1e1fb1f42bed4eb7a/opentelemetry/proto/metrics/v1/metrics.proto#L217-L226), with `is_monotonic=true` | | [`UpDownCounter`](https://opentelemetry.io/docs/specs/otel/metrics/api/#updowncounter) | Items in a queue | [Sum](https://opentelemetry.io/docs/specs/otel/metrics/sdk/#sum-aggregation) | [`Sum` metric](https://github.com/open-telemetry/opentelemetry-proto/blob/a05597bff803d3d9405fcdd1e1fb1f42bed4eb7a/opentelemetry/proto/metrics/v1/metrics.proto#L217-L226), with `is_monotonic=false` | | [Asynchronous UpDownCounter](https://opentelemetry.io/docs/specs/otel/metrics/api/#asynchronous-updowncounter) | Observe current memory usage | [Sum](https://opentelemetry.io/docs/specs/otel/metrics/sdk/#sum-aggregation) | [`Sum` metric](https://github.com/open-telemetry/opentelemetry-proto/blob/a05597bff803d3d9405fcdd1e1fb1f42bed4eb7a/opentelemetry/proto/metrics/v1/metrics.proto#L217-L226), with `is_monotonic=false` | | [`Histogram`](https://opentelemetry.io/docs/specs/otel/metrics/api/#histogram) | Duration of http requests | [Explicit Bucket Histogram](https://opentelemetry.io/docs/specs/otel/metrics/sdk/#explicit-bucket-histogram-aggregation) | [`Histogram` metric](https://github.com/open-telemetry/opentelemetry-proto/blob/a05597bff803d3d9405fcdd1e1fb1f42bed4eb7a/opentelemetry/proto/metrics/v1/metrics.proto#L230-L236) **[1]** | | [`Gauge`](https://opentelemetry.io/docs/specs/otel/metrics/api/#gauge) | Change events for CPU fan speed | [Last Value](https://opentelemetry.io/docs/specs/otel/metrics/sdk/#last-value-aggregation) | [`Gauge` metric](https://github.com/open-telemetry/opentelemetry-proto/blob/a05597bff803d3d9405fcdd1e1fb1f42bed4eb7a/opentelemetry/proto/metrics/v1/metrics.proto#L211-L213) | | [Asynchronous Gauge](https://opentelemetry.io/docs/specs/otel/metrics/api/#asynchronous-gauge) | Observe current room temperature | [Last value](https://opentelemetry.io/docs/specs/otel/metrics/sdk/#last-value-aggregation) | [`Gauge` metric](https://github.com/open-telemetry/opentelemetry-proto/blob/a05597bff803d3d9405fcdd1e1fb1f42bed4eb7a/opentelemetry/proto/metrics/v1/metrics.proto#L211-L213) | See [OpenTelemetry metrics supplementary guidelines](https://opentelemetry.io/docs/specs/otel/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](#otlp-histogram) for more details. ## OTLP metric mapping [#otlp-mapping] New Relic maps OTLP metrics to the [`Metric` data type](https://docs.newrelic.com/docs/data-apis/understand-data/metric-data/metric-data-type/#metric-types). The table below describes how fields from the [Metric proto messages](https://github.com/open-telemetry/opentelemetry-proto/blob/main/opentelemetry/proto/metrics/v1/metrics.proto) are interpreted. See [Instrument kind to metric type](#instrument-mapping) 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`](https://docs.newrelic.com/docs/data-apis/understand-data/metric-data/metric-data-type/#metric-types) | | `Metric.sum.data_points` | Maps to New Relic [`count`, `cumulativeCount`, or `gauge`](https://docs.newrelic.com/docs/data-apis/understand-data/metric-data/metric-data-type/#metric-types) See [OTLP sum metrics](#otlp-sum) | | `Metric.histogram.data_points` | Maps to New Relic [`distribution`](https://docs.newrelic.com/docs/data-apis/understand-data/metric-data/metric-data-type/#metric-types) See [OTLP histogram metrics](#otlp-histogram) | | `Metric.exponential_histogram.data_points` | Maps to New Relic [`distribution`](https://docs.newrelic.com/docs/data-apis/understand-data/metric-data/metric-data-type/#metric-types) See [OTLP histogram metrics](#otlp-histogram) | | `Metric.summary.data_points` | Maps to New Relic [`summary`](https://docs.newrelic.com/docs/data-apis/understand-data/metric-data/metric-data-type/#metric-types) See [OTLP summary metrics](https://github.com/open-telemetry/opentelemetry-proto/blob/a05597bff803d3d9405fcdd1e1fb1f42bed4eb7a/opentelemetry/proto/metrics/v1/metrics.proto#L254-L256) | **[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](https://docs.newrelic.com/docs/opentelemetry/best-practices/opentelemetry-otlp/#otlp-attribute-types) for details on New Relic OTLP endpoint supported attribute types and [OTLP attribute limits](https://docs.newrelic.com/docs/opentelemetry/best-practices/opentelemetry-otlp/#attribute-limits) for details on validation performed on attributes. ### OTLP sum metrics [#otlp-sum] OTLP [sum metrics](https://github.com/open-telemetry/opentelemetry-proto/blob/a05597bff803d3d9405fcdd1e1fb1f42bed4eb7a/opentelemetry/proto/metrics/v1/metrics.proto#L217-L226) represent the sum of measurements over time. Sums include an [`aggregation_temporality`](#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`](https://docs.newrelic.com/docs/data-apis/understand-data/metric-data/metric-data-type/#metric-types) | | `true` | `delta` | Maps to New Relic [`count`](https://docs.newrelic.com/docs/data-apis/understand-data/metric-data/metric-data-type/#metric-types) | | `false` | `cumulative` | Maps to New Relic [`gauge`](https://docs.newrelic.com/docs/data-apis/understand-data/metric-data/metric-data-type/#metric-types) | | `false` | `delta` | Not supported since data is not meaningful. See [this discussion](https://github.com/open-telemetry/opentelemetry-specification/pull/2314#pullrequestreview-877408961) for details. | ### OTLP histogram metrics [#otlp-histogram] OTLP [histogram metrics](https://github.com/open-telemetry/opentelemetry-proto/blob/a05597bff803d3d9405fcdd1e1fb1f42bed4eb7a/opentelemetry/proto/metrics/v1/metrics.proto#L230-L236) and [exponential histogram metrics](https://github.com/open-telemetry/opentelemetry-proto/blob/a05597bff803d3d9405fcdd1e1fb1f42bed4eb7a/opentelemetry/proto/metrics/v1/metrics.proto#L240-L246) 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](#aggregation-temporality) field. Both varieties of histograms are translated to New Relic [`distribution`](https://docs.newrelic.com/docs/data-apis/understand-data/metric-data/metric-data-type/#metric-types), 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 histogram aggregation](https://docs.newrelic.com/docs/opentelemetry/best-practices/opentelemetry-otlp/#metric-histogram-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](https://github.com/newrelic-experimental/newrelic-sketch-java#new-relic-sketch) 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] OTLP [summary metrics](https://github.com/open-telemetry/opentelemetry-proto/blob/a76fe9dea26871e8a6c494024bc9927fe73b8142/opentelemetry/proto/metrics/v1/metrics.proto#L274-L276) 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`](https://docs.newrelic.com/docs/data-apis/understand-data/metric-data/metric-data-type/#metric-types). Note that the New Relic summary type does not support quantiles. > #### ⚠️ IMPORTANT > > While summaries are ingested and translated to a New Relic [`summary`](https://docs.newrelic.com/docs/data-apis/understand-data/metric-data/metric-data-type/#metric-types), 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](#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 [#aggregation-temporality] The OpenTelemetry notion of [aggregation temporality](https://opentelemetry.io/docs/specs/otel/metrics/data-model/#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](#otlp-sum) and [histogram metrics](#otlp-histogram) 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](https://docs.newrelic.com/docs/opentelemetry/best-practices/opentelemetry-otlp/#metric-aggregation-temporality). When temporality is cumulative, metrics are converted to a delta representation (with the cumulative value retained for [`cumulativeCount`](https://docs.newrelic.com/docs/data-apis/understand-data/metric-data/metric-data-type/#metric-types), 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 [#exemplars] OpenTelemetry metric [exemplars](https://opentelemetry.io/docs/specs/otel/metrics/data-model/#exemplars) are not currently supported by New Relic.