Uncovered: The Hard Truth About OpenTelemetry's Vendor Neutrality

We still hear people saying, "OpenTelemetry is vendor neutral so you can switch vendors any time you want to." This is like saying that because the vCard format exists, it's easy to switch from iOS to Android. Sure, your core data will ultimately be portable, but you'll be missing a *lot* of other things.

Does that make vendor neutrality moot? Not at all! Vendor-neutral instrumentation means that all of our code artifacts aren’t impacted by tool changes. Switching vendors won’t be like waving a magic wand, but it will be much easier thanks to OpenTelemetry (OTel). We’ll cover some of the challenges and pitfalls, and offer best practices to make this process as pain-free as possible. We’ll discuss:

* OTel API and SDKs: they ease the pain of total tool switch, but aren’t a magic wand
* The OTel Collector’s simulcast capabilities to multiple tools and how it helps enable vendor “bake-off” evaluations
* The OpenTelemetry Protocol (OTLP): the best part of OpenTelemetry (hint: vendors used to all have their own exporters, but now most accept OTLP)
* What’s transferable between vendors vs what’s not
* Even the instrumentation isn’t always safe: Structuring your your OTel data to optimize for a vendor

Attendees will come away with an understanding of what OTel vendor neutrality means, so that they can make informed decisions when considering switching to or adopting new tooling.

Uncovered: The Hard Truth About OpenTelemetry's Vendor Neutrality

We still hear people saying, "OpenTelemetry is vendor neutral so you can switch vendors any time you want to." This is like saying that because the vCard format exists, it's easy to switch from iOS to Android. Sure, your core data will ultimately be portable, but you'll be missing a *lot* of other things.

Does that make vendor neutrality moot? Not at all! Vendor-neutral instrumentation means that all of our code artifacts aren’t impacted by tool changes. Switching vendors won’t be like waving a magic wand, but it will be much easier thanks to OpenTelemetry (OTel). We’ll cover some of the challenges and pitfalls, and offer best practices to make this process as pain-free as possible. We’ll discuss:

* OTel API and SDKs: they ease the pain of total tool switch, but aren’t a magic wand
* The OTel Collector’s simulcast capabilities to multiple tools and how it helps enable vendor “bake-off” evaluations
* The OpenTelemetry Protocol (OTLP): the best part of OpenTelemetry (hint: vendors used to all have their own exporters, but now most accept OTLP)
* What’s transferable between vendors vs what’s not
* Even the instrumentation isn’t always safe: Structuring your your OTel data to optimize for a vendor

Attendees will come away with an understanding of what OTel vendor neutrality means, so that they can make informed decisions when considering switching to or adopting new tooling.

Uncovered: The Hard Truth About OpenTelemetry's Vendor Neutrality

We still hear, "OpenTelemetry (OTel) is vendor neutral so you can switch vendors any time you want to." This is akin to saying because the vCard format exists, it's easy to switch from iOS to Android. Yes, your core data will ultimately be portable, but you'll be missing a lot of other things.

This doesn't make vendor neutrality moot. Vendor-neutral instrumentation means that all of our code artifacts aren’t impacted by tool changes. Switching vendors isn't like waving a magic wand, but it is much easier thanks to OTel. We’ll cover some of the challenges and pitfalls, and offer best practices to make this process as pain-free as possible. We’ll discuss:

* OTel APIs/SDKs ease tool migration: helpful but not foolproof
* OTel Collector enables multi-tool simulcast, ideal for vendor "bake-offs"
* OpenTelemetry Protocol (OTLP): OTel’s standout feature
* What's transferrable between vendors vs what's not
* Even the instrumentation isn’t always safe: Structuring your your OTel data to optimize for a vendor

Attendees will come away with an understanding of what OTel vendor neutrality means, so they can make informed decisions when considering switching to or adopting new tooling.

The Power of Consolidation: A Unified Stack for Business Intelligence, Security, and Observability

Imagine you’re responding to a production incident, and you’re trying to answer simple questions about it. How many systems do you need to consult when assessing the impact of events at your company? Do you manage different technology stacks for observability, security, and business intelligence?

What if we told you, you could create a unified stack capable of serving all stakeholders simultaneously? In this talk, Mya and Josh explore how open source technologies like ClickHouse, OpenTelemetry, and Grafana enable complex business use cases using modern tooling and practices.

Regardless of your function, you will leave with a deeper understanding of how consolidating these concerns into a unified stack reduces technical complexity and provides a common language for everyone to use - from engineers building new features and product managers evaluating their success, to operators keeping the lights on and C suite’s birds-eye view of the company.

The Open Source Hero's Journey

