Jamie Danielson
Senior Software Engineer at Honeycomb.io
New York City, New York, United States
Actions
Jamie is a Senior Software Engineer at Honeycomb where she works on instrumentation libraries. She is an active contributor to multiple OpenTelemetry projects, and is a maintainer for OpenTelemetry JavaScript. When she’s not working she’s playing dek hockey.
Area of Expertise
Topics
The Life of a Span
In the world of distributed systems and observability, spans are the fundamental building blocks that enable us to understand system performance, troubleshoot issues, and optimize our applications. But what really happens when a span is created? How does it flow through an OpenTelemetry pipeline, interact with other spans, and ultimately surface in an observability backend?
In this session, we’ll take a deep dive into the life of an OpenTelemetry span—from its birth in an instrumented application to its final visualization in an observability backend. We’ll explore the various components of OpenTelemetry that interact with spans, including tracers, processors, exporters, and propagators. Using an example application and relying on OpenTelemetry’s default configurations, we’ll follow the span’s journey step by step, gaining insight into how context propagation, data enrichment, and trace exporting work under the hood
OpenTelemetry Contribfest
Join the OpenTelemetry maintainers to make the project better for everyone. You can choose between several opportunities to contribute, and you can count on maintainers from different project areas to help you on your first steps: documentation, Collector, Java, JS, Ruby, Python, .NET, and more.
Measure What Matters
Have you ever had an alert go off that you immediately ignore? It’s a nuisance alert, not actionable, but you keep it around just in case. Have you ever looked at your trace waterfall and wondered what exactly happened during that gap that just doesn’t drill down deep enough to surface meaningful details? Do you know the feeling where you have just enough information to sort of monitor what’s going on in your systems, but not quite enough to put your mind at ease or feel like you know where to look when things go wrong?
These experiences are almost universally known, something that everyone can relate to at some point in their observability journey. This session will help tackle common pitfalls, offering strategic ways to improve your observability. Armed with a mix of tailored custom instrumentation and well-reasoned SLOs, you’ll walk away able to help yourself and your team sleep better at night knowing you are measuring what matters and reducing the noise of unhelpful alerts.
Fine-tuning Auto-instrumentation
Automatic instrumentation is a great way to get started in any observability journey. For many, the telemetry gleaned from these libraries is enough to cover the majority of important use cases. But while everything may be covered in these libraries, there is also a lot included that may not be needed or desired. At that point it’s important to understand how to fine-tune the instrumentation based on configuration options available.
Attendees will get a run-through of common instrumentation configurations available in most auto-instrumentation libraries, with some practical use cases and common recommendations.
Journey to Becoming an OpenTelemetry Approver
When I first started learning to write code, contributing to open source seemed terrifying. People talked about it as an amazing resource and made it seem like it would be easy to jump into a project. But I was hesitant to get involved because it would be very much an exercise of working in public. What if my code is bad? What if I don't understand what's happening? What if I embarrass myself?
Through contributing to open source projects over the last few years, I’ve learned a few lessons about how open source communities work. We're all human and we all want good code and good support for our code. In this session I’ll talk about what it was like to start contributing to a big open source project, and the lessons I learned along the way that eventually led to becoming an approver on a repository that I contributed to.
Build in Observability While Developing
We’ve heard that observability is important to understand what is happening in production. But carving out the time to add instrumentation to a codebase can seem daunting, and is often treated as a separate task to writing features. This means that we end up instrumenting for observability long after a feature has shipped, usually when there’s a problem with it and we’ve lost all the context.
What if we instead treated observability similarly to how we treat tests? We wouldn't submit our code without a test. Let’s do the same with observability. Treat it as part of the feature while the code is still fresh in our mind, with the benefit of being able to observe how the feature is behaving in production.
We’ll cover practical ways to instrument during development so it feels like a natural part of the development workflow. Because if you know how to log, you know how to trace.
Just because you didn’t think of it doesn’t make it an edge case
Even when you think you're designing for and testing for all use cases, there will be scenarios you haven't thought of. These are not always "edge" cases - they are simply blind spots or unexpected use cases. Put another way, these are the unknown unknowns. By their very definition you cannot account for them, but you can plan for them by having safeguards in place that allow you to quickly iterate on production code to handle the inevitable impact caused by unknown unknowns.
We have experienced this plenty of times at Honeycomb as customers send us new variations of telemetry and use our product in ways we hadn't thought of. A prime example of this occurred when we enabled a new type of ingest that seemed relatively straightforward. We added a feature flag for this functionality, though it seemed excessive and unnecessary - it was just extra code to maintain for a fairly trivial new feature. This feature flag ended up saving our bacon when an unexpected shape of data almost took down production.
KubeCon + CloudNativeCon North America 2026 Sessionize Event Upcoming
CNCF-hosted Co-located Events Europe 2026 Sessionize Event
OTel Community Day 2025 Sessionize Event
Project Lightning Talk + Maintainer Track + Contribfest: KubeCon + CloudNativeCon Europe 2025 Sessionize Event
CNCF-hosted Co-located Events North America 2024 Sessionize Event
Project Lightning Talk + ContribFest + Maintainer Track: KubeCon + CloudNativeCon North America 2024 Sessionize Event
OTel Community Day North America 2024 Sessionize Event
KubeCon + CloudNativeCon North America 2023 Sessionize Event
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top