• Log in

Introduction to OpenTelemetry with New Relic

OpenTelemetry is a toolkit you can use to gather telemetry data from your applications and hosts and then export that data to New Relic. Once the data is in New Relic, you can use the New Relic platform to analyze the data and resolve application issues.

OpenTelemetry has features that overlap with New Relic agents, so review the information below to see if it will help you accomplish your telemetry goals. If you're already familiar with OpenTelemetry and want to get started, see our setup instructions.

Here are some topics to help you get acquainted with OpenTelemetry:

Benefits of OpenTelemetry

OpenTelemetry provides a secure, vendor-neutral specification for service and host instrumentation so that you can export data to distinct back-ends 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 and hosts.

The following components make up the OpenTelemetry project:

  • Specifications for the core pillars of observability to drive consistency across all projects. New Relic supports all of these signals: traces, metrics, and logs (see details below)
  • 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:

Feature

Description

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.

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 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. The information in this section has some broad concepts for you to consider, and if you want to look more closely at the differences, see our detailed comparsion. Also, you are welcome to discuss this in our CNCF Slack channel, #otel-newrelic to decide what works best for you. You may have to first sign up for CNCF's Slack account here.

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 exporting 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 where 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, we will continue to support new OpenTelemetry data models and provide you curated UI experiences in our platform.

New Relic agents

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

New Relic's 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.

Important

Running New Relic agents and OpenTelemetry tooling in the same process

New Relic agents and OpenTelemetry tooling (SDKs, agents, etc.) are among many APM products on the market.

For a given language, nearly all APM products operate by using the same low-level language and runtime hooks available–most of which alter the behavior of your code at run time. Depending on your language's architecture, this is often achieved via techniques like byte-code manipulation or monkey patching.

Due to the complex ways in which APM products alter your running code, there can be no guarantees that one product will be compatible with another product running in the same process. At best, they’ll live side by side unbeknownst to the other and independently generate telemetry from your application. At worst, they’ll stomp on each other leading to unpredictable behavior.

New Relic cannot make any assurances that our APM agents are compatible with a different APM product running in the same process. We recommend you pick the one–and only one–that best fits your needs.

How OpenTelemetry works with New Relic

New Relic supports the native OpenTelemetry Protocol (OTLP) for exporting telemetry data. This allows you to use the vendor neutral components developed by the OpenTelemetry community to export your data to New Relic.

The tables in the sections below show the supported features for each telemetry signal. If you have any questions about details in the sections below or unsupported use cases, please contact us in our CNCF Slack channel, and watch this page for future updates. If you prefer to get the big picture of an implementation with New Relic, see our reference architecture.

Important

New Relic's exporters for OpenTelemetry are now deprecated in favor of exporting data to New Relic using OTLP.

Traces

New Relic offers support for the OTLP ingest of trace signals. The maturity of the upstream specification is stable.

OpenTelemetry traces and spans are compatible with New Relic traces and spans. OpenTelemetry spans optionally include attributes (name-value pairs) and resource attributes which map directly to dimensions that can be used to facet or filter span data at query time. OpenTelemetry span metadata (for example, name, kind, and trace_id) also map directly to dimensions on New Relic spans. At this time, New Relic does not support span links.

For details, see the Traces section of our best practices guide.

Feature

Supported

Span events

Span linking

Array of primitives (homogeneous)

✅ (Must be non-nested and 64 or less elements)

Metrics

New Relic offers support for the OTLP ingest of metric signals. Note that the maturity of the upstream specification is experimental. We intend to follow potentially breaking upstream changes.

Here are the OpenTelemetry data types we support and their associated mappings. For details, see the Metrics section of our best practices guide.

Metric Type

Supported

Delta sums

Cumulative sums

Gauges

Delta histograms

Summary

Cumulative histograms

Exemplars

Array of primitives (homogeneous)

✅ (Must be non-nested and 64 or less elements)

Logs

New Relic offers support for the OTLP ingest of log signals. Note that the maturity of the upstream specification is experimental. We intend to follow potentially breaking upstream changes.

OpenTelemetry logs are compatible with logs in New Relic. The OpenTelemetry logs optionally include attributes (name-value pairs) and resource attributes that map directly to dimensions you can use to facet or filter log data with queries. OpenTelemetry log metadata (for example, name, severity_text, and trace_id) also map directly to dimensions on New Relic's log management capabilities. We currently support all OpenTelemetry log message types.

For more details, see the logs information in our best practices guide.

Feature

Supported

Description

LogRecord body

Supported types: string, boolean, int, double, bytes

LogRecord attributes

Supported types: string, boolean, int, double, bytes

LogRecord fields

Examples: name, severity_text, trace_id

Array messages (homogeneous)

✅ (Must be non-nested and 64 or less elements)

Array of primitives (homogeneous)

✅ (Must be non-nested and 64 or less elements)

Next steps

Follow the OpenTelemetry quick start to help you get started.

You'll also want to review the best practices guide for getting the most out of the data you export to New Relic.

Copyright © 2022 New Relic Inc.

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