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
👀 "Looking to OTel": Limited or missing support in OpenTelemetry
❌ Not supported in New Relic
Tip
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
Feature
New Relic agents
OpenTelemetry in New Relic
Collect metrics, traces, and logs
✅
✅
Collect custom events
✅
👀 Semantic conventions for events is currently an experimental capability in the OpenTelemetry specification. For more about events in New Relic, see Custom events below.
APM: Optimize application performance
✅
👀 OpenTelemetry instrumentation varies significantly by language and is improving. New Relic agents have overall broader coverage of languages.
APM: Discover root causes in complex systems
✅
👀 Front-end and Kubernetes observability is limited unless combined with New Relic agents
APM: Triage and fix errors and exceptions
✅
👀 Front-end error triage is limited unless combined with New Relic agents
Understand system topology and dependencies with maps
✅
✅
Monitor Kubernetes
✅
👀 Better out-of-the-box experience with New Relic or Pixie instrumentation
Monitor hosts
✅
✅
Monitor serverless functions
✅
👀 Better user experience with New Relic instrumentation, though setup is easier with OpenTelemetry for AWS Lambda
Improve browser and mobile end-user experience
✅
👀 RUM (real user monitoring) specifications in progress but end-to-end tracing works today
Alert on any telemetry
✅
✅
Detect and notify anomalies
✅
🟡 Automatic anomaly detection is presently limited to New Relic Lookout
Measure and track SLIs/SLOs
✅
✅
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
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).
New Relic agents: ✅ OpenTelemetry in New Relic: 👀
OpenTelemetry doesn't specify or collect metrics breaking down service response time.
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: ✅
This support means that in a distributed system where some services are instrumented with OpenTelemetry and others with APM agents, trace context can be propagated successfully from one service to the next. This gives you visibility into activity across the system even when you use more than one instrumentation technology.
New Relic agents: ❌ OpenTelemetry in New Relic: ✅
In OpenTelemetry, baggage is a mechanism to propagate key:value pairs. It allows for observability events in a called service to be indexed with attributes provided by a service making the request in the same transaction/trace, without having to pull the attributes from a database. For instance, a user ID added as baggage will be accessible to services where requests are sent, and those services can then also index their spans and metrics by the user ID.
The baggage specification is only focused on the propagation of data—not the presentation. If you've added data as baggage that you want to view in New Relic, you have to do something to it. For example, you can add the user ID from the example above to a span to view it as an attribute on that span in New Relic.
New Relic agents: ✅ OpenTelemetry in New Relic: ✅
APM agents support both head- and tail-based sampling, which you can implement by enabling standard tracing or Infinite Tracing, respectively.
OpenTelemetry SDKs by default implement parent-based sampling, though there are a number of built-in samplers that are available to choose from.
Additionally, OpenTelemetry offers a standalone service called a collector, a configurable telemetry-processing system. This means you can configure a custom sampling strategy (or strategies) that makes the most sense for your observability needs. However, configuring and operating collectors can be complex.
To use tail sampling and OpenTelemetry, you can use the tail sampling processor in the collector, or New Relic Infinite Tracing with OTLP.
New Relic agents: ❌ OpenTelemetry in New Relic: ✅
Here's a clarification on terminology: In New Relic documentation, span event in the context of APM agents refers to event data of type Span, which is how segments of distributed traces are stored in NRDB (our database). Span events as a distinct data type are not supported directly by APM agents.
In OpenTelemetry, “span events” are generally referred to as “events on spans.” An event on a span represents something that happens during the span's lifecycle and is displayed as a human-readable message. For example, exceptions that occur on a span will be displayed as a span event.
New Relic agents: ❌ (deprecated) OpenTelemetry in New Relic: n/a
Cross-application tracing (CAT) is a deprecated New Relic-specific precursor to New Relic distributed tracing and W3C trace context.
Transactions
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). Metric data can also power the transactions experience, but is only produced by some OpenTelemetry language agents. All New Relic agents produce transaction metrics, including additional metrics on aggregate performance of transaction segments.
In order for spans 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
With New Relic agents, if your service is a message consumer (for example, Kafka, RabbitMQ), you can find a breakdown of messaging operations in the Transactions page and see messaging operations in individual traces in Transaction Traces and Distributed tracing.
With OpenTelemetry instrumentation, you can see messaging operations in individual traces in Distributed tracing.
New Relic agents: ✅ OpenTelemetry in New Relic: ❌
In New Relic, transaction traces are meant to capture a small sample of slow and/or important requests, scoped to a single process (the app being monitored). You can see the transaction traces UI from the Transactions page.
OpenTelemetry traces, on the other hand, are scoped to all services that may be involved, although they are also designed to be captured for a sampling (up to 100%) of requests. Slow traces for your OpenTelemetry service are available on the Distributed tracing page.
New Relic agents: ✅ OpenTelemetry in New Relic: ❌
Similar to Transaction events, TransactionError events are sampled measures describing errors caught or reported while processing a request in a service.
An OpenTelemetry span with span.kind='server' or span.kind='consumer', and otel.status_code='ERROR' provides data similar to a TransactionError event.
New Relic agents: ✅ OpenTelemetry in New Relic: ❌
Databases
New Relic agents: ✅ OpenTelemetry in New Relic: 👀 Limited support
The Databases page shows an application's use of a database or cache. It shows individual database transactions/queries as a sortable table, and shows operations, throughput, and response time as charts.
The features of the Databases 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:
New Relic agent services use metrics, which are not subject to sampling effects
OpenTelemetry services use spans, which are subject to sampling
New Relic agents: ✅ OpenTelemetry in New Relic: 👀
OpenTelemetry captures some database query details in spans, but OpenTelemetry SDK instrumentation does not capture some slow database query details by default, such as SQL Explain Plans.
There is no feature in OpenTelemetry that is analogous to New Relic APM SQL Traces. The SQL Traces UI is where explain plans would be displayed if they were captured, so this feature is also not supported for OpenTelemetry.
New Relic agents: ✅ OpenTelemetry in New Relic: 👀
(See above)
New Relic agents: ✅ OpenTelemetry in New Relic: 👀
Currently, there is not a uniform way in OpenTelemetry to obfuscate sensitive information. Check each instrumented library you are using to see if there is a configuration option for query sanitization. The opentelemetry-collector could also be customized to obfuscate any telemetry data.
Externals
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.
Logs
New Relic agents: ✅ OpenTelemetry in New Relic: 👀
New Relic agents offer automatic log collection by default for services. OpenTelemetry can be configured to send logs from a variety of sources.
Service map
New Relic agents: ✅ OpenTelemetry in New Relic: ❌
The service map, accessible when looking at a single service in the UI, displays an entire set of entities connected to that service and is currently only supported by New Relic agents. The interconnected services must be actively reporting to appear in this map.
OpenTelemetry data does power the Related entities, Automap, and Trace map features.
Dependencies
New Relic agents: ✅ OpenTelemetry in New Relic: ❌
For OpenTelemetry, the Related entities or Automap views can take you to all the dependencies for a given service.
Errors
New Relic agents: ✅ OpenTelemetry in New Relic: ✅
For OpenTelemetry services in the Errors page, the error rate is based on 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).
New Relic agents: ✅ OpenTelemetry in New Relic: 👀
The Transactions page works with New Relic agent metrics, or with metrics for HTTP services reported by OpenTelemetry. OTel instrumentation, however, does not consistently or by default report transction/endpoint metrics.
All New Relic language agents report metrics (as well as spans and events) scoped to an individual transaction or endpoint.
Default OpenTelemetry SDK instrumentation does not consistently report such metrics. The semantic conventions for endpoint-level data, for example http.route, are still considered experimental.
New Relic agents: ✅ OpenTelemetry in New Relic: 👀
The New Relic agent measures the aggregate performance of spans within a request and reports them as metrics. We call these spans “segments” in the context of a transaction trace and record their “exclusive time” within the transaction, as well as the time spent in child spans/segments.
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.
Explorer
New Relic agents: ✅ OpenTelemetry in New Relic: 🟡 Limited support
Services instrumented with New Relic and services instrumented with OpenTelemetry appear in different sections of the APM & services and All entities pages today.
OpenTelemetry services use spans to create golden signals, whereas New Relic agent services use metrics.
Lookout
New Relic agents: ✅ OpenTelemetry in New Relic: ✅
OpenTelemetry services use spans to create golden signals, whereas New Relic agent services use metrics.
Navigator
New Relic agents: ✅ OpenTelemetry in New Relic: ✅
OpenTelemetry services use spans to create golden signals, whereas New Relic agent services use metrics.
Apdex
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
New Relic agents: ✅ OpenTelemetry in New Relic: ✅
New Relic agents: ✅ OpenTelemetry in New Relic: ❌/👀
Not all OpenTelemetry language SDKs/agents specify or report process.runtime.* metrics yet.
New Relic agents: ✅ OpenTelemetry in New Relic: 👀
Browsers page
New Relic agents: ✅ OpenTelemetry in New Relic: 👀
The New Relic APM agent can automatically inject a JavaScript agent into rendered content, so that the front-end JS assets are instrumented.
In OpenTelemetry, there is no equivalent to the New Relic browser agent or the browser instrumentation available with New Relic APM agents. If you are using the OpenTelemetry-JavaScript SDK, there are some auto-instrumentation libraries available today to generate and collect browser data from end users. For languages that can be used to write iOS and Android applications (Java and Swift) and browser applications (JavaScript), there is a specification to instrument client-side telemetry, but is not yet available.
Currently, New Relic does not support JSON-encoded payloads over HTTP (yet), so you need to stand up a collector to send browser data to New Relic. This is because OpenTelemetry-JS used in the browser does not support protobuf payloads over OTLP/HTTP—only json payloads. The collector can process the data back into a format that New Relic can ingest.
New Relic agents: ✅ OpenTelemetry in New Relic: 👀
New Relic agents: ✅ OpenTelemetry in New Relic: 👀
New Relic agents: ✅ OpenTelemetry in New Relic: 👀
New Relic agents: ✅ OpenTelemetry in New Relic: 👀
New Relic agents: ✅ OpenTelemetry in New Relic: 👀
New Relic agents: ✅ OpenTelemetry in New Relic: 👀
New Relic agents: ✅ OpenTelemetry in New Relic: 👀
New Relic agents: ✅ OpenTelemetry in New Relic: 👀
Mobile
New Relic agents: ✅ OpenTelemetry in New Relic: ✅
OpenTelemetry provides support for Java and Swift, which are two of the main languages for mobile app development:
The Java instrumentation that you would use for Android can be found in the OpenTelemetry Java repo
The Swift instrumentation currently contains implementations for tracing, metrics, and baggage APIs and SDK
Not all of the telemetry that the New Relic Mobile SDK collects can yet be collected by OpenTelemetry instrumentation, however.
New Relic agents: ✅ OpenTelemetry in New Relic: 👀
New Relic agents: ✅ OpenTelemetry in New Relic: 👀
New Relic agents: ✅ OpenTelemetry in New Relic: 👀
New Relic agents: ✅ OpenTelemetry in New Relic: 👀
New Relic agents: ✅ OpenTelemetry in New Relic: 👀
New Relic agents: ✅ OpenTelemetry in New Relic: 👀
New Relic agents: ✅ OpenTelemetry in New Relic: 👀
New Relic agents: ✅ OpenTelemetry in New Relic: 👀
New Relic agents: ✅ OpenTelemetry in New Relic: 👀
New Relic agents: ✅ OpenTelemetry in New Relic: 👀
New Relic agents: ✅ OpenTelemetry in New Relic: 👀
New Relic agents: ✅ OpenTelemetry in New Relic: 👀
New Relic agents: ✅ OpenTelemetry in New Relic: 👀
New Relic agents: ✅ OpenTelemetry in New Relic: 👀
New Relic agents: ✅ OpenTelemetry in New Relic: 👀
New Relic agents: ✅ OpenTelemetry in New Relic: 👀
Related entities
New Relic agents: ✅ OpenTelemetry in New Relic: 🟡 Limited support
This view shows, for APM and/or OpenTelemetry services or hosts:
Relationships between services
Relationships between services and infrastructure
Relationships between services and uninstrumented external 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 between services and databases are only generated for APM services at this time.
New Relic agents: ✅ OpenTelemetry in New Relic: ✅
This map displays the connected neighbors for a given service, and includes a Timewarp cursor to see changes in the health status for the displayed entities. The automap option will appear as a Map view button in any Related entities pane for both APM and OpenTelemetry services, as well as other supported entity types.
Environment
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.
Deployments
New Relic agents: ✅ OpenTelemetry in New Relic: 👀 Limited support
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 only for New Relic APM agent entities.
Faster time-to-glass
New Relic agents: ✅ OpenTelemetry in New Relic: ✅
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.
Reports
New Relic agents: ✅ OpenTelemetry in New Relic: ❌
New Relic agents: ✅ OpenTelemetry in New Relic: ❌
New Relic agents: ✅ OpenTelemetry in New Relic: ❌
New Relic agents: ✅ OpenTelemetry in New Relic: ❌
New Relic agents: ✅ OpenTelemetry in New Relic: ❌
New Relic agents: ✅ OpenTelemetry in New Relic: ❌
Infrastructure
New Relic agents: ✅ OpenTelemetry in New Relic: ✅
Host entities with golden metrics are available independent of the data source: New Relic infrastructure agent vs. OpenTelemetry collector host receiver.
New Relic agents: ✅ OpenTelemetry in New Relic: 👀
The infrastructure inventory capability has no equivalent in OpenTelemetry, which is based on metrics, traces and logs.
New Relic agents: ✅ OpenTelemetry in New Relic: 👀
Most infrastructure events depend on inventory or custom events pushed by the New Relic infrastructure agent.
New Relic agents: ✅ OpenTelemetry in New Relic: 👀
On-host integrations (NGINX, MySQL, Redis, Apache, RabbitMQ, and many more) and the Kubernetes integrations are required as a source for curated dashboards and entities in New Relic.
New Relic agents: ✅ OpenTelemetry in New Relic: 🟡 Limited support
New Relic agent data for services shows up in the Kubernetes cluster explorer, but OpenTelemetry services data does not.
The Kubernetes page does work for either New Relic APM agent or OpenTelemetry-instrumented services.
We recommend that for any OpenTelemetry service using Kubernetes you should decorate your telemetry with the relevant resource attributes from the OpenTelemetry semantic conventions so you can query for this data.
Serverless
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.
Alerts
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 agents: ✅ OpenTelemetry in New Relic: ❌
New Relic agents: ✅ OpenTelemetry in New Relic: ✅
New Relic agents: ✅ OpenTelemetry in New Relic: ❌
New Relic platform
New Relic agents: ✅ OpenTelemetry in New Relic: ✅
For OpenTelemetry services, just ensure that the service.name attribute is present in logs to associate them with a service entity.
New Relic agents: ✅ OpenTelemetry in New Relic: ❌
New Relic agents: ✅ OpenTelemetry in New Relic: ✅
OpenTelemetry service entities do not have a dedicated Service Levels UI, but SLIs (service level indicators) can be viewed for them in a workload or in the mini-overview.
For OpenTelemetry, you can start with our setup instructions, which guides to various sites to complete the installation.
New Relic agents: 🟡 Limited support OpenTelemetry in New Relic: ❌
New Relic agent transaction events are functionally similar to OpenTelemetry exemplars. They capture a detailed sample of one service's request and can be linked to metrics using the name of the request endpoint/transaction.
New Relic agents: ✅ OpenTelemetry in New Relic: 👀
New Relic is developing a limited preview of a feature that maps event telemetry data to New Relic events.
New Relic agents: ✅ OpenTelemetry in New Relic: ✅
Entities coming both from New Relic agent and OpenTelemetry data can be added to a workload. The golden metrics for each entity depend on the entity type.
Configuration options
New Relic agents: ✅ OpenTelemetry in New Relic: 👀
Several configuration options, including server-side configuration, are available via the New Relic UI for APM services.
Configuration for OpenTelemetry services is handled directly in the SDK and/or the collector (if implemented).
New Relic agents: ✅ OpenTelemetry in New Relic: ✅
New Relic agents can tag their entities via configuration files (see our tagging documentation).
All entities can be tagged via the UI and API
New Relic agents: ✅ OpenTelemetry in New Relic: ❌
The restrictions on data enforced by New Relic agents' high security mode feature could be enforced by configuring or modifying the OpenTelemetry collector, but New Relic could not enforce them because OTLP does not specify such controls.
New Relic agents: 🟡 Java only OpenTelemetry in New Relic: 👀
Only the New Relic Java agent supports creating, applying, and exporting custom instrumentation via the UI.
New Relic agents: 🟡 Limited release for .NET OpenTelemetry in New Relic: 👀
Only the New Relic .NET agent supports a live custom instrumentation update via the UI, without agent restart. This feature is in limited release.