Are you already familiar with OpenTelemetry and want to begin the setup? Check out our quick start:
If you don't have one already, create a New Relic account. It's free, forever.
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
OpenTelemetry provides a secure, vendor-neutral specification for service instrumentation so that you can export 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. 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:
A single, open standard of instrumentation provides better coverage and flexibility as engineers from all over the world contribute to the instrumentation.
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.
You don’t need to decide which instrumentation option to use (a proprietary option or one of the other open standards).
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.
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.
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.
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 this with us in our CNCF Slack channel to decide what works best for you.
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 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 customers.
In general, New Relic's APM agents will collect more telemetry data for your services, and 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.
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 following tables show the supported features for each telemetry signal. If you have questions about these or have an unsupported use case, please contact us in our CNCF Slack channel, and watch this page for future updates.
New Relic's exporters for OpenTelemetry are now deprecated in favor of exporting data to New Relic using OTLP.
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,
trace_id) also map directly to dimensions on NewRelic spans. At this time, New Relic does not support span links or array attributes.
For details, see the Traces section of our best practices guide.
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.
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 New Relic logs. OpenTelemetry logs optionally include attributes (name-value pairs) and resource attributes which map directly to dimensions that can be used to facet or filter log data at query time. OpenTelemetry log metadata (for example,
trace_id) also map directly to dimensions on New Relic logs. NewRelic currently supports all OpenTelemetry log message types except for arrays.
For more details, see the Logs section of our best practices guide.
Supported types: string, boolean, int, double, bytes
Supported types: string, boolean, int, double, bytes
Examples: name, severity_text, trace_id
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.