Executive Summary

Thanks for choosing Honeycomb for your debugging and observability needs. Honeycomb is a modern tool that is purpose-built for identifying deeply buried issues in any system with ease, regardless of its complexity. It helps teams align behind proactively building better customer experiences instead of reactively focusing on fixing superficial symptoms that distract from problems that actually matter to the business. That means Honeycomb uses workflows and cultivates practices that may not be entirely familiar to users accustomed to working with traditional monitoring and APM tools.

This guide will help you and your teams ensure a smooth and successful migration away from multi-tool APM suites by showing you what’s different about Honeycomb and how to find the solutions you need. It accelerates time to value by showing teams accustomed to standard monitoring and APM processes how they can reorient their practices and workflows to use Honeycomb’s approach to observability. It answers common questions that former APM users may have and shows them how to use Honeycomb’s most valuable features in ways that may not be immediately obvious when transitioning into a new way of working.

How to Use This Guide

This guide consists of five separate modules that can be read together or separately, based on your preferences. If you want an introduction to our observability approach, start with Module 1. If your goal is to get hands-on experience right away, start with Module 2. If you’re looking to build an internal business case and ROI projection for your Honeycomb adoption plan, Module 5 is your friend.

You may want to combine modules depending on your role. For engineers seeking a quickstart with Honeycomb, Modules 1 and 2 are a great combination. For engineering managers, Modules 1 and 5 may be most interesting, while Modules 2-4 are best for seasoned observability operators and developers looking to quickly understand the technical and functional differences between Honeycomb and APM suites. Of course, if any particular module topic looks interesting to you, start there.

What Honeycomb does

Choosing Honeycomb as a debugging solution gives you fast, powerful insights to understand the world’s most complex systems so you can build better customer experiences. But for teams accustomed to standard APM workflows, it can feel like an uphill battle to switch to an observability-driven workflow. Switching to Honeycomb means adopting several new and more effective ways of finding answers to problems, many of which do not resemble more traditional ways of troubleshooting with legacy tools. This guide will help orient you from the old way of troubleshooting issues to a more modern approach.

Honeycomb helps you answer questions about how your code behaves in production, using techniques that were unfathomable only a few years ago, and in ways that simply aren’t possible with traditional monitoring and APM tools. Honeycomb makes it trivial to sift through a vast range of user transactions, comparing results across thousands of unique high-cardinality dimensions and their billions of combinations, to find the tiniest deviations and surface very-difficult-to-find issues. Honeycomb’s workflow is based on querying your telemetry data in visually simple, interactive, iterative ways that leverage machine algorithms, and combining that with your human intelligence to find the signals you care about within the noise of daily production traffic.

The net result is learning a new way of troubleshooting and determining what might be wrong in your systems. The Honeycomb way does not rely on accumulated knowledge retained in the minds of your most senior engineers in order to investigate issues. Rather, it focuses on a repeatable process that allows anyone on your team—no matter how familiar they are with your stack—to investigate issues from first principles every time. In this world, resolving issues is less about rewarding those with the most application system familiarity and more about rewarding those who are most curious about proactively exploring system performance. Honeycomb encourages you to make fewer assumptions about what may be a problem in your systems and to instead discover every issue as if it were new.

That’s a radical change from how APM-based application system troubleshooting is done. The traditional approach to troubleshooting production relies on intuition (built on prior knowledge) to interpret what separate monitoring and APM signals might be telling you about where a problem exists in your system. Instead, with Honeycomb, you will learn how to use data to quickly form hypotheses about what may be wrong in your system and then use more data to validate or invalidate those hypotheses. It’s somewhat like applying the scientific method to troubleshooting your applications. We know that change can be difficult to navigate at first. But, in a short amount of time, you will learn how to use Honeycomb to put the science back into computer science.

We consistently hear from customers that this approach is revolutionary and that, after learning to work this way, they can’t imagine going back to previous methods. We hope you will also find that to be the case. We think that means you have much to look forward to, but getting there will require you to learn a few different ways to solve problems you might be accustomed to solving in other ways. This guide will show you what you need to do differently.

What makes Honeycomb different

As an APM user, you may have certain expectations of how your monitoring debugging solution operates. As a Honeycomb user, you can expect a few key differences that help unlock the debugging experience described in the introduction section when put together.

A few key differences to expect with Honeycomb vs. typical APM suites:

