It was a wet day in Seattle at KubeCon + CloudNativeCon North America in December 2018 once I first encountered the time period ‘OpenTelemetry.’ At the moment, I used to be an lively member of a working group targeted on growing W3C Hint Context, a typical now extensively employed for context propagation in distributed programs. It’s seemingly no coincidence that some key people on this working group additionally performed a pivotal function in orchestrating the merger between two distinguished open supply telemetry merchandise: OpenCensus and OpenTracing. I by no means would’ve guessed that, in 2023, OpenTelemetry would change into the second-largest undertaking within the CNCF, sitting simply behind Kubernetes.
As is the case with any common new know-how like OpenTelemetry, the hype could make it tough to discern sign from noise. Throughout my years working in observability, I’ve had the prospect to speak with many organizations that have been occupied with utilizing OpenTelemetry or already actively use it. By way of these conversations, I’ve heard many causes for adopting OpenTelemetry, some good and a few unhealthy. On this submit, I’ll share examples of the perfect and worst causes to undertake OpenTelemetry that will help you reduce by the noise.
Poor Cause One: Following the Crowd
It’s by no means a good suggestion to undertake one thing solely as a result of others are doing it. Simply since you noticed a convention speak praising a brand new know-how as the best innovation since sliced bread doesn’t essentially imply that know-how is appropriate to your particular use case.
Talking of which, have you ever clearly outlined your use case? To start out, ask your self the next three questions:
1. Can you decide at any given second whether or not your programs are performing as anticipated, comparable to assembly their service degree goals (SLOs)?
2. When one thing goes unsuitable, are you able to simply pinpoint the basis trigger?
3. Can you drill into beforehand unidentified issues, often known as “unknown unknowns”?
For those who answered these questions with “no,” you definitely have observability gaps value tackling, and OpenTelemetry might assist shut a few of them.
Poor Cause Two: Constructing Your Personal Observability Product
Gathering telemetry knowledge is usually a problem, and with OpenTelemetry now dealing with important alerts like metrics, traces and logs, you may really feel the urge to save lots of your organization some money by constructing your individual system. As a developer myself, I completely get that feeling, however I additionally know the way straightforward it’s to underestimate the hassle concerned by simply specializing in the enjoyable components when kicking off the undertaking. No joke, I’ve truly seen organizations assign groups of fifty engineers to work on their observability stack, regardless that the corporate’s core enterprise is one thing else fully.
Take into account that knowledge assortment is only a small a part of what observability instruments do nowadays. The actual problem lies in knowledge ingestion, retention, storage and, finally, delivering precious insights out of your knowledge at scale. Chances are high, a homegrown resolution gained’t provide you with a return on funding that your organization would admire.
Nonetheless, whether or not you construct your individual system or use an current product, OpenTelemetry could also be an excellent match to your observability stack.
Poor Cause Three: ‘Vendor Neutrality’
Folks I chat with typically cite vendor neutrality as a significant cause for his or her curiosity in OpenTelemetry. Whereas there’s some fact to this, which I’ll contact on shortly, it’s vital to take this argument with a grain of salt to keep away from over-promising your administration.
For those who’re a developer, you’ve seemingly labored with database abstraction libraries and have most likely talked about to somebody that they mean you can swap out the database at any time–utilizing MySQL right now and Oracle tomorrow, for example. Whereas that’s the promise, I’ve by no means seen this occur in my profession. There’s extra to think about aside from the SQL dialect when switching a database backend.
In the identical vein, the thought of vendor neutrality suggests which you can simply change your observability backend. Whereas this is perhaps true in concept, in follow, vendor lock-in typically happens on the backend, the place individuals and processes change into carefully tied to the software at present in use.
So, when you imagine you’ve achieved vendor neutrality by going all-in with OpenTelemetry, I’d encourage you to assume twice and take into account constructing a stronger case. Vendor neutrality shouldn’t be your solely cause.
With all that mentioned, it’s time to deal with the great causes to make use of OpenTelemetry right now. Belief me, there are lots, they usually’re positively value contemplating.
Good Cause One: Bridging Gaps With Guide Instrumentation
Practically each observability software on the market right now depends on a point of auto-instrumentation. This implies when you’ve added their respective language SDK to your code, the library will make the most of a method known as “monkey patching” to insert observability code that runs mechanically.
On the very least, auto-instrumentation will seek for acknowledged libraries and APIs after which add some code to point the beginning and finish of well-known perform calls. Moreover, auto-instrumentation takes care of capturing the present context from incoming requests and forwarding it to downstream requests.
Nonetheless, auto-instrumentation falls quick in the case of pure userland code, notably for dynamic languages like JavaScript. It gained’t catch your blocking Fibonacci perform that’s slowing down all of your requests by 50%. In some circumstances, you may also have so as to add your individual context-propagation logic to RPC calls not captured by the auto-instrumentation.
That’s the place handbook instrumentation is available in. Prior to now, distributors supplied an API for his or her SDK, permitting builders to manually add instrumentation code to segments that weren’t auto-instrumented. This typically resulted in code being plagued by vendor-specific directions. This brings us again to the subject of vendor neutrality. Whereas including a dependency to your undertaking is normally no massive deal, it turns into cumbersome when 20% of your codebase is made up of vendor-specific observability instrumentation.
OpenTelemetry addresses this subject by providing each auto-instrumentation and a vendor-neutral API for handbook instrumentation. This permits observability distributors to entry the information whereas sustaining vendor neutrality inside your codebase.
Good Cause Two: Sending Knowledge to A number of Distributors
I’ve but to return throughout a big group that depends on only one observability software. Completely different components of the group have distinctive wants and views in the case of knowledge, and it’s uncommon {that a} software designed for SREs satisfies all use circumstances builders have and vice versa.
On the identical time, it’s not sensible to instrument code particularly for every vendor. Doing so would result in efficiency points and different issues, comparable to double-tracing. For instance, if a number of distributors modify an outbound HTTP request so as to add context, which one takes priority?
OpenTelemetry addresses this by providing a unified strategy to instrument code and a number of integration factors the place distributors can seize the collected knowledge and ship it to their respective backends. In consequence, a single utility can ship knowledge to a number of observability backends with a minimal added efficiency affect.
Good Cause Three: Gaining Perception Into Third-Social gathering Libraries and Companies
In an period the place many purposes rely upon third-party libraries and providers, gaining perception into all of your utility dependencies has change into more and more tough. It’s additionally difficult for observability distributors to maintain up with each new library and repair that’s launched.
Historically, distributors would attempt to reverse-engineer these providers and apply the aforementioned monkey patching so as to add of their code. Nonetheless, since each vendor should do that for every service, it finally ends up being quite a lot of redundant work. A key objective of the OpenTelemetry undertaking is to make it straightforward for infrastructure and library distributors so as to add instrumentation hooks to their code. This manner, their choices may be monitored with out the necessity for reverse engineering. The observability group is steadily making progress on this objective. One profitable instance is Istio, which emits OpenTelemetry knowledge that may be simply consumed by observability backends to know what’s taking place contained in the service mesh.
Unsurprisingly, cloud distributors like AWS, Microsoft and Google are among the many founding members of the OpenTelemetry undertaking. They share a powerful curiosity in defining a format that permits observability distributors to seamlessly eat knowledge from cloud providers. OpenTelemetry Protocol, or OTLP, is ready to change into the usual for emitting observability knowledge from these providers that will in any other case be black packing containers.
Wrapping it Up
“If all you might have is a hammer, each downside seems like a nail.” This assertion holds very true when deciding on instruments within the tech trade. Whereas there are various good causes to undertake OpenTelemetry, it’s essential to strategy know-how selections pragmatically.
Keep away from leaping on the bandwagon for its personal sake; as an alternative, fastidiously consider your use case and assess the out there instruments. OpenTelemetry is undoubtedly right here to remain, and when you’re new to the subject, taking a better take a look at the undertaking and including it to your toolbelt makes good sense.
And don’t overlook: OpenTelemetry is open supply. Your contribution is all the time appreciated.