What should one pay for observability? How much observability is enough? How much is too much, or is there such a thing? Is it better to pay for one product that claims (dubiously) to do everything, or twenty products that are each optimized to do a different part of the problem super well? It’s almost enough to make a busy engineer say “Screw it, I’m spinning up Nagios”. (Hey, I said almost.)
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.
