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.
The diminishing value of metrics
In the past, we’ve written about the limitations imposed by metrics: their pre-aggregation limits you from being able to segment data in meaningful ways.
One of the core values of observability is that you can arbitrarily slice and dice data, in whatever ways you see fit, to discover new insights. But that doesn’t mean that metrics don’t provide value. It’s helpful to see measures like average latency, requests per second, or any plethora of things that metrics usually tell you.
In observability systems, metrics aren’t replaced because the numbers they generate no longer provide value. Metrics are replaced because they’re too rigid and limiting. As aggregate numerical representations of system state, they only serve one narrow view of one specific system property.
Events, by contrast, still allow you to aggregate measures and calculate the value those metrics provide, as needed. So you can still see measures like average latency, requests per second, or any plethora of things your metrics tell you today. But you can also see what latency was like for one specific userId, for a particular request, the underlying services it touched, the payload of that request, or any plethora of comparisons your little heart desires to make.
In an event-based system, metrics are replaced because their value diminishes significantly.
The metric is dead, long live the metric!
Don’t get me wrong. There’s still a place for metrics in the observability world.
While Honeycomb is centered around analyzing events, you can also send Honeycomb your metrics in a variety of ways. At Honeycomb, like our customers, we use both events and metrics to understand our production systems.
Yes, you can use Honeycomb for metrics. You will likely wind up replacing 95% of your metrics with Honeycomb events and keep the last 5% for use cases that are still best suited to metrics. Namely, those are infrastructure metrics.
Infrastructure metrics measure system resources that affect how well your code runs if they become constraints, e.g. CPU, memory, disk performance, etc. You absolutely need to see those in order to ensure your applications remain healthy.
But the path to getting infrastructure metrics into Honeycomb isn’t always clear to new users.
Events and metrics are fundamentally different data types. Typically, that distinction keeps these data types living in different tools and data sets. Fortunately, Honeycomb can analyze both types of data at the same time. But there are considerations to keep in mind along the way.
The Getting Started With Honeycomb Metrics whitepaper shows you how to use metrics with Honeycomb. First, it examines the role of metrics, how they’re used today, and how their usage should change with observability tools. It then uses practical examples of which metrics to collect and includes code samples that show you how to send them to Honeycomb. Finally, it covers practices necessary to analyze metrics in an event-based context along with tips to help ensure you can properly compare the two.
If you’re wondering how to make metrics and events go together like bees and honey, check out the whitepaper and let us know what you think! You can reach us in the Pollinators Slack group.
