New Relic : Adopting observability with OpenTelemetry

Outlook for OpenTelemetry

According to a OpenTelemetry Metrics Roadmap blog post in March 2021, Metrics API/SDK specifications were planned to achieve stable status by November 30, 2021. At present, metrics is marked as mixed status, which is an indication that the majority of the specification has stabilized. The notable exceptions are exemplars and exponential histograms, which may still undergo changes that could cause backward-compatibility issues.

There is no specific roadmap available from the OpenTelemetry project at this time. However, considering where the most activity is happening, metrics compatibility across various languages are expected to move to stable status soon, and as the final data signal, logs will follow. It is difficult to predict how soon these statuses could change and is dependent on the individual SIGs implementing the specifications. In parallel, the limited auto-instrumentation capabilities are also continuing to mature across the Java and .NET ecosystems.

After the work to implement metrics, adding support for logging should not be much of a heavy lift. Logs specifications are comparatively well defined. The logging data model recently became stable, and some reference implementations, referred to as experimental, have been available for some language clients for months. I would expect the logs SDK, and the protocol to reach stable status sometime in the second half of the year, assuming no delays in Cloud Native Computing Foundation (CNCF) project resourcing.

OpenTelemetry adoption considerations

In addition to achieving stable status for metrics and logs, simplifying OpenTelemetry deployment may become one of the project's focus areas. Today, the learning curve is long for adopting OpenTelemetry at scale because of many unknowns for implementation and support. In the next sections, I'll go through some considerations to help with adoption.

To set up OpenTelemetry for success, you can start by reviewing some of the limitations.

Understand OpenTelemetry limitations

It's important to be aware of what you can achieve with the OpenTelemetry implementation, and where there are limitations. Here are some tips to consider:

• Understanding OpenTelemetry feature support will help with the instrumentation planning. Let's say you're planning to instrument a Python application for enabling distributed tracing, metrics, and logs. After reviewing the current state, you might conclude that most of the distributed tracing specs are supported and stable. Meanwhile, metrics and logs have limited capability and are in experimental and draft status. Going through the supported specs will help you make the right instrumentation decisions.

• Organization fit is not just about the technology. The success of any serious OpenTelemetry adoption at scale will need mindshare across functional teams. You need to evaluate where your observability strategy OpenTelemetry fits. You also need to identify all functional groups critical for the project's success. Your roll-out plan must be supported by enablement of the OpenTelemetry concepts and implementation standards you set for your organization.

• OpenTelemetry isn't an observability platform. Don't confuse OpenTelemerty with an observability platform such as New Relic. OpenTelemetry provides instrumentation standards for generating the signals such as traces, metrics, and logs but it's not an observability solution by itself. It doesn't include visualizations, alerts, queries, or storage capabilities. Simply put, OpenTelemetry is all "what" and no "why"! To provide business value to your organization, you need to send the raw data to an observability platform to be analyzed.

OpenTelemetry instrumentation methodology

There are mainly two ways to instrument applications in OpenTelemetry: automatic and manual instrumentation.

Before we compare the two, let's look at various types of instrumentation libraries available in OpenTelemetry:

• Core: This repository contains all language instrumentation libraries, such as opentelemetry-java. This repository contains the implementation of the API and SDK for Java, which can be used for or all manual instrumentation activities.
• Instrumentation: This repository has automatic instrumentation capabilities on top of what you get with the Core repository. An example is openeletemetry-java-instrumentation.
• Contrib: This repository covers any additional helpful libraries and standalone OpenTelemetry-based utilities that don't fit in the scope of the Core and Instrumentation repositories. Java Contrib is an example that contains libraries for generating signals for AWS X-Ray and JMX Metrics.
  Note: Not every language will follow the Core, Instrumentation, and Contrib structure for instrumentation libraries. Certain languages such as Ruby offer a single repository for all instrumentation libraries.
• Distribution: This repository is built on top of OpenTelemetry repositories with some customizations. Distribution adds customizations for vendor-specific configurations (pure), additional (plus), or less (minus) capabilities beyond what's available in OpenTelemetry. Vendor support includes a list of distributions from various products.

This table describes the differences between manual and auto instrumentation methods. As of the current state of OpenTelemetry, you may have to rely on manual instrumentation for rich telemetry until auto instrumentation capabilities mature.