In our previous post about Honeycomb Tracing, we used tracing to better understand Honeycomb’s own query path. When doing this kind of investigation, you typically have to go back and forth, zooming out and back in again, between your analytics tool and your tracing tool, often losing context in the process.

When we released derived columns last year, we already knew they were a powerful way to manipulate and explore data in Honeycomb, but we didn’t realize just how many different ways folks could use them. We use them all the time to improve our perspective when looking at data as we use Honeycomb internally, so we decided to share. So, in this series, Honeycombers share their favorite derived column use cases and explain how to achieve them.

We’ve been on a roll this year with Beelines, our integrations for quick, easy, and automagic instrumentation of your apps. You may have already seen our Node.js, Ruby, and Go beelines – today, we’re excited to announce the release of the Honeycomb Beeline for Python!

We’re all collectively trying to define observability (“o11y,” pronounced “olly”) these days, and, as Honeycomb is sometimes described as an event-based observability product, trying to define all the other words that go around o11y at the same time.

In our world of distributed systems, state changes to your infrastructure often take some time to propagate. With a few exceptions (for example, feature flags), single point in time changes are rare. Deploys, outages, database migrations, failovers, stress tests; none of these things are instantaneous – all have some duration during which the system is changing.

Meet the Honeycomb Beeline for Ruby. Like our Beelines for Go and Node, it understands the common packages you’re using and automatically instruments them to send useful events to Honeycomb. Then once you’ve got a chance to explore your app’s behavior, you can add custom fields specific to your app with just one line of code.