Description
I want a clear picture of how my application is performing in production, but proper observability involves a lot of faff. So let's look at how to add metrics to an application with only a few lines of code and an open-source library called autometrics-py.
Marie Curie said, “Nothing in life is to be feared, it is only to be understood.”
For developers, writing code is a big part of our lives. And if we want to understand how the code we write is actually performing out in the wild, then we need to use techniques and tooling from the world of observability.
This poses a problem for many of us, including myself: Observability tooling is itself fear-inducing!
Yes, I would love to understand how my code is doing after I release it onto the scary internets. (Please. Tell me. I have no idea.)
However, the path to an observable codebase is full of easy-to-take wrong turns and very confusing signage. Speaking personally, I needed to get to know the the quirks of a time-series database, determine what to measure (and how to measure it), label my data correctly, and then learn a new query language to generate charts that would help me understand whether or not my app is doing as well as I (really, really) hope it is.
I am a developer. I’ve been creating web applications for a decade. And yet, before working for an observability company, I still relied mostly on carefully placed log statements to debug my production code.
This is why I started contributing to autometrics-py, which is a small, open source micro-framework that exposes a cute little python decorator to make implementing observability best practices much, much simpler for developers. (To be clear: I am by no measure an expert in observability, but that’s exactly why I’m excited to share what I’ve learned while helping to make it easier for others.)
In this talk, we’ll cover what makes observability tricky, especially for devs, and how we can do away with this trickiness by making some smarty-pants assumptions about the type of data we are most interested in. We’ll focus on the unique power of getting metrics at the function level (because who doesn’t love functions?!), and emerge with the confidence of Marie Curie when it comes to understanding the health of our codebase in production.