• Log in

Compare New Relic agents with OpenTelemetry

New Relic agents and OpenTelemetry are like similar wrenches in your toolbox: you need to choose the one best suited to your task. To help you choose the tool that is right for you, we've provided comparisons of various user experiences you can expect in New Relic with OpenTelemetry. Because of the rapid growth and change in our product, and in the open source community, we'll be updating this feature comparison regularly.

Our goal is to provide you the same world-class observability experience whether your data comes from New Relic agents or OpenTelemetry. The simple truth is that some experiences will be different because OpenTelemetry is a newer technology than New Relic agents, and it has a different data model. Though OpenTelemetry is rapidly growing in scope and maturity, there are still capabilities of the New Relic platform that aren’t yet supported by OpenTelemetry instrumentation or specifications. We are committed to adding more and more support for OpenTelemetry specifications in the New Relic platform.

We recommend you start with the table at the beginning that shows high-level comparisons. Then, you can use that information to focus on the detailed sections that are most important to you. The sections that follow have icons that describe whether you can expect particular experiences in New Relic:

  • ✅ Supported in New Relic
  • 🟡 Limited support in New Relic
  • ❌ Not supported in New Relic


Here are some ways navigate through these comparisons:

  • Scan the headings in the right navigation pane.
  • Use CONTROL-F to search the page for key phrases.
  • Expand all collapser sections by pressing s or hide with h.

High-level comparisons


New Relic agents

OpenTelemetry in New Relic

Collect metrics, traces, and logs

Collect custom events

❌ Not specified with OpenTelemetry

Measure and track SLIs/SLOs

🟡 Spans only at present

Optimize application performance

🟡 OpenTelemetry instrumentation varies significantly by language and is improving. New Relic agents have overall broader coverage of languages.

Discover root causes in complex systems

🟡 Front-end and Kubernetes observability is limited unless combined with New Relic agents

Triage and fix errors and exceptions

🟡 Front-end error triage is limited unless combined with New Relic agents

Understand system topology

Monitor Kubernetes

🟡 Better out-of-the-box experience with New Relic instrumentation

Monitor serverless functions

🟡 Better user experience with New Relic instrumentation, though setup is easier with OpenTelemetry for AWS Lambda

Improve end-user experience

🟡 RUM (real user monitoring) specifications in progress but traces can be collected

Alert on any telemetry

Detect and notify anomalies

🟡 Automatic anomaly detection is presently limited to New Relic Lookout

Create dashboards

Orchestrate and deploy observability tooling

Govern data ingest and storage

✅ The OpenTelemetry collector is one powerful tool for this purpose, requiring additional management

Share, export, and build upon observability data

See reported telemetry immediately

✅ Varies by data type

✅ Varies by data type

Reliable, high-scale telemetry ingest, storage, and query

Integrate with cloud platform vendors

Get support from New Relic technical experts

See our support offering

Summary page

New Relic agents: ✅       OpenTelemetry in New Relic: 🟡 Limited support

The Summary page offers an overview of a service’s health, charting golden signals about your entity: response time, throughput, and error rate. These are also broken down by service instance ID (OpenTelemetry) or hostname (New Relic agent).

OpenTelemetry services use spans to create golden signals, whereas New Relic agent services use metrics.

Filter/group data in the UI

New Relic agents: 🟡 Limited support       OpenTelemetry in New Relic: ✅

OpenTelemetry's service UIs in New Relic let you filter/group data in charts using any attribute. In New Relic One, only OpenTelemetry services have the filter bars shown below:

In contrast, the New Relic agent-based UI can be filtered/grouped by a more limited set of attributes. For example, all data can be filtered by host/instance. Several specialized views provide fixed groupings of their metrics, for example: by database query, by transaction/endpoint, by external service call, by error message and exception type, etc. In addition, event data available for many of these views can be filtered/grouped by any attribute.

Distributed tracing

New Relic agents: ✅       OpenTelemetry in New Relic: ✅

Distributed tracing is supported today by our agents and OpenTelemetry. Both provide W3C Trace Context compatibility. Furthermore, OpenTelemetry supports W3C Baggage, highly configurable sampling options, and events on spans, or New Relic span events.


New Relic agents: ✅       OpenTelemetry in New Relic: 🟡 Limited support

Transactions are a New Relic concept, representing an aggregation of requests to a particular endpoint. For OpenTelemetry we map this concept using trace data (see Transactions).

In order for data from an OpenTelemetry service to populate the Transactions page, the spans must be SpanKind of server or consumer. These spans represent requests processed by the service, which may be part of a larger trace involving more services. You may have to set this attribute manually if you want this data in the Transactions UI (see Transactions page).

The key difference between transactions (as a New Relic concept) and traces is the process boundary. A transaction is meant to encapsulate one logical unit of work done by a single process, whereas a trace can involve multiple units of work from multiple processes. A New Relic agent starts up by attaching itself to a process. The process may make calls to external services, but the boundary for a transaction begins and ends at that process.

A trace, on the other hand, does not have the same boundary and thus includes spans across all services that may be involved.


New Relic agents: ✅       OpenTelemetry in New Relic: 🟡 Limited support

The Databases page shows an application's database and cache data. It shows individual database transactions as a sortable table, and shows operations, throughput, and response time as charts.

The features of the database page will vary due to the following:

  • Differences in instrumentation coverage depending on the libraries being used
  • Different data sources are used to populate this page:
    • APM agent services use metrics, which are not subject to sampling effects
    • OpenTelemetry services use spans, which uses sampling


New Relic agents: ✅       OpenTelemetry in New Relic: 🟡 Limited support

