Event Foo: A Series of Unfortunate/Incredible EventsBy Charity Majors | Last modified on August 23, 2021
Good technical intuition is one of the things that defines a good senior engineer. And unpacking that intuition is the most valuable teaching tool. By making your implicit assumptions and experiences explicit, others can learn from them.
Lately I’ve been having a lot of conversations with people about debugging with events, or structured log data, with a dawning realization that this is not a universal experience. What I thought was as normal as code reviews is an intuition fed by some highly specific experiences.
Events seem ordinary and intuitive to many engineers—that’s how our brain works, after all—but not all of us. Furthermore, many engineers in the ops space have spent years or decades learning, intentionally and painstakingly, to retrain their brains to think in terms of metrics and aggregates. Which does not come as naturally, but is no less sticky once learned.
What makes an event useful or good? What makes it not-useful, or even deceptive? Instead of assuming full knowledge, let’s assume none and start from scratch.
We have invited some of our favorite people to start at the beginning and unpack their experience and understanding of how to debug with structured log events. Enjoy.
Part 1: you’re reading it :)
When an organization signs up for Honeycomb at the Enterprise account level, part of their support package is an assigned Technical Customer Success Manager. As...
Incidents happen. What matters is how they’re handled. Most organizations have a strategy in place that starts with log searches—and logs/log searching are great, but...