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
- Should I use OpenTelemetry or New Relic agents?
- How OpenTelemetry works with New Relic
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.|
|Efficiency||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. Each approach assumes you set up instrumentation in your code, but they differ in how the data is gathered and sent to New Relic.
For each approach, you can optionally set up New Relic Infinite Tracing so that our trace observer can analyze all your traces. To see if this is a good fit, see Introduction to Infinite Tracing.
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:
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.
The OpenTelemetry collector is easy to deploy and maintain in most environments. But, if you prefer to send your telemetry data directly from your service to New Relic, we provide some language-specific exporters.
Your OpenTelemetry automatic or manual instrumentation can pass data from your service to an exporter, which sends data directly to New Relic. You can see in the following diagram how data can reach New Relic without a collector. Note the alternative path if you set up New Relic Infinite Tracing:
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.
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.