Honeycomb is an event-based observability tool. Rather than relying on the rigid pre-aggregated measures provided by metrics, Honeycomb instead favors using events because they provide a much greater degree of flexibility. But that doesn’t mean metrics don’t belong in Honeycomb. Our new whitepaper, Getting Started With Honeycomb Metrics, breaks down exactly how to do that.
As a Customer Advocate, I talk to a lot of prospective Honeycomb users who want to understand how observability fits into their existing Site Reliability Engineering (SRE) practice. While I have enough of a familiarity with the discipline to get myself into trouble, I wanted to learn more about what SREs do in their day-to-day work so that I’d be better able to help them determine if Honeycomb is a good fit for their needs.
At Honeycomb, we talk a lot about eating our own dogfood. Since we use Honeycomb to observe Honeycomb, we have many opportunities to try out UX changes ourselves before rolling them out to all of our users. UX doesn’t stop at the UI though! Developer experience matters too, especially when getting started with observability. We often get questions about the difference between using our Beeline SDKs compared with other integrations, especially OpenTelemetry (abbreviated “OTel”).
Thanks to awesome contributions from the community and the hard work of our integrations team, the Honeycomb Rails integration comes with lots of great features out of the box. This post is an end-to-end tutorial to show you exactly the steps involved, from creating a new Honeycomb team to getting your data in and observing your app in production.
Curious how to get data flowing from your Go application into Honeycomb using OpenTelemetry? This guide will help you step by step through adding OpenTelemetry into your web service and sending the data to Honeycomb.
Thank you so much to all who attended Raw & Real Ep. 5 “All Aboard! Bring Your Team Together,” and to any who take the time out of their busy days to watch the recording 🙂 This was a session for those who would describe yourselves as “internal champions” of Honeycomb and Observability.
Have you heard the buzz about observability with Honeycomb 🐝? It’s the best tool on the market for observing your systems in real time to reduce toil and delight users. But don’t listen to us, listen to our buzzing community of “Pollinators”–this blog post is dedicated to them 💖 An invite is sent to our shared Slack workspace “Pollinators” to everyone who signs up for Honeycomb.
At ecobee, adopting Honeycomb started as a grassroots effort. Engineers signed up for the free tier and quickly started sharing insights with teammates. When it came time for ecobee to make the “build vs. buy” decision for observability tooling, sticking with Honeycomb was the clear choice. Now on the enterprise plan, ecobee’s engineering squads rely on features like SLOs to support the business’s need to map engineering effort to user impact.
Honeycomb’s event-based pricing model is pretty simple: we only care about how many events you send. For teams running workloads at scale, the question becomes: are all of my events worth keeping? How can you reduce overall event volume while maintaining fidelity? This HoneyByte is all about sampling strategies you can use to lower costs without sacrificing the value of your data.
We’ve released some improvements to our Java Beeline library! Allow me to share all the interesting new features.
