Liberate Your DevOps Journey with OpenTelemetry

Industry events — like our upcoming annual user conference, .conf20 — are more than a place to “grab” swag and reminisce with industry peers. Now, more than ever, industry events are key to feeding the continued adoption of modern tooling and practices. One of those practices is open instrumentation and data collection, and this year at .conf20 we get to talk about a project at the heart of it all, OpenTelemetry.

Open instrumentation and data collection might seem to be more of an ideal than a design pattern. But the idea that enterprises should not be held back by how they instrument their management plane has widespread impacts on all aspects of building, running and supporting cloud-native applications. As organizations build a strategy for on-boarding new tools, updating existing ones and implementing standards, the practice of open instrumentation has to be part of that.

A key component of any application management plane is monitoring and Observability. What is Observability without data? The success of monitoring and Observability practices is dependent on timely, high resolution and high fidelity inputs from the systems being managed. The most common way to collect data from systems today is agents and, increasingly more common, instrumenting code.

This is where OpenTelemetry (OTel) comes in. Splunk, who understands the power of data, is a co-founder and fully committed to OpenTelemetry. So much so that we are currently the #1 in contributions to-date. 

This open-source project removes the shackles most organizations encounter with agents and client libraries so they can effortlessly move past instrumentation and focus on monitoring, Observability and shipping great code.

Without OTel Change is Scary

Without tooling like OTel, enterprises have to balance enhancements of their delivery chain and DevOps environments with the complexity of implementing that change. This is a choice no organization should have to make. Tools should not dictate your transformation. And in a world where being the disrupter — not the disruptee — is absolutely critical to future success, tools that hold you back already set you on the wrong path from the get-go.

When organizations are dealing with static monolithic applications, instrumentation challenges usually translate to when to update (or not). But in modern application architectures where organizations are dealing with 100+ services, distributed across clouds, each with their own lifecycle, making any change on how telemetry is collected from these systems can be a challenge. It’s not just as simple as installing an agent. It first has to be orchestrated with infrastructure-as-code tooling. Next, the configurations need to be standardized. And third, it needs to be flexible enough so that every change to the application does not force a change in the instrumentation. If your environment has — and most do — more than one type of agent for monitoring and Observability, then the above is simply not possible because each agent and library is unique, so the challenges amplify at an exponential rate.

_{^{Architecture example using OTel Collector}}

The first benefit you get from OTel is that all instrumentation is decoupled from your application stack, your infrastructure and a vendor. So how you collect telemetry from tool A, B and C are all the same. When tool D shows up you are not faced with a question of how to support it without major disruption. Instead, you get to focus on execution.

Scale is Exactly Why You OTel

Enterprises  have to operate at scale, which is the primary inhibiting factor to adopting any new tooling or process. In these environments, open instrumentation with OTel is not really a choice – it’s a necessity. It’s fundamental for enabling organizations to continue being disrupted, or to be the ones doing the disrupting. OTel gives enterprises the freedom to scale modern monitoring and Observability practices without thinking about tool-specific considerations.

OpenTelemetry Today and Future

So here is what I want to tell you about where the OTel project is going. OTel is not yet GA, but it is getting there fast. And that velocity matters a lot when you look at the health and sustainability of open-source. Splunk recognized this and has invested heavily in both resources and dollars.

“It is clear that the Observability space will be driven by open-source and vendor-agnostic instrumentation and data collection. OpenTelemetry is becoming the standard and already has broad support and adoption from cloud providers, vendors and end-users. As co-founders of the project, we are excited to help accelerate its adoption and continue leading the way in Observability.” — Steve Flanders, Director of Engineering, Splunk

The governance committee, amount of activity and roadmap of OTel are fantastic signs of the strength of the project. As OTel expands its capabilities beyond Observability, it is moving towards becoming a one-stop shop solution for telemetry data collection for legacy and modern applications and infrastructure. Here are some highlights.

Expanding Stack Support
Having out-of-the-box support for your stack certainly helps accelerate the adoption and robustness of any tool. Here is what you have to look forward to:

• .Net Auto-Instrumentation support
• Java Auto-Instrumentation support
• Python Auto-Instrumentation support
• Guidance on mapping between OpenTracing and OpenTelemetry
• Broader support for OpenTelemetry Line Protocol (OTLP)
  
  

Metrics
The foundation of OTel has been on traces and spans, but rapid support for metrics is being added.

Splunk Support
Specific support for Splunk is coming very soon.

Logging
This is an absolutely key component that broadens the range of data OTel can receive, manipulate and export. 

Documentation
All techies have intense feelings around the quality and usefulness of documentation. The governance team of OTel know this, and contributors continue to invest effort in keeping documentation robust and current.

Getting Started with OpenTelemetry

At .conf20 you have an awesome opportunity to join a collection of sessions on OTel; hearing from project contributors is one of the best ways to understand the value and get started. Also, check out the large community and webinar content.

How you collect telemetry from your applications is the first critical step in better monitoring and Observability practices. The OpenTelemetry project is standardizing and adding more capabilities, without architecting DevOps teams into a corner.

Follow all the conversations coming out of #splunkconf20!

Follow @splunk

----------------------------------------------------
Thanks!
Chris Riley