Joseph Cambell's story-circle describes the journeys of epic heroes from the known into the unknown in search of rewards. Maybe it's not so different from the Gartner Hype Cycle that describes the journeys of innovations; And as individual developers we also go through a journey of discovery when adopting new tools and technologies.

DevOps is a Foreign Language (or why there are no Junior SREs)

DevOps has a notoriously steep learning curve. Getting started in the field can feel like being dropped in a foreign country without the ability to understand *anything* about the language.

A language is more than just the syntax and semantic rules of the words themselves. It also encompasses the shared culture of the speakers. With the proliferation of programming languages as well as the deeply held cultural beliefs of the community, it's easy to see that learning DevOps is like trying to learn a foreign language.

I will review five foundational hypotheses from the field of Second Language Acquisition and relate these hypotheses back to the world of DevOps. DevOps practitioners, trainers, tool builders, and learners should all come away with useful insights to apply to their practice.

The five hypotheses referenced in the talk description come from Krashen and are sometimes grouped under the Input Hypothesis.

The Input Hypothesis states that we optimally acquire language when we are exposed to new inputs of the size "i+1", where "i" represents already comprehensible input and the "1" or new input to the learner is as small as possible. How can we reconcile this theory against the many layers of knowledge now necessary for modern software development and operation?

The Acquisition-Learning Hypothesis theorizes about the roles of conscious learning and subconscious acquisition of knowledge through practice. This relates to the Monitor Hypothesis, which states that "Learning" can only be used as a feedback loop, not as a source of original or spontaneous speech. This clearly relates to the process of reading tutorials and learning about fundamental concepts in software development versus the process of applying that knowledge to solve specific tasks. How can we combine these two learning modalities for maximum effectiveness?

The Natural Order Hypothesis relates to the overarching linguistic concept of Universal Grammar. It states that all learners acquire language features in the same preset order. In my research for this talk I am still looking for examples from the world of devops that relate to this specific theory. In the absence of a specific connection, I could spend 60 seconds explaining Universal Grammar using the origin story of Nicaraguan Sign Langauge, an incredible story about human brains and socialization.

Finally, the Affective Filter Hypothesis tells us that our emotional state can be one of the largest factors in our ability to acquire new knowledge — an important reminder that we must always consider the humans that help make up our socio-technical systems.

The OpenTelemetry Hero’s Journey: Working with Open Source Observability

Having correlated metrics, traces, and logs from our services and infrastructure is a vital component of observability. We will discuss what’s possible with OpenTelemetry and where the gaps are with today’s open source tools.

Modern Application Debugging: An Intro to OpenTelemetry

In this talk, I'll be sharing my insights and experiences with OpenTelemetry, an open source project that offers protocols, APIs, and SDKs for collecting metrics, traces, and logs from applications and services. I will cover the tools provided by the OpenTelemetry Community, including the Language SDKs, the Collector, and the OTLP formats for Metrics, Traces, and Logs.

I'll demonstrate how to instrument and observe a microservices application running on a Kubernetes cluster, utilizing the resources that OpenTelemetry has to offer. By the end of the presentation, you will have a deeper understanding of how to use open source tools like Jaeger and Prometheus to analyze the telemetry signals from your application.

Join me as I delve into the fascinating world of OpenTelemetry, sharing my knowledge and expertise to help you make the most of this powerful technology in your own projects.

Presented at:
DevOps Days NYC 2023

Where’s the Auto in Auto-Instrumentation? A look at current automation strategies with OTel

“Automatic Instrumentation” can mean a lot of things depending on context. Whether we’re discussing the Instrumentation SDKs or full-kernel observability with eBPF, the promise is the same: end-to-end observability coverage with no custom code and minimal setup.

First, I will review how the different mechanisms available for automatic instrumentation work within each of the 11 languages supported by OpenTelemetry. I’ll examine:

- how code-path instrumentation works at the library level by diving into the Node.js OpenTelemetry Extension and the JavaScript libraries it supports
- automatic instrumentation via attachment with Java and Python
- automatic instrumentation injection using the OTel Operator for DotNet, Java, and NodeJS

Finally, I’ll take a peek at the future of automatic instrumentation of compiled binaries with a look at the Go instrumentation library built using eBPF.

In this talk will attempt to clarify the different mechanisms that are often colloquially lumped under the term “Auto-Instrumentation” and help to clarify for end users exactly what is possible within each supported language. I will answer questions that I hear often about instrumentation such as “will I need to modify my application code?”, “will it work without Kubernetes?”, “Will I be able to use the libraries I’m currently using?”, and “how can I use this in a completely custom code base?”