Operations | Monitoring | ITSM | DevOps | Cloud

Happy December! Back in October, we cohosted a SPOOKY HALLOWEEN meetup with our pals at LaunchDarkly about testing in production. Here’s a review of the talks we saw!

This blog miniseries talks about how to think about doing data analysis the Honeycomb way. In this episode, we announce an exciting new feature, currently in beta. Honestly, we’re so excited to get this out the door, we haven’t settled on a final name so for now, we’re going with “Codename: Drilldown.”

In this blog miniseries, I’m talking about how to think about doing data analysis, the Honeycomb way. In Part I, I talked about how heatmaps help us understand how data analysis works. In Part II, I’d like to broaden the perspective to include the subject of actually analyzing data.

Honeycomb has always been about flexibility, power, and speed — and about working with your data in a way that other vendors say is impossible. But now Honeycomb is also about being easier than ever to orient yourself and begin getting value out of your data right away.

You probably know that Honeycomb is the most flexible observability tool around. Its powerful high-cardinality search makes working with real raw data quick and easy. But as you may have learned through hard experience, fetching those dots can still be quite a challenge.

In this blog miniseries, I’d like to talk about how to think about doing data analysis “the Honeycomb way.” Welcome to part 1, where I cover what a heatmap is—and how using them can really level up your ability to understand what’s going on with distributed software. Heatmaps are a vital tool for software owners: if you’re going to look at a lot of data, then you need to be able to summarize it without losing detail.

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.

Our new RubyGems.org public dataset is now available — use it to analyze global download traffic of all gems hosted on RubyGems!

Honeycomb strives to be a fast, efficient tool; our storage back-end satisfies the median customer query in 250ms (and the P90 in 1.3 seconds). Still, every system has its limits, and customers with large datasets know that querying over a long time range, grouping by high-cardinality columns, building complex derived columns, and throwing a quantile or heat map into the mix can lead to some pretty slow queries. If this sounds familiar: good news!

When we release something new, whether it’s a new SDK or Beeline or a new feature in the UI, we’ll often set a Honeycomb Trigger to keep track of its use. Sometimes we don’t necessarily have a customer we know is immediately going to use the feature in question, and we’re interested in when it happens.