What is OpenTelemetry?

OpenTelemetry (OTel) is an observability framework and toolkit for users to create, process, and export telemetry such as traces, metrics, and logs. Its main purpose is to provide a singular standard for code instrumentation and telemetry data transport to an observability tool backend.

As a Cloud Native Computing Foundation (CNCF) project, OpenTelemetry is vendor- and tool-agnostic. Developers can use it with a variety of observability backends, including open source tools such as Jaeger and Prometheus in addition to observability vendors. However, it is not a storage backend or a frontend UI for query visualization and querying.

The OpenTelemetry Collector helps developers monitor microservice application health, capture requests between microservices, trace resource use to specific user groups, create tiered requests for priority resources, and process and transform telemetry before exporting.

To understand OpenTelemetry more fully, let’s take a look at its components, benefits, and tradeoffs.

OpenTelemetry gives organizations control over the telemetry pipeline by processing telemetry before it is sent onto an observability vendor. Open source instrumentation libraries for popular languages and frameworks also mean freedom from vendor lock-in when migrating between platforms.

Before OpenTelemetry, each observability vendor had its own libraries. This made it tough for companies that relied on multiple vendors to collect and export data types, as they couldn’t easily jump between different libraries or various telemetry types.

This meant telemetry was often completely siloed, and businesses would get their competitive advantage on which products they chose for telemetry collection. It also affected how well you could import and work with data depending on the vendor’s library and feature set.

OpenTelemetry removes the need to have multiple instrumentation libraries and streamlines data collection across your observability backend. This makes it easier to get and share telemetry data. Engineers not only get data faster, they only need to maintain one telemetry collector – one that’s based on open source coding – instead of proprietary, vendor-specific code.

Like the old Java tagline “write once, run anywhere,” OpenTelemetry allows you to “instrument once and export anywhere.”

As a toolkit and a framework, OpenTelemetry includes:

• The OpenTelemetry Collector to receive, process and export telemetry data (metrics and traces).
• Specification for all included components.
• OpenTelemetry Protocol that outlines telemetry data shapes.
• Semantic conventions that provide a standardized naming convention for telemetry data types.
• APIs to define telemetry data generation.
• A library ecosystem that implements instrumentation for common libraries and frameworks.
• Automatic instrumentation that helps generate telemetry data without code changes.
• Language SDKs to implement the developer’s desired specification, APIs, and data export.

All of these components come together to provide a robust foundation for data collection and porting into observability software.

OpenTelemetry brings three main benefits to organizations: A large open source community, increased interoperability, and backend tool flexibility.

Large open source community: A wide variety of users and contributors means that development teams can use OTel in house and can get support through online research and user communities, instead of solely relying on vendor support or wrangling with customer service.

Compatibility across different tools and services: Vendor- and ecosystem-agnostic telemetry collections reduces the required number of tools and lets developers monitor their ecosystem of third-party services without setting up complex integrations that require additional monitoring and operation.

Flexibility to change backend observability tools: Because OpenTelemetry is open source, it gives developers the flexibility to add a telemetry collector without investment in proprietary software or having to set up specific infrastructure for it to run (which adds a point of failure and consumes resources). It also provides a way for organizations to avoid vendor lock-in and make future migrations more efficient.

While OpenTelemetry brings a lot of benefits to observability telemetry collection, there are still things organizations should know during the evaluation process.

OpenTelemetry is much more useful for understanding a system’s inner workings and for backend developers; support for frontend, client and browser data is still pretty experimental and in the early stages.

Some languages are more supported than others, so it’s necessary to see what kind of compatibility developers need before deciding to go all in with OpenTelemetry adoption. The specification is stable and complete, but the language SDK implementation is still a work in progress depending on the specific language.

Generally, OpenTelemetry is not a direct replacement for Prometheus. While both tools work with open source telemetry collection, they offer different feature sets. It’s not a direct, feature-to-feature comparison.

Either project can ingest each other’s data, and so they often coexist within environments.

OpenTelemetry is still a fairly new project, but developers are already seeing its impact within the observability space in terms of adoption acceleration. In 451 Research’s “Voice of the Enterprise (VotE): DevOps, Organizational Dynamics” 2021 data survey, responding organizations have already adopted (47%) or are in the discovery stages (21%) of adopting observability.

Going forward, OpenTelemetry’s standardized processes and frameworks should provide greater flexibility to change backend tools as organizations streamline observability, which boosts the project’s progress and helps teams avoid vendor lock-in.

Using OpenTelemetry as a de facto standard allows organizations to spend less time instrumenting for data collection and more time leveraging the data when they believe it is mature without adding application performance overhead.

As a cloud native, open source platform, Chronosphere provides both community support and product support for OpenTelemetry. Within our product, Chronosphere ingests OpenTelemetry metrics without a server-side component and is currently integrating the same support for traces. Recent contributions to the OpenTelemetry project include a Jaeger Remote Sampling extension and several bug fixes.