The external services feature allows you to look closely at the upstream and downstream activity of a single service. Whether you’re monitoring with New Relic agents or OpenTelemetry, the external services feature shows transaction-level detail as you drill into connected services.

For OpenTelemetry, this view is based strictly on span data (which may be sampled), while New Relic agents report unsampled metrics on the interservice connections.


New Relic agents: ✅       OpenTelemetry in New Relic: 🟡 Limited support

Service map

New Relic agents: ✅       OpenTelemetry in New Relic: ❌

This map displays an entire set of interconnected services for a given service. The interconnected services must be actively reporting to appear in this map. Compare with these features: related entities and automap.


New Relic agents: ✅       OpenTelemetry in New Relic: ❌

For OpenTelemetry, the Related entities view can take you to all the dependencies for a given service.


New Relic agents: ✅       OpenTelemetry in New Relic: ✅

For OpenTelemetry services in the Errors page, the error rate is based off span data. Traces will be displayed if they contain a span or spans that meet the following conditions:

  • otel.status_code=ERROR
  • span.kind=server OR span.kind=consumer

The above also applies to exceptions, which are displayed as a span event on the span it was recorded on.

If you are not seeing an error that you expect to see in the Errors page, check the distributed tracing page since it does not exclude based on the span.kind attribute.

Errors inbox

New Relic agents: ✅       OpenTelemetry in New Relic: ✅

Metrics for services

New Relic agents: ✅       OpenTelemetry in New Relic: 🟡 Limited support

New Relic agents report a wider variety of metrics for services, some of which are detailed below. These metrics power certain user experiences, like databases, externals, and transactions.

OpenTelemetry metrics release candidate was announced earlier in May, with general availability expected soon. The metrics API, SDK, and Protocol are stable, with client libraries in Java, .NET, and Python existing in RC (release candidate).

Metrics explorer

New Relic agents: ✅       OpenTelemetry in New Relic: ✅

New Relic APM agents use timeslice metrics while OpenTelemetry uses dimensional metrics.

Events explorer

New Relic agents: ✅       OpenTelemetry in New Relic: ✅

For OpenTelemetry services, you can use this page to explore data about the spans and logs emitted by your service. To explore data about your span events, click on Span and then nr.spanEventCount, or query for SpanEvent.


New Relic agents: ✅       OpenTelemetry in New Relic: 🟡 Limited support

The APM view shows response time, throughput, error rate, end user response time, and PageView rates. The OpenTelemetry view only shows the first three metrics.


New Relic agents: ✅       OpenTelemetry in New Relic: 🟡 Limited support

For OpenTelemetry services, only other OpenTelemetry-instrumented services are shown in this view.

New Relic agents: ✅       OpenTelemetry in New Relic: ✅


New Relic agents: ✅       OpenTelemetry in New Relic: ❌

This concept is not covered by the OpenTelemetry specification.

Thread profiler

New Relic agents: ✅       OpenTelemetry in New Relic: ❌

Runtime/VM observability

Browsers page


Related entities

New Relic agents: ✅       OpenTelemetry in New Relic: 🟡 Limited support

This view shows:

  • Relationships between services (APM and OpenTelemetry services)
  • Relationships between services and infrastructure (not supported for OpenTelemetry services)

Relationships will be inferred between any services that use Distributed Tracing or report OpenTelemetry traces with W3C trace context. These will appear in Related Entities.

Relationships to unmonitored external services and databases are only generated for APM services at this time.


New Relic agents: ✅       OpenTelemetry in New Relic: ❌

To gather environment information for OpenTelemetry services, you can look at the span attributes (either in the distributed tracing page or by querying) to find certain environment information, such as the language SDK being used.

It may not necessarily be reported by the SDK in use, but users can manually set span attributes to include it and other environment information that is helpful for them.


New Relic agents: ✅       OpenTelemetry in New Relic: ❌

There is no specification in OpenTelemetry for recording deployments. A potential workaround is to add a service.version attribute to spans, which you can then use to filter for different deployment versions in your environment. This workaround may not offer the same benefits you may be looking for. This is because the value of deployment markers is that they show up in the activity stream alongside anomalies and can be viewed in real time. However, it can still provide value by allowing filtering.

Activity stream

New Relic agents: ✅       OpenTelemetry in New Relic: 🟡 Limited support

Alert violations will be shown for all types of entities.

Service deployments, related deployments, and Java agent circuit breaker events will be shown for New Relic APM agent entities.

Faster time-to-glass

New Relic agents: ✅       OpenTelemetry in New Relic: 🟡 Limited support

New Relic agents send events on a 15s interval and metrics on a 1m interval, although you can configure it to be faster or slower.

The OpenTelemetry Collector also allows you to configure reporting cycles, although there isn’t really a concept of a harvest cycle. There are similar concepts, but there's some variation for the different telemetry types. For example, there's a batch processor that can be triggered on a periodic basis or when the batch is full, but these time cycles are not enforced across all telemetry types.

Any data reported directly using the New Relic ingest endpoints (MELT, OTLP, etc.) will be available in the UI in less than 1 minute, although you can query data almost immediately.




New Relic agents: ✅       OpenTelemetry in New Relic: 🟡 Limited support

OpenTelemetry serverless function telemetry can be reported, stored, and visualized with custom dashboards. A dedicated view of this telemetry is not yet available.


New Relic agents: ✅       OpenTelemetry in New Relic: 🟡 Limited support

You can configure alerts on OpenTelemetry data using conditions written in NRQL. Click any chart’s “...” menu to get started.

Conditions, violations, incidents, and issues all work for any entity.

New Relic platform

Configuration options

Support Model

See our OpenTelemetry support policy for details.

Copyright © 2022 New Relic Inc.

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