Adriana Villela is a CNCF Ambassador, blogger, host of the Geeking Out Podcast, and a maintainer of the OpenTelemetry End User SIG. By day, she's a Principal Developer Advocate at Dynatrace, focusing on Observability and OpenTelemetry. By night, she climbs walls. She also loves capybaras, because they make her happy.
We keep telling developers they need to instrument their own code with OpenTelemetry (OTel). When they do, it feels like they’re doing it for the benefit of others, like SREs. Observability can benefit developers too, but it feels too complicated, and as a result Observability is treated as a second-class citizen.
This talk changes that by motivating developers to troubleshoot their own code with OTel. Developers will learn:
- Why do it?
- Basic overview of OTel instrumentation concepts
- Overview of desktop tooling for developers to visualize OTel data
- How to add meaningful traces, metrics, and logs to your code with minimal changes
- A practical, repeatable workflow for using OTel to troubleshoot code
- Common pitfalls (like accidental high cardinality) and how to avoid them
- A live demo putting it all together
Developers will walk away with the confidence to instrument and troubleshoot their own code with OTel.
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.
Searching for speaker images...