---
title: OpenTelemetry APM UI
source: https://docs.newrelic.com/docs/opentelemetry/get-started/apm-monitoring/opentelemetry-apm-ui
---

The OpenTelemetry APM UI provides a comprehensive monitoring experience for services instrumented with OpenTelemetry, offering the same powerful APM capabilities you expect from New Relic's traditional language agents.

## Prerequisites

Before using the OpenTelemetry APM UI, ensure you have:

-   Configured your service with OpenTelemetry instrumentation
-   Set up your service to send data to New Relic
-   Created [OpenTelemetry service entities](https://docs.newrelic.com/docs/opentelemetry/best-practices/opentelemetry-best-practices-resources/#services)

If you haven't completed these steps, see [OpenTelemetry APM monitoring](https://docs.newrelic.com/docs/opentelemetry/get-started/apm-monitoring/opentelemetry-apm-intro/) for setup instructions.

## Find your OpenTelemetry services [#find-apm-services]

To locate your OpenTelemetry-instrumented services:

1.  In the New Relic UI, navigate to **All entities > Services - OpenTelemetry** or **APM & Services**
2.  Select a service to open its [Summary page](#summary-page)

> #### 💡 TIP
>
> Use [entity tags](https://docs.newrelic.com/docs/new-relic-solutions/new-relic-one/core-concepts/use-tags-help-organize-find-your-data/) in the entity explorer to filter services. Learn more about how entity tags are computed in [OpenTelemetry resources in New Relic](https://docs.newrelic.com/docs/opentelemetry/best-practices/opentelemetry-best-practices-resources).

## How OpenTelemetry works with New Relic APM

OpenTelemetry-instrumented services provide the same curated APM experience as services using New Relic's language agents. Here's how it works:

### Data mapping process

New Relic automatically maps your OpenTelemetry data to our APM conventions by:

1.  **Generating APM metrics**: We create the metrics needed for the APM experience directly from your OpenTelemetry data
2.  **Preserving original data**: Your original OpenTelemetry data remains available for custom dashboards and alerts
3.  **Normalizing conventions**: We handle OpenTelemetry's evolving semantic conventions so you don't have to track version differences

### Benefits for existing New Relic users

If you're transitioning from New Relic agents to OpenTelemetry, you can continue using familiar metrics and queries while adopting OpenTelemetry standards.

> #### ⚠️ IMPORTANT
>
> **Why we normalize OpenTelemetry data**
>
> OpenTelemetry's semantic conventions are still evolving, with many not yet stable. By normalizing your data to New Relic conventions, we:
>
> -   Reduce the complexity of tracking which OpenTelemetry convention versions your instrumentation uses
> -   Provide a consistent experience as you transition from New Relic agents to OpenTelemetry
> -   Ensure your APM experience remains stable regardless of OpenTelemetry changes

### Data sources and prioritization

The APM experience uses three types of OpenTelemetry data:

-   **Metrics** (primary): Provide accurate service statistics like throughput, response time, and error rate
-   **Spans** (supplementary): Used when metrics aren't available or for specific features like transaction traces
-   **Logs**: Integrated for troubleshooting and correlation

**Why metrics are preferred**: Metrics give a complete picture of your service performance, while spans are typically sampled and may not represent all traffic.

The APM experience primarily leverages these OpenTelemetry semantic conventions:

-   [HTTP](https://opentelemetry.io/docs/specs/semconv/http/) - Web transactions and external calls
-   [RPC](https://opentelemetry.io/docs/specs/semconv/rpc/) - Remote procedure calls
-   [Messaging](https://opentelemetry.io/docs/specs/semconv/messaging/) - Message queue operations
-   [Database](https://opentelemetry.io/docs/specs/semconv/database/) - Database operations

### How transactions are derived from OpenTelemetry data [#transaction-mapping]

New Relic’s APM experience is centered around the notion of a [transaction](https://docs.newrelic.com/docs/apm/transactions/intro-transactions/transactions-new-relic-apm/). When using a New Relic agent, it is the responsibility of the agent’s instrumentation to define the scope of a transaction (e.g., a single web request). The agent produces metric data that drives the vast majority of the New Relic APM experience by recording transaction metrics measuring the duration of transactions and its individual operations (e.g., external calls and database calls).

OpenTelemetry instrumentation does not have a direct analog to a New Relic transaction, so adapting the notion of transactions to OpenTelemetry data is key.

By leveraging OpenTelemetry’s [semantic conventions](https://opentelemetry.io/docs/concepts/semantic-conventions/) we can take advantage of OpenTelemetry’s highly structured and standardized means of describing telemetry in order to drive the APM experience in a very similar way to that of New Relic’s agents.

The semantic conventions define standard metrics for measuring common operations such as handling [HTTP](https://opentelemetry.io/docs/specs/semconv/http/http-metrics/) or [RPC](https://opentelemetry.io/docs/specs/semconv/rpc/rpc-metrics/)
requests. These metrics are analogous to the transaction metrics that New Relic agents produce for describing [Web transactions](https://docs.newrelic.com/docs/apm/transactions/intro-transactions/transactions-new-relic-apm/#types). We leverage OpenTelemetry’s HTTP and RPC metrics to synthesize metrics that drive the APM UI such as the [`apm.service.transaction.duration` metric](#metric-apm-service-transaction-duration).

New Relic also provides a notion of a [non-web transaction](https://docs.newrelic.com/docs/apm/transactions/intro-transactions/monitor-background-processes-other-non-web-transactions/). Non-web transactions are commonly used for systems that perform message
processing. Instrumentation that leverages OpenTelemetry’s [messaging conventions](https://github.com/open-telemetry/semantic-conventions/blob/main/docs/messaging/messaging-spans.md) will result in synthesizing metrics representing non-web transactions.

> #### ⚠️ IMPORTANT
>
> **Messaging operations and span data**
>
> OpenTelemetry's messaging conventions are less mature than HTTP and RPC conventions. Currently, we generate non-web transaction metrics for messaging operations from span data rather than metric data. This approach follows the messaging semantic conventions but may be affected by your sampling strategy.

#### Transaction names

Each transaction has a name which is derived from attributes required by OpenTelemetry’s semantic conventions. Refer to the [APM Service Metrics](#apm-service-metrics) section for how this name is derived.

##### Unknown transaction name

Sometimes you may see a transaction with `unknown` in the name. This is an indication that the source data used to derive the transaction does not follow any of the established OpenTelemetry semantic conventions which we currently support.

Some examples:

-   HTTP metrics missing `http.request.method` or `http.route`. For example, if the `http.server.request.duration` metric is missing the `http.route` attribute then the transaction name will be `WebTransaction/server/GET unknown`.
-   Frameworks or protocols for which OpenTelemetry does not currently define semantic conventions for (e.g., background jobs and CI frameworks).

## Navigating the APM experience

### Summary [#summary-page]

The [summary page](https://docs.newrelic.com/docs/apm/agents/manage-apm-agents/agent-data/triage-run-diagnostics/) provides an overview of your service's health and is centered around New Relic's notion of a [transaction](https://docs.newrelic.com/docs/apm/transactions/intro-transactions/transactions-new-relic-apm/). See [How transactions are derived from OpenTelemetry data](#transaction-mapping) for more details.

The New Relic metrics that drive the Summary page are the [`apm.service.transaction.duration`](#metric-apmservicetransactionduration) and [`apm.service.error.count`](#metric-apmservicetransactionduration) metrics. Refer to them for details on how they are derived from your OpenTelemetry data.

#### Customizing Apdex Target [#customizing-apdex-target]

In New Relic instrumentation, custom apdex targets are configured using agent configuration. For OpenTelemetry, when viewing a service navigate to **Settings > Application** to configure your Apdex target.

### Distributed tracing [#distributed-tracing-page]

The distributed tracing page provides detailed insights into OpenTelemetry trace data. See [Distributed tracing](https://docs.newrelic.com/docs/distributed-tracing/ui-data/understand-use-distributed-tracing-ui/) for page usage information. See [OpenTelemetry traces in New Relic](https://docs.newrelic.com/docs/opentelemetry/best-practices/opentelemetry-best-practices-traces) for details on how OpenTelemetry trace data is ingested into New Relic.

As with [golden signals](#golden-signals), spans are classified as errors if the span status is set to `ERROR` (for example, `otel.status_code = ERROR`). If the span is an error, the span status description (for example, `otel.status_description`) is displayed in **error details**.

OpenTelemetry span events attach additional event context information to a particular span. They are most commonly used to capture exception information. If available, you can view a span's events in **trace details**.

> #### 💡 TIP
>
> The presence of a span exception event doesn't qualify the span as an error on its own. Only spans with span status set to `ERROR` are classified as errors.

![Screenshot showing the right pane showing the two links for span events](https://docs.newrelic.com/images/opentelemetry_screenshot-crop_view-span-events.webp "Screenshot showing the right pane showing the two links for span events")

### Service map [#service-map-page]

The service map page provides a visual representation of your entire architecture. See [Service maps](https://docs.newrelic.com/docs/new-relic-solutions/new-relic-one/ui-data/service-maps/service-maps/) for more information.

### Transactions [#transactions-page]

The [transactions page](https://docs.newrelic.com/docs/apm/apm-ui-pages/monitoring/transactions-page-find-specific-performance-problems/) provides tools for identifying problems with and analyzing a service's [transactions](https://docs.newrelic.com/docs/apm/transactions/intro-transactions/transactions-new-relic-apm/#txn-defined).

OpenTelemetry does not have a direct analog to New Relic's notion of a transaction. See [How transactions are derived from OpenTelemetry data](#transaction-mapping) for more details.

The New Relic metrics that drive the Transaction page are the [`apm.service.transaction.duration`](#metric-apmservicetransactionduration) and [`apm.service.error.count`](#metric-apmservicetransactionduration) metrics. Refer to them for details on how they are derived from your OpenTelemetry data.

#### Transaction traces

[Transaction traces](https://docs.newrelic.com/docs/apm/transactions/transaction-traces/introduction-transaction-traces/) for OpenTelemetry are derived from your span data. On the transactions page you can find a list of transaction traces. This list requires the span data and metric data for a given transaction be correlated together. We do this by adding a `transaction.name` attribute to the root span of a transaction trace.

#### Segment breakdown [#segment-breakdown]

Clicking on a transaction opens a detailed view of the transaction revealing a
segment breakdown. Unlike New Relic agents, OpenTelemetry does not emit metrics
for individual segments. Therefore, the New Relic metrics required for driving
the segment breakdown are derived from span data.

The notable downside to computing segment breakdown from span data is that
spans are usually sampled. Though, even with sampling, the segment breakdown
can still serve to help you identify specific methods or operations that
consume the most time within a transaction.

From span data, we estimate a sampling rate by computing a throughput based on
span data received and divide that by the actual throughput as reported by your
metric data. The estimated sampling rate enables us to extrapolate the segment
breakdown of a transaction.

This process is not perfect and can be affected by a number of factors, most
notably your sampling strategy. It works best when you're strictly sampling
a percentage of your span data. However, for example, if you sample only
spans representing errors, then the segment breakdown may be skewed.

### Databases [#databases-page]

The databases page provides tools for identifying problems with and analyzing a
service's database client operations.

OpenTelemetry instrumentation represents calls to databases using the
[database](https://opentelemetry.io/docs/specs/semconv/database/)
semantic conventions.

The New Relic metric that drives the databases page is the
[`apm.service.datastore.operation.duration`](#metric-apmservicedatastoreoperationduration)
metric. Refer to it for details on how it is derived from your
OpenTelemetry data.

#### Time consumption by caller

When you click on a specific database call, you will see the
"Time consumption by caller" chart. This chart is driven by the
[`apm.service.transaction.overview`](#metric-apmservicetransactionoverview) metric.
This is the same metric that drives the [segment breakdown](#segment-breakdown)
view of the transaction page and it is derived from span data.

> #### ⚠️ IMPORTANT
>
> OpenTelemetry's database semantic conventions were recently deemed stable.
> There does not yet exist many stable instrumentations, and the instrumentation
> that does exist often only emits span data and no metric data.
>
> As such, when using instrumentation that has not yet adopted the stable
> semantic conventions, the APM metrics generated driving the database page are
> derived from span data.
>
> As stable instrumentation becomes available and you adopt it, the database page
> will begin to leverage OpenTelemetry metric data. Reach out to the OpenTelemetry
> community regarding the availability of stable database instrumentation in your
> language.

### External services [#externals-page]

The [external services page](https://docs.newrelic.com/docs/apm/apm-ui-pages/monitoring/external-services/external-services-ui/)
provides tools for identifying problems with and analyzing a service's external
calls, including calling entities (upstream services) and called entities
(downstream services).

OpenTelemetry instrumentation represents calls to external services using the
[HTTP](https://opentelemetry.io/docs/specs/semconv/http/) and [RPC](https://opentelemetry.io/docs/specs/semconv/rpc/)
semantic conventions.

The New Relic metric that drives the databases page is the
[`apm.service.external.host.duration`](#metric-apmserviceexternalhostduration)
metric. Refer to it for details on how it is derived from your
OpenTelemetry data.

#### Time consumption by caller

When you click on a specific external call, you will see the
"Time consumption by caller" chart. This chart is driven by the
[`apm.service.transaction.overview`](#metric-apm-service-transaction-overview) metric.
This is the same metric that drives the [segment breakdown](#segment-breakdown)
view of the transaction page and it is derived from span data.

### JVM runtime [#jvm-runtime-page]

The JVM runtime page provides tools for identifying problems with and analyzing
a Java service's JVM. The page is only displayed for services using [OpenTelemetry Java](https://opentelemetry.io/docs/languages/java/).
In order to differentiate between distinct service instances, the page requires
the `service.instance.id` resource attribute to be set (see
[Services](https://docs.newrelic.com/docs/opentelemetry/best-practices/opentelemetry-best-practices-resources/#services)
for more details).

The JVM runtime page shows golden signals alongside JVM runtime metrics to
correlate runtime issues with service usage.

The queries assume data conforms to the [JVM metric](https://opentelemetry.io/docs/specs/semconv/runtime/jvm-metrics/)
semantic conventions. Note, these conventions are embodied in
[OpenTelemetry Java runtime instrumentation library](https://github.com/open-telemetry/opentelemetry-java-instrumentation/tree/main/instrumentation/runtime-telemetry/runtime-telemetry-java8/library),
which is automatically included with the OpenTelemetry java agent.

### Go runtime [#go-runtime-page]

The Go runtime page provides tools for identifying problems with and analyzing
a Go service's runtime. The page is only displayed for services using [OpenTelemetry Go](https://opentelemetry.io/docs/languages/go/).
In order to differentiate between distinct service instances, the page requires
the `service.instance.id` resource attribute to be set (see [Services](https://docs.newrelic.com/docs/opentelemetry/best-practices/opentelemetry-best-practices-resources/#services)
for more details).

The Go runtime page shows golden signals alongside Go runtime metrics to
correlate runtime issues with service usage.

The queries assume data is produced by the [OpenTelemetry Go runtime instrumentation library](https://opentelemetry.io/docs/specs/semconv/runtime/go-metrics/).

> #### ⚠️ IMPORTANT
>
> The [semantic conventions](https://github.com/open-telemetry/semantic-conventions/blob/main/docs/runtime/go-metrics.md)
> for Go runtime metrics are still under development. The Go runtime page targets
> an older version of the conventions. You must enable the old conventions by
> enabling the `OTEL_GO_X_DEPRECATED_RUNTIME_METRICS` environment variable. For more
> information refer to the [documentation](https://github.com/open-telemetry/opentelemetry-go-contrib/blob/9a6e0bf68e1da495be52faf152b5b4e6fb09d475/instrumentation/runtime/internal/x/README.md)
> for the instrumentation.
>
> New Relic will eventually support the new conventions once they become stable.

### Logs [#logs-page]

The Logs page provides tools for identifying problems and analyzing a service's
logs. See [Use logs UI](https://docs.newrelic.com/docs/logs/ui-data/use-logs-ui/) for more information.

### Errors inbox [#errors-inbox-page]

The errors inbox page provides tools for detecting and triaging a service's
errors. See [Getting started with errors inbox](https://docs.newrelic.com/docs/errors-inbox/getting-started/)
for more details.

The errors inbox page is driven by trace data. As with [golden signals](#golden-signals),
spans are classified as errors if the span status is set to `ERROR` (for
example, `otel.status_code = ERROR`).

Error spans are grouped together by their error fingerprint, computed by
normalizing away identifying values such as UUIDs, hex values, email addresses,
etc. Each distinct error span is an individual instance within the error group.
The error group message is determined as follows:

-   Span status description (for example, `otel.status_description`)
-   `rpc.grpc.status_code` from [RPC span](https://opentelemetry.io/docs/specs/semconv/rpc/rpc-spans/) semantic conventions
-   `http.status_code` from [HTTP span](https://opentelemetry.io/docs/specs/semconv/http/http-spans/) semantic conventions
-   `http.response.status_code` from [HTTP span](https://opentelemetry.io/docs/specs/semconv/http/http-spans/) semantic conventions
-   `undefined` if none of the above are present

### Span View (Legacy) [#span-view-legacy]

In the past, OpenTelemetry instrumented services lit up an entirely different
user experience from that of New Relic's language agents. This older experience
provided curated charts driven from span data. Span data is usually sampled, so
it can be misleading particularly when representing things like throughput.

For now, the old user experience is still available via the Span View (Legacy)
page. At the top, it contains four tabs: Summary, Transactions, Databases, and
External services. All the charts on these tabs are driven from span data.

> #### 💡 TIP
>
> **Legacy span-based view**
>
> Our older OpenTelemetry APM experience allowed viewing data from both metric and span perspectives. Since span data is typically sampled, metrics provide more accurate throughput and response time measurements. The span-based view is still available but will be phased out. See [Span View (Legacy)](#span-view-legacy) for details.

## How errors are represented in New Relic [#errors]

Error information from your application surfaces in two places in the APM UI:

-   **Error rate**: Displayed on the [summary page](#summary-page), derived from
    metric data. When an OpenTelemetry metric such as `http.server.request.duration`
    or `rpc.server.call.duration` includes an `error.type` attribute, that data
    point contributes to the error rate.
-   **Errors inbox**: See the [errors inbox page](#errors-inbox-page), driven by
    span data. A span is classified as an error when its status is set to `ERROR`
    (for example, `otel.status_code = ERROR`).

### Ignore errors [#ignore-errors]

New Relic language agents can be configured to ignore errors by HTTP status
code or error class, preventing them from affecting error rate or appearing
in errors inbox. With OpenTelemetry, there is no equivalent agent configuration,
but the same effect can be achieved by manipulating the underlying data before
it reaches New Relic.

#### Ignore errors in error rate

The error rate is derived from the same metric data that we
[derive transactions](#transaction-mapping) from. When a metric such as
`http.server.request.duration` or `rpc.server.call.duration` includes an
`error.type` attribute, that data point contributes to the error rate. Removing
the `error.type` attribute from a metric data point prevents it from being
counted as an error.

> #### ⚠️ IMPORTANT
>
> The `error.type` attribute did not exist in earlier versions of OpenTelemetry's
> semantic conventions. To support older instrumentation that follows earlier
> versions of the HTTP and RPC semantic conventions, New Relic leverages the
> `http.status_code` and `rpc.grpc.status_code` attributes to drive the error
> rate. These attributes were present on the older `http.server.duration` and
> `rpc.server.duration` metrics.

#### Ignore errors in errors inbox

Errors inbox is driven by span data. A span is classified as an error when its
status is set to `ERROR` (i.e., `otel.status_code = ERROR`). Unsetting
the span status so it is no longer `ERROR` prevents the span from appearing in
errors inbox.

#### Example: transform data with the OpenTelemetry Collector

The [OpenTelemetry Collector](https://opentelemetry.io/docs/collector/) can be
used to transform metric and span data in transit to suppress specific errors.
The [ignored-errors example](https://github.com/newrelic/newrelic-opentelemetry-examples/tree/main/other-examples/ignored-errors)
provides a working collector configuration demonstrating how to:

-   Remove the `error.type` attribute from metric data points to exclude them from error rate
-   Unset the span status to prevent error spans from appearing in errors inbox

## New Relic APM metrics derived from span data [#apm-metrics-from-span-data]

The New Relic APM metrics that drive the APM experience are usually derived
from metric data. However, there are a few scenarios where APM metrics are
derived from span data. For the following scenarios note that the sampling
strategy you're using will influence the metrics generated.

### Segment breakdown

The transaction segment breakdown view is driven from span data.
See [Segment breakdown](#segment-breakdown) for more information.

### Database calls

The [OpenTelemetry database semantic conventions](https://opentelemetry.io/docs/specs/semconv/database/)
were recently declared stable. However, most database instrumentation has not
yet adopted the stable conventions and does not yet emit metric data.
Therefore, when using older instrumentation, the metrics that drive the
[database page](#databases-page) are generated from span data. You're
encouraged to upgrade to the latest stable database instrumentation as soon as
it becomes available for your language.

### Messaging systems

The [OpenTelemetry messaging semantic conventions](https://opentelemetry.io/docs/specs/semconv/messaging/)
are still in development. Most messaging instrumentation does not yet emit
metric data. New Relic represents interations with messaging systems as non-web
transactions. See [How transactions are derived from OpenTelemetry data](#transaction-mapping)
for more information.

### OpenTelemetry Ruby

OpenTelemetry supports metrics for most languages now, however Ruby is a
notable exception. For Ruby, we perform a best-faith effort to generate New
Relic APM metrics from span data.

## APM Service Metrics

The `apm.service.*` metrics drive New Relic’s APM experience. The following sections describe the source OpenTelemetry data that is used to derive `apm.service.*` metrics.

### Metric resource attributes

The following resource attributes are copied from source data on to APM metrics:

-   `container.id`
-   `entity.guid`
-   `host.name`
-   `instrumentation.provider`
-   `k8s.cluster.name`
-   `k8s.container.name`
-   `k8s.namespace.name`
-   `k8s.pod.name`
-   `service.instance.id`
-   `service.name`

### Metric: `apm.service.transaction.duration`

| **Name**                           | **[Instrument Type](https://docs.newrelic.com/docs/data-apis/understand-data/metric-data/metric-data-type/)** | **Unit ([UCUM](https://ucum.org/ucum))** | **Description**                   |
| ---------------------------------- | ------------------------------------------------------------------------------------------------------------- | ---------------------------------------- | --------------------------------- |
| `apm.service.transaction.duration` | Distribution                                                                                                  | `s`, `ms`, `ns` **[1]**                  | Duration of transactions. **[2]** |

| **Attribute**     | **Type** | **Description**                                        | **Example**                                                                 |
| ----------------- | -------- | ------------------------------------------------------ | --------------------------------------------------------------------------- |
| `transactionName` | `string` | The name of the transaction.                           | `WebTransaction/server/GET /users/:id`, `OtherTransaction/consumer/unknown` |
| `transactionType` | `string` | The type of the transaction.                           | `Web`, `Other`                                                              |
| `error.type`      | `string` | Describes a class of error the transaction ended with. | `500`, `TimeoutException`                                                   |

**[1]**: Unit from source metric is copied.

**[2]**: If `error.type` resolves to non-null, `apm.service.error.count` is incremented with the respective count of the source data.

#### Metric sources

| **Semantic Convention**                                                                                                                                       | **Metric name**                | **Conditions**                    | **`transactionName`**                                                                | **`transactionType`** | **`error.type`**                     |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------ | --------------------------------- | ------------------------------------------------------------------------------------ | --------------------- | ------------------------------------ |
| [`OtelHttpServer1_23`](https://github.com/open-telemetry/semantic-conventions/blob/v1.23.0/docs/http/http-metrics.md)                                         | `http.server.request.duration` | `http.request.method IS NOT NULL` | `WebTransaction/server/${http.request.method} ${http.route}`                         | `Web`                 | `${error.type}`                      |
| [`OtelHttpServer1_20`](https://github.com/open-telemetry/opentelemetry-specification/blob/v1.20.0/specification/metrics/semantic_conventions/http-metrics.md) | `http.server.duration`         | `http.method IS NOT NULL`         | `WebTransaction/server/${http.method} ${http.route}`                                 | `Web`                 | `__http_error_status_code_or_null__` |
| [`OtelRpcServer1_20`](https://github.com/open-telemetry/opentelemetry-specification/blob/v1.20.0/specification/trace/semantic_conventions/rpc.md)             | `rpc.server.duration`          | `rpc.system IS NOT NULL`          | `WebTransaction/server/${rpc.system}/${rpc.service:-unknown}.${rpc.method:-unknown}` | `Web`                 | `__rpc_error_status_code_or_null__`  |

### Metric: `apm.service.transaction.overview`

| **Name**                           | **[Instrument Type](https://docs.newrelic.com/docs/data-apis/understand-data/metric-data/metric-data-type/)** | **Unit ([UCUM](https://ucum.org/ucum))** | **Description**                          |
| ---------------------------------- | ------------------------------------------------------------------------------------------------------------- | ---------------------------------------- | ---------------------------------------- |
| `apm.service.transaction.overview` | Summary                                                                                                       | s                                        | Segment breakdown time of a transaction. |

| **Attribute**     | **Type** | **Description**                                                                                                                       | **Example**                                                                          |
| ----------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ |
| `transactionName` | `string` | The name of the transaction.                                                                                                          | `WebTransaction/server/GET /users/:id`, `OtherTransaction/consumer/unknown`          |
| `transactionType` | `string` | The type of the transaction.                                                                                                          | `Web`, `Other`                                                                       |
| domain attributes | various  | Domain specific attributes dependent on the source convention including: `db.system`, `db.sql.table`, `db.operation`, `external.host` | See `apm.service.external.host.duration`, `apm.service.datastore.operation.duration` |

#### Span sources

| **Semantic Convention**                                                                                                                                       | **Span kind**      | **Conditions**                               | **`transactionName`**                                                                                                                 | **`transactionType`**                    | **domain attributes**                                                                                                                                                                                               |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------ | -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [`OtelHttpServer1_23`](https://github.com/open-telemetry/semantic-conventions/blob/v1.23.0/docs/http/http-metrics.md)                                         | `server`           | `http.request.method IS NOT NULL`            | `WebTransaction/server/${http.request.method} ${http.route}`                                                                          | `Web`                                    |                                                                                                                                                                                                                     |
| [`OtelHttpServer1_20`](https://github.com/open-telemetry/opentelemetry-specification/blob/v1.20.0/specification/metrics/semantic_conventions/http-metrics.md) | `server`           | `http.method IS NOT NULL`                    | `WebTransaction/server/${http.method} ${http.route}`                                                                                  | `Web`                                    |                                                                                                                                                                                                                     |
| [`OtelRpcServer1_20`](https://github.com/open-telemetry/opentelemetry-specification/blob/v1.20.0/specification/trace/semantic_conventions/rpc.md)             | `server`           | `rpc.system IS NOT NULL`                     | `WebTransaction/server/${rpc.system}/${rpc.service:-unknown}.${rpc.method:-unknown}`                                                  | `Web`                                    |                                                                                                                                                                                                                     |
| [`OtelMessagingConsumer1_24`](https://github.com/open-telemetry/semantic-conventions/blob/v1.24.0/docs/messaging/messaging-spans.md)                          | `consumer`         | `messaging.operation IS NULL`                | `OtherTransaction/consumer/unknown`                                                                                                   | `Other`                                  |                                                                                                                                                                                                                     |
| [`OtelMessagingConsumer1_24`](https://github.com/open-telemetry/semantic-conventions/blob/v1.24.0/docs/messaging/messaging-spans.md)                          | `consumer`         | `messaging.operation IS NOT NULL`            | `OtherTransaction/consumer/${messaging.operation:-unknown}/${messaging.destination.template:-${messaging.destination.name:-unknown}}` | `Other`                                  |                                                                                                                                                                                                                     |
| [`OtelDbClient1_33`](https://github.com/open-telemetry/semantic-conventions/blob/v1.33.0/docs/database/database-metrics.md)                                   | `internal``client` | `db.system.name IS NOT NULL`                 | `transactionName` of the local root span                                                                                              | `transactionType` of the local root span | `db.system`: `${db.system.name}``db.sql.table`: `${db.stored_procedure.name:-${db.collection.name:-${__db_summary_to_sql_table__}}}``db.operation`: `${db.operation.name:-${__db_summary_to_operation__:-unknown}}` |
| [`OtelDbClientRedis1_24`](https://github.com/open-telemetry/semantic-conventions/blob/v1.24.0/docs/database/database-spans.md)                                | `client`           | `db.system IS NOT NULL``db.system = 'redis'` | `transactionName` of the local root span                                                                                              | `transactionType` of the local root span | `db.system`: `${db.system}``db.sql.table`: `${db.sql.table}``db.operation`: `${db.operation:-${name:-unknown}}`                                                                                                     |
| [`OtelDbClient1_24`](https://github.com/open-telemetry/semantic-conventions/blob/v1.24.0/docs/database/database-spans.md)                                     | `client`           | `db.system IS NOT NULL`                      | `transactionName` of the local root span                                                                                              | `transactionType` of the local root span | `db.system`: `${db.system}``db.sql.table`: `${db.sql.table}``db.operation`: `${db.operation:-unknown}`                                                                                                              |
| [`OtelHttpClient1_23`](https://github.com/open-telemetry/semantic-conventions/blob/v1.23.1/docs/http/http-metrics.md)                                         | `client`           | `http.request.method IS NOT NULL`            | `transactionName` of the local root span                                                                                              | `transactionType` of the local root span | `external.host`: `${server.address:-unknown}`                                                                                                                                                                       |
| [`OtelHttpClient1_20`](https://github.com/open-telemetry/opentelemetry-specification/blob/v1.20.0/specification/metrics/semantic_conventions/http-metrics.md) | `client`           | `http.method IS NOT NULL`                    | `transactionName` of the local root span                                                                                              | `transactionType` of the local root span | `external.host`: `${net.peer.name:-unknown}`                                                                                                                                                                        |
| [`OtelRpcClient1_20`](https://github.com/open-telemetry/opentelemetry-specification/blob/v1.20.0/specification/metrics/semantic_conventions/rpc-metrics.md)   | `client`           | `rpc.system IS NOT NULL`                     | `transactionName` of the local root span                                                                                              | `transactionType` of the local root span | `external.host`: `${net.peer.name:-unknown}`                                                                                                                                                                        |

### Metric: `apm.service.external.host.duration`

| **Name**                             | **[Instrument Type](https://docs.newrelic.com/docs/data-apis/understand-data/metric-data/metric-data-type/)** | **Unit ([UCUM](https://ucum.org/ucum))** | **Description**             |
| ------------------------------------ | ------------------------------------------------------------------------------------------------------------- | ---------------------------------------- | --------------------------- |
| `apm.service.external.host.duration` | Distribution                                                                                                  | `s`, `ms`, `ns` **[1]**                  | Duration of external calls. |

| **Attribute**   | **Type** | **Description**                                                                                         | Example                                    |
| --------------- | -------- | ------------------------------------------------------------------------------------------------------- | ------------------------------------------ |
| `external.host` | `string` | Server domain if available without reverse DNS lookup; otherwise, IP address or Unix domain socket name | `example.com`, `10.1.2.80`, `/tmp/my.sock` |

**[1]**: Unit from source metric is copied.

#### Metric sources

| **Semantic Convention**                                                                                                                                       | **Metric name**                | **Conditions**                    | **`external.host`**          |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------ | --------------------------------- | ---------------------------- |
| [`OtelHttpClient1_23`](https://github.com/open-telemetry/semantic-conventions/blob/v1.23.1/docs/http/http-metrics.md)                                         | `http.client.request.duration` | `http.request.method IS NOT NULL` | `${server.address:-unknown}` |
| [`OtelHttpClient1_20`](https://github.com/open-telemetry/opentelemetry-specification/blob/v1.20.0/specification/metrics/semantic_conventions/http-metrics.md) | `http.client.duration`         | `http.method IS NOT NULL`         | `${net.peer.name:-unknown}`  |
| [`OtelRpcClient1_20`](https://github.com/open-telemetry/opentelemetry-specification/blob/v1.20.0/specification/metrics/semantic_conventions/rpc-metrics.md)   | `rpc.client.duration`          | `rpc.system IS NOT NULL`          | `${net.peer.name:-unknown}`  |

### Metric: `apm.service.datastore.operation.duration`

| **Name**                                   | **[Instrument Type](https://docs.newrelic.com/docs/data-apis/understand-data/metric-data/metric-data-type/)** | **Unit ([UCUM](https://ucum.org/ucum))** | **Description**              |
| ------------------------------------------ | ------------------------------------------------------------------------------------------------------------- | ---------------------------------------- | ---------------------------- |
| `apm.service.datastore.operation.duration` | Distribution                                                                                                  | `s`, `ms`, `ns` **[1]**                  | Duration of datastore calls. |

**[1]**: Unit from source metric is copied.

| **Attribute**      | **Type** | **Description**                                                                            | **Example**                                                     |
| ------------------ | -------- | ------------------------------------------------------------------------------------------ | --------------------------------------------------------------- |
| `db.system`        | `string` | The database management system (DBMS) product as identified by the client instrumentation. | `postgresql`, `mysql`, `mariadb`                                |
| `db.sql.table`     | `string` | The name of a collection (table, container) within the database.                           | `public.users`, `customers`                                     |
| `db.operation`     | `string` | The name of the operation or command being executed.                                       | `findAndModify`, `HMSET`, `SELECT`                              |
| `db.query.summary` | `string` | Low cardinality summary of a database query.                                               | `SELECT wuser_table`, `INSERT shipping_details`, `SELECT order` |

#### Metric sources

| **Semantic Convention**                                                                                                     | **Metric name**                | **Conditions**               | **`db.system`**     | **`db.sql.table`**                                                                   | **`db.operation`**                                              | **`db.query.summary`** |
| --------------------------------------------------------------------------------------------------------------------------- | ------------------------------ | ---------------------------- | ------------------- | ------------------------------------------------------------------------------------ | --------------------------------------------------------------- | ---------------------- |
| [`OtelDbClient1_33`](https://github.com/open-telemetry/semantic-conventions/blob/v1.33.0/docs/database/database-metrics.md) | `db.client.operation.duration` | `db.system.name IS NOT NULL` | `${db.system.name}` | `${db.stored_procedure.name:-${db.collection.name:-${__db_summary_to_sql_table__}}}` | `${db.operation.name:-${__db_summary_to_operation__:-unknown}}` | `${db.query.summary}`  |

### Helper functions

Helper functions are references to bits of attribute mapping logic which are more involved than simple attribute references.

| **Function**                         | **Description**                                                                                                                                       |
| ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| `__http_error_status_code_or_null__` | Returns string value of `http.status_code if >= 500`                                                                                                  |
| `__rpc_error_status_code_or_null__`  | Returns string value of rpc.grpc.status_code if in set: `[2,4,12,13,14,15]`                                                                           |
| `__db_summary_to_operation__`        | Returns first word in `db.query.summary` in set (case insensitive): `[alter,call,create,delete,drop,exec,execute,insert,merge,select,set,update]`     |
| `__db_summary_to_sql_table__`        | Returns first word in `db.query.summary` NOT in set (case insensitive): `[alter,call,create,delete,drop,exec,execute,insert,merge,select,set,update]` |
| `__null__`                           | Placeholder for `null`                                                                                                                                |

## Golden signals [#golden-signals]

The golden signals of throughput, response time, and error rate appear in several places throughout the OpenTelemetry APM UI. When used, they are computed as follows:

For metrics, the queries assume data conforms to the [HTTP metric](https://opentelemetry.io/docs/specs/semconv/http/http-metrics/) or [RPC metric](https://opentelemetry.io/docs/specs/semconv/rpc/rpc-metrics/) semantic conventions.

For spans, the queries are generic, utilizing only the top level span data model. Spans are counted towards throughput and response time if they are root entry spans into a service, computed using a heuristic of `WHERE span.kind = server OR span.kind = consumer`. Spans are errors if they have a status code of `ERROR` (for example, `otel.status_code = ERROR`).

## Narrow data with filters [#narrow-with-filters]

Several pages include a filter bar, with options like **Narrow data to...**. This allows you to filter queries on the page to match the criteria. For example, you might narrow to a particular canary deployment by filtering for `service.version='1.2.3-canary'`. Filters are preserved when navigating between pages.

## Golden metrics

Golden metrics are low-cardinality versions of golden signals data, such as HTTP/RPC metrics. They populate various platform experiences, including the Entity Explorer, Workloads Activity page, and Change Tracking Details page. These metrics use names like `newrelic.goldenmetrics.ext.service.*`.

> #### ⚠️ IMPORTANT
>
> Historically, the OpenTelemetry golden metrics were calculated from spans. Spans are usually sampled, so they only provide a partial picture. Now that metrics are broadly available, golden metrics are calculated using metrics data rather than span data.