• Queries return much faster results. Honeycomb queries, even those analyzing incredibly large datasets, typically return results within 2 seconds or less. Anytime you ask a question, you should get real-time answers.
• Near real-time data ingest to query availability. After you send telemetry data to Honeycomb, it is typically available for you to analyze within 3 seconds. This results in debugging capabilities that let you see the impact of changes in real time.
• The complexity of your data will not slow down your results. Honeycomb is designed to work with high-cardinality and high-dimensionality data. That means you can sort through billions of transactions, looking for patterns across thousands of dimensions that may contain highly unique (or high-cardinality) fields (e.g., customer_ID, transaction_ID, etc.) and still get results in seconds. With traditional APM tools, query performance suffers and slows as your dataset grows. With Honeycomb, you continue to get fast results, regardless of how large or complex your data gets.
• We surface differences and you decide what matters. Features like BubbleUp use the best of both worlds: machine compute-power to quickly sift through enormous sets of data, combined with human intelligence to make sense of the results. Our approach doesn’t rely on fallible and mysterious AI. Instead, we augment your own intelligence by making machine analysis work for you. You highlight important spikes in visualizations, machines quickly spot any corresponding deviations, then you click into individual traces to see why those deviations occurred. It’s you at the wheel, but a faster and more powerful you.
• Perform dynamic and complex calculations with derived columns. Similar to using functions in a spreadsheet, derived columns allow you to make custom computation and logic functions on your telemetry data without having to modify the data itself. While some APM tools allow for very complex querying, it limits you to using static data. Derived columns remain available for reuse in later queries, so you can dynamically manipulate your data any way you see fit, whenever you see fit.
• Reduce alert noise and fatigue with Honeycomb’s debuggable SLOs. Our implementation of service-level objectives (SLOs) are a radical shift over typical monitoring workflows. Rather than alert on thousands of potential symptoms, our SLOs allow you to only focus on what matters: customer experience. SLOs consistently monitor application performance against customer-impacting thresholds you define. When customer-impacting issues are detected with enough volume that they threaten your SLOs, our error-budget burn alerts will notify you that an issue exists. But unlike other SLO implementations, with Honeycomb you can debug exactly why that issue is occurring from within the same interface. Honeycomb surfaces the underlying data that is correlated with the failed events in every SLO you set up, so when something becomes a problem, you already have answers. This model drastically lowers alert noise, alleviates alert fatigue, results in fewer false positives (and false negatives), and drastically lowers mean-time-to-detect / mean-time-to-resolution (MTTD/MTTR) when compared to traditional monitoring approaches.
• Team knowledge-sharing is integrated into your experience. Team history and static query links help others on your team learn from your investigative patterns. It’s easy to see which investigative paths led to incident resolutions in the past, backtrack steps and fork off in new directions, and ensure that anyone you’re investigating an issue with can see exactly the same results you see when you run a query. Our static query links also persist permanently—even after the underlying data has expired—so that you can always refer back to the results that led to past decisions. Eschew tribal knowledge by making your steps discoverable and retain organizational memory.

There’s more to consider, but those concerns will make more sense in the context of how they apply to different workflows.

Hands-on with the Honeycomb UI

The differences in the introduction section above may sound promising. But, as they say, the proof is in the pudding. Getting your hands on the product and seeing these differences for yourself is what will develop your basic familiarity and solidify these concepts. Honeycomb helps you get started in two key ways.

First, you can get an introductory tour of the UI and how it works by visiting Honeycomb Play.

If you’ve never seen Honeycomb in action, this guided tour will help you understand Honeycomb basics. Honeycomb’s primary interface is through its Query Builder, where you build queries (as the name implies) to ask questions about your system. The query builder provides an intuitive interface to analyze signals like total requests, latency, errors, or any other telemetry data that your application emits.

You build and submit queries that generate different visualizations to let you quickly see errors, status codes, services, routes, and more all from the main interface. The visualizations (and most elements within the UI) are clickable and filterable. Honeycomb Play will show you how a few of these elements work as a way to help you get started.

In one of the Honeycomb Play scenarios, you’ll learn about one of our key features known as BubbleUp. When you build visualizations that display as a heatmap, BubbleUp lets you select an interesting area within that heatmap to determine what’s different in the selected area. BubbleUp then uses the non-selected area to calculate a performance baseline. It next compares all events in the selected area against the baseline. It analyzes all of those events across all possible dimensions to quickly surface where events in the selected area deviate from the