What is OpenTelemetry?
OpenTelemetry (often abbreviated as Otel) is an open-source observability framework that helps with tracing, monitoring, and collecting telemetry data from distributed applications.
Here are important points about OpenTelemetry:
APIs and Libraries: OpenTelemetry provides a set of APIs and libraries that developers can use to instrument their applications and capture observability data, including distributed traces, metrics, and logs.
Language and Framework Agnostic: OpenTelemetry is designed to be language- and framework-agnostic, which means it can be used with a variety of programming languages, such as Java, Go, Python, C++, and others, making it flexible and adaptable to different application stacks.
Standardization: OpenTelemetry aims to standardize the way observability data is collected and transmitted across distributed systems, making it easier for developers to understand the behavior of complex applications and troubleshoot issues efficiently.
Distributed Tracing: OpenTelemetry provides a consistent approach to capture distributed traces, which are records of the activities and interactions between different components of an application. This helps in understanding the flow of requests and identifying bottlenecks or issues in distributed systems.
Metrics and Logs: In addition to distributed traces, OpenTelemetry also supports capturing metrics, which are quantitative measurements of system behavior, and logs, which are records of events and messages emitted by an application. This comprehensive data collection enables holistic observability of applications.
Community-driven: OpenTelemetry is part of the Cloud Native Computing Foundation (CNCF) and has a growing community of contributors from various organizations, including cloud providers, vendors, and individual developers. This community-driven approach ensures continuous improvement and evolution of the framework.
Flexibility and Interoperability: OpenTelemetry allows for flexibility and interoperability in collecting observability data across different systems and environments. Developers can easily swap out backends or exporters, making it adaptable to different monitoring and tracing setups.
Assessing OpenTelemetry’s Effectiveness
The question we’re discussing daily with potential users of TelemetryHub is, ‘can I instrument my system with OpenTelemetry?’ And the answer is almost always ‘yes.’
Well, mostly. Any system with internet access can report data via the OpenTelemetry standard. And anyone can use an OpenTelemetry Collector to filter, compress, and limit data being sent over the internet to an OpenTelemetry Endpoint.
All is well and good, but what most people want to know is ‘how well will open telemetry instrument my language and framework?’
C++
C++ has most of the pieces that need to be instrumented with OpenTelemetry
The current status of the major functional components for OpenTelemetry C++ is as follows:
The latest release has support to build most projects with the C++ Otel SDK. Note the builds with Bazel are experimental at this stage. See the installation documentation for more detail.
Java
The OpenTelemetry Java project is the most mature of the Otel-supported languages. While Logs are still listed as “experimental,” it’s worth digging into what “experimental” means. From the docs:
Signals start as experimental, which covers alpha, beta, and release candidate versions of the signal. While signals are experimental, breaking changes and performance issues may occur. Components should not be expected to be feature-complete. In some cases, the experiment may be discarded and removed entirely. Long-term dependencies should not be taken against experimental signals.
Later in this article, I will discuss the status of logging within OpenTelemetry, and the short version is that it’s likely you’re already using a logging tool that can be exported to the Open Telemetry format.
.NET
Like C++, .NET support is stable for traces and metrics, but mixed for logs due to the non-stable OTLP Log Exporter.
The current status of the major functional components for OpenTelemetry .NET is as follows:
For logging, while the OpenTelemetryLoggerProvider (i.e., integration with ILogger) is stable, the OTLP Log Exporter is still non-stable.
To be frank, this is probably still usable for most applications since it’s possible to use a tool like ILogger for sending logs. Further, it’s unlikely that logs are the ‘missing piece’ of your observability solution.
Erlang/Elixir
The status of Erlang support makes it worth developing with:
See the definition of ‘Experimental’ above in the Java section; both logs and metrics are currently functioning in the project.
Packages of the API, SDK, and OTLP exporter have been published to hex.pm as opentelemetry_api, opentelemetry, and opentelemetry_exporter.
Go
Go isn’t currently well-supported enough to recommend using OpenTelemetry to monitor your stack. The current status of the major functional components for OpenTelemetry Go is as follows:
Traces
|
Metrics
|
Logs
|
Stable
|
Alpha
|
Not yet implemented
|
Traces are a major component, making it worth a try if you’re currently not observing any part of your go stack. For releases of the Go Otel project, including the latest release, see Releases.
Javascript
OpenTelemetry JavaScript is currently rather advanced
Traces
|
Metrics
|
Logs
|
Stable
|
Release candidate
|
Development
|
As of the latest release, logs were not in a state where they should be used in production. There are several other logging solutions available, and this is an area of active development
It’s worth noting that, in order to perform tracing, OpenTelemetry stores span in the Context. This is necessary to allow tracing of multiple components handling the same basic request. Learn more in the Context API documentation.
Python
Python, that classic of functional programming, is another language with OpenTelemetry support. Only logs are listed as Experimental, which is true across all OpenTelmetry languages. This is listed on the OpenTelemetry documentation page
An OpenTelemetry logging SDK is currently under development. This allows OpenTelemetry clients to ingest logging data from existing logging systems, outputting logs as part of OTLP along with tracing and metrics.
An OpenTelemetry logging API is not currently under development. We are focusing first on integration with existing logging systems. When metrics are complete, the focus will shift to developing an OpenTelemetry logging API.
One question that may come up is, ‘why is logging still in the experimental phase, how hard can it be?’ The counter-intuitive reason is that logging, and the transmission of logging, is largely a solved problem in the tech industry.
Every framework has some way to emit logs, and nearly every organization has tools to transmit and store logs. Data ingest of existing logs tools is a more reasonable focus for the OpenTelemetry project.
Ruby
OpenTelemetry Ruby is ‘not ready for prime time’ as of yet. The current status of the major functional components for OpenTelemetry Ruby is as follows:
Traces
|
Metrics
|
Logs
|
Stable
|
Not yet implemented
|
Not yet implemented
|
For releases, including the latest release, see Releases.
Without Metrics, there’s not a strong case for Otel on Ruby yet. Thankfully there are great APM tools to monitor Ruby applications.
OpenTelemetry GA
From https://opentelemetry.io/docs/reference/specification/versioning-and-stability/
Still, the question remains ‘when will OpenTelemetry reach GA?’ The term “OpenTelemetry GA” refers to the point at which OpenTracing and OpenCensus will be fully deprecated. The minimum requirements for declaring GA are as follows:
A stable version of both tracing and metrics MUST be released in at least four languages.
CI/CD, performance, and integration tests MUST be implemented for these languages.
And we’re close! GA is expected within the next year. The team here is so confident that we’ve released TelemetryHub, a clean, efficient, and reliable endpoint for your OpenTelemetry data.
TelemetryHub enables users to ingest telemetry data from platforms instrumented with the OpenTelemetry CNCF project.
As an early adopter of OpenTelemetry, TelemetryHub benefits from a project with the community support of over 100,000 contributors and is committed to evangelizing and supporting the project through education and contribution. This allows the TelemetryHub team to stay committed to providing the best solution for users and allows our customers the opportunity to implement an ever-maturing, vendor-agnostic solution that lets them have total control and flexibility with their observability data.
Conclusion
OpenTelemetry provides a powerful, flexible, and evolving framework for observing distributed applications. While some languages are more mature in their support, the framework is continuously improving, with GA expected within the next year. The community-driven approach and TelemetryHub’s commitment to education and contribution ensure that OpenTelemetry remains a robust, vendor-agnostic solution for holistic observability.
This article has been editorially reviewed by Suprotim Agarwal.
C# and .NET have been around for a very long time, but their constant growth means there’s always more to learn.
We at DotNetCurry are very excited to announce The Absolutely Awesome Book on C# and .NET. This is a 500 pages concise technical eBook available in PDF, ePub (iPad), and Mobi (Kindle).
Organized around concepts, this Book aims to provide a concise, yet solid foundation in C# and .NET, covering C# 6.0, C# 7.0 and .NET Core, with chapters on the latest .NET Core 3.0, .NET Standard and C# 8.0 (final release) too. Use these concepts to deepen your existing knowledge of C# and .NET, to have a solid grasp of the latest in C# and .NET OR to crack your next .NET Interview.
Click here to Explore the Table of Contents or Download Sample Chapters!
Was this article worth reading? Share it with fellow developers too. Thanks!
Sarah brings with her more than 18 years of experience in the software industry, primarily at Boston based ventures. In addition to her current role as a Sr. Product Manager at Scout, she is a featured speaker at Product School and a product strategy consultant for Tapple.io. Sarah holds a BS in Computer Science from Eckerd College, a Masters of Science in Innovation from Northeastern University, and an MBA also from Northeastern.