OpenTelemetry is a toolkit to gather telemetry from applications, infrastructure (e.g. hosts, k8s, etc), and more. By configuring OpenTelemetry data sources to export to New Relic, you can leverage a wide range of platform capabilities to analyze the data and diagnose problems.
This page provides an overview of OpenTelemetry and New Relic. For working code examples demonstrating common integration patterns including APM and infrastructure monitoring, see get started with OpenTelemetry with New Relic. For information on how New Relic receives, processes, and ingests OpenTelemetry data, see OpenTelemetry data in New Relic, and in particular details on New Relic's OTLP endpoint.
Benefits of OpenTelemetry
OpenTelemetry is a vendor-neutral open standard for instrumenting and exporting telemetry data. The project scope is quite extensive, including:
- A specification of language agnostic APIs for instrumenting the core pillars of observability (traces, metrics, logs), and SDKs for configuring how telemetry is exported out of process, with implementations exist in 11+ languages. There is a substantial catalog of instrumentation available built on top of these APIs.
- OTLP, a general-purpose telemetry data delivery protocol.
- Semantic conventions describing the shape of telemetry data for common domains (i.e. HTTP servers, messaging systems, and many more).
- The collector, a highly configurable and extensible data collection and processing pipeline used to monitor infrastructure and enrich, filter, and otherwise transform telemetry.
These components work together to create distinct advantages:
Feature | Description |
|---|---|
Language Agnostic | OpenTelemetry reduces the cognitive load of polyglot teams by providing one vocabulary and one toolkit. |
Open standard | As an open standard with an open governance structure, no single vendor controls the direction of OpenTelemetry. |
Full control of observability data | The highly configurable and extensible nature of language SDKs and the collector offer unparalleled control over your telemetry data pipeline. |
Rich instrumentation ecosystem | One of the goals of OpenTelemetry is for the APIs to ultimately be used directly in upstream libraries and frameworks. To bridge the gap, OpenTelemetry provides a large catalog of instrumentation contributed from engineers all over the world. There is more collective instrumentation effort in OpenTelemetry than any one vendor can provide on their own. |
Future proof | While OpenTelemetry has already come a long way, it seems poised to grow in adoption thanks to its large active community, industry support, and open governance model. While we can't see the future, OpenTelemetry is the most likely open source winner in the observability industry. |
OpenTelemetry or New Relic instrumentation?
In many cases, there is overlap between features and components available from OpenTelemetry and from New Relic. For example, OpenTelemetry APM monitoring mirrors New Relic APM agents, and infrastructure monitoring with the OpenTelemetry collector mirrors the capabilities of the New Relic infrastructure agent.
We recommend that you explore both New Relic and OpenTelemetry options. With New Relic instrumentation, there are inherent advantages to developing instrumentation and platform features which work together, and New Relic integrations tend to work better out of the box. On the other side, OpenTelemetry offers an unparalleled degree of flexibility and control, but this sometimes requires additional research and effort to achieve the desired outcome.
OpenTelemetry is continually evolving
The OpenTelemetry project has a large scope which has grown over the years. While many core components have reached stability (including OTLP, the trace API / SDK, the metric API / SDK, the log bridge API / SDK, http semantic conventions, and many language implementations), there are naturally pieces which are at various other stages of maturity.
New Relic aims to have first class support for OpenTelemetry, including ingesting all OTLP data into our general purpose observability platform and building user experiences on top of OpenTelemetry data to help drive insights from the data out of the box. As components emerge and develop our platform capabilities will evolve alongside. However, please be cognizant of the maturity status of any OpenTelemetry components you are integrating with. While we try to stay on top of changes, it can be challenging to build around breaking changes of experimental components.
OpenTelemetry reference architecture
With such a wide variety of components and configuration options, it can be difficult to know where to start with OpenTelemetry.
The diagram below illustrates a reference architecture: a high level view of how a variety of OpenTelemetry components work together and integrate with New Relic. Software developers, DevOps, architects, and managers can use it to align on concepts. It shows apps instrumented with a variety of tools - New Relic APM agents, OpenTelemetry APM instrumentation, Jaeger, and Prometheus - exporting data to New Relic, and optionally through an intermediate OpenTelemetry collector. The OpenTelemetry collector understands a wide variety of protocols, and can process, filter, and enrich telemetry data before exporting on to one or more destinations. For working code examples demonstrating these integrations, see get started with OpenTelemetry and New Relic.
For additional reading, familiarize yourself with the OpenTelemetry demo, a project maintained by the OpenTelemetry community which illustrates various OpenTelemetry concepts through a fictitious ecommerce system driven by a series of microservices.