• /
  • Log in
  • Free account

Introduction to OpenTelemetry with New Relic

You can send OpenTelemetry data to New Relic and analyze the results in our observability platform. This introduction can help you decide if you want to get started with OpenTelemetry. If you're already familiar with OpenTelemetry and want to jump into the setup, go to our OpenTelemetry quick start.

If you're just getting acquainted with OpenTelemetry, this is what we'll explore here:

Benefits of OpenTelemetry

OpenTelemetry provides a secure, vendor-neutral specification for service instrumentation so that you can send data to distinct backends of your choice, such as New Relic. OpenTelemetry offers a single set of APIs and libraries that standardize how you collect and transfer telemetry data for your services.

The following components make up the OpenTelemetry project:

  • Specifications for the core pillars of observability to drive consistency across all projects (initially, traces and metrics are supported, followed by logs)
  • APIs that contain interfaces and implementations based on the specifications SDKs (reference implementations of the APIs) created specifically for languages like Java, Python, Go, Erlang, and more
  • Collectors that offer a vendor-agnostic implementation for processing and exporting
  • Exporters that enable you to send data to a backend of your choice

The components of OpenTelemetry work together to create some distinct advantages for capturing telemetry data:



Ubiquitous instrumentation

A single, open standard of instrumentation provides better coverage and flexibility as engineers from all over the world contribute to the instrumentation.

Future proof

As the instrumentation gets built into libraries and frameworks, and as more vendors move to support this open standard, you can be confident that you won’t need to change your instrumentation.

Support for newer technologies

When new technologies emerge, contributors can build integrations into OpenTelemetry or add instrumentation directly to source code, ensuring end users can easily monitor these new technologies.

Simplified choice

You don’t need to decide which instrumentation option to use (a proprietary option or one of the other open standards).

Cross-platform compatibility

OpenTelemetry supports a variety of languages and backends. It represents a vendor-neutral path for capturing and transmitting telemetry to backends without altering existing instrumentation.

Streamlined observability

It is easier for vendors to support and test against a single standard as they don’t need to develop their own agents or collectors.

High dimensionality

OpenTelemetry uses dimensional metrics, so you can filter and facet on more aspects of the data, such as AWS regions, Kubernetes clusters, or service versions. Dimensional metrics also lead to less time between occurrence and reporting.


OpenTelemetry’s fire-and-forget trace-centric approach to instrumentation often has lower overhead than New Relic agents, especially for asynchronous workloads. It will also result in better handling of trace data for asynchronous requests.


For more, see our blog posts on OpenTelemetry.

Should I use OpenTelemetry instrumentation or New Relic agents?

As you consider OpenTelemetry, you may also be looking at New Relic APM agents that also capture telemetry data.

As you'd expect, there is a lot of overlap between features available from OpenTelemetry agents and SDKs versus those available from New Relic APM agents. This is especially true if you're interested in distributed tracing telemetry data. The choice you make depends on what you need.

We recommend that you explore both New Relic and OpenTelemetry instrumentation or discuss it directly with us at New Relic to decide what works best for you.

OpenTelemetry: A work in progress

OpenTelemetry is still an emerging standard, so your choices may be affected by what's available. You can check on the current state of the specification at the OpenTelemetry site.

The current state of language-specific OpenTelemetry APIs and SDKs varies: some languages are still pre-alpha and may be missing instructions on how to instrument your service. Most languages have some implementation of traces that is sufficient to start sending data to New Relic. Check out this table in GitHub that provides an overview of the state of OpenTelemetry specification compliance for each language.

For languages that New Relic does not currently provide an agent or SDK, OpenTelemetry may offer you a good alternative. Also, in cases where you want explicit control over sampling of your telemetry data, OpenTelemetry provides a lot of flexibility.

As OpenTelemetry matures, New Relic will continue to support new OpenTelemetry data models and to provide a curated UI experience for our Full Stack Observability customers.

New Relic APM agents

In general, New Relic APM agents will collect more telemetry data for your services, and they offer a wide range configuration options and an extensive set of auto-instrumentation capabilities.

APM agents offer detailed transaction trace visibility for individual services. They also offer predefined sampling to balance the performance impact of your instrumentation against the need to capture enough data to gain helpful insights.

How OpenTelemetry works with New Relic

Here are two basic ways you could set up OpenTelemetry with New Relic: use the OpenTelemetry collector (recommended), or use the native OTLP endpoint (pre-release). Each approach assumes you set up instrumentation in your code, but they differ in how the data is gathered and sent to New Relic.

If you are interested in tracing, we recommend that you instrument as many services as you can so that you get the most benefit from distributed tracing. There are two main options for trace sampling:

  • Configure the head-based, native sampling in OpenTelemetry, which means OpenTelemetry samples traces before they are sent to New Relic. Head-based sampling doesn’t analyze all traces, but instead randomly samples traces up front before details about the completed traces are known. Both the OpenTelemetry collector and the native OTLP endpoint support this option.
  • If you want New Relic to analyze all your traces, configure tail-based sampling with New Relic Infinite Tracing, which reroutes traces to our cloud-based trace observer. The trace observer accepts all your traces and sorts through them to find useful ones. If you want to know more about this option, especially if you want to use it in the EU, see Introduction to Infinite Tracing. While Infinite Tracing is not yet compatible with the native OTLP endpoint, it is still possible to configure tail-based sampling via the collector, for more information see Tail Sampling Processor.


We discuss some variations on these basic approaches in our OpenTelemetry architecture recipes. For a detailed discussion about the architecture of OpenTelemetry itself, see our blog.


New Relic's language-specific exporters for OpenTelemetry are now deprecated in favor of the OpenTelemetry collector and native OTLP endpoint options described here.

Collector (recommended)

The OpenTelemetry project provides a tool called the OpenTelemetry Collector that you can deploy and use as an intermediate data aggregator. In your service, you use the OpenTelemetry exporter to send telemetry data first to the OpenTelemetry collector. Then, in the OpenTelemetry collector, you enable the New Relic exporter to send data to New Relic.

In this workflow, note the alternate path if you set up New Relic Infinite Tracing:

Diagram showing OpenTelemetry with collector.

Here are some advantages of this approach:

  • The OpenTelemetry collector can perform processing operations on telemetry data before it is sent to the backend, including filtering attributes, excluding traces, and sampling.
  • The OpenTelemetry collector can receive telemetry data in many formats and forward it on to New Relic’s backend, including Prometheus, Zipkin, Jaeger, AWS X-Ray, OpenCensus, and much more.
  • The OpenTelemetry collector can collect system-level metrics from the host where it is running.

OTLP (pre-release)

The example above uses a New Relic exporter, but we have a pre-release program if you want to try out the native OTLP endpoint for sending your data to New Relic. You can either use the OTLP exporter in the OpenTelemetry collector, or send us data directly from your service. If you are interested, let us know by completing this form.

Here are some advantages to operating without an OpenTelemetry collector:

  • There is no need to deploy a collector alongside your service.
  • Telemetry data is sent directly from the instrumented service to New Relic. If something goes wrong, and telemetry data does not arrive, there is one less component to debug.

What's next?

If you want to set up OpenTelemetry with New Relic, the next step is to check out our OpenTelemetry quick start.

If you prefer to use a New Relic APM agent, go to Introduction to APM.

For more help

If you need more help, check out these support and learning resources:

Create issueEdit page
Copyright © 2021 New Relic Inc.