Honeycomb offers unique advantages over traditional techniques, and those advantages make our users better engineers and debuggers. In the world of distributed systems and complex problems, debugging skills are becoming increasingly important.
“We’re all distributed systems engineers now” –Charity Majors, CEO and co-founder
In a traditional monitoring system, engineers are frequently pinned between two or more undesirable alternatives: they can either pre-aggregate data and lose precious detail, or keep lots of data but suffer very slow querying and large costs.
Honeycomb, in contrast, hits a sweet spot between these two and is backed by a blazing fast columnar store which can run queries on many millions of rows in seconds. It encourages a fluid workflow and rapid iteration speed in answering questions to solve problems, and still exposes the raw collected data to analyze in as much detail as desired. Because engineers are able to get both high- and low- level information, they become better at solving problems more rapidly.
Example: Your website is suddenly receiving a lot of traffic and it’s not clear whether it’s “good” traffic (e.g., you’re going viral somewhere) or “bad” traffic (someone is attacking you by flooding us with requests, or a bot has gone crazy). Using Honeycomb you can:
BREAK DOWNby the high-cardinality fields within the requests – user ID, IP address, and more – to quickly see if the sources originate from few or from many places using Honeycomb.
Having the raw data available is helpful in this case since you don’t need to know which IP addresses or user IDs to count ahead of time – only that those fields might be of interest to you later.
Honeycomb can help you figure out which specific customers are affected by (or even causing) a particular issue in production. This allows you to not only detect when something is wrong, but to rapidly deduce why and take steps to proactively mitigate its impact on the business, or even spot potential issues before they happen.
Honeycomb is able to do this because it was specifically designed and architected to handle “high-cardinality” data. High-cardinality data has a lot of distinct values (such as a customer ID, of which there could be thousands or millions), and many existing monitoring systems do not handle it well because trying to do so can create explosive complexity.
Example: A high priority customer writes in to let you know that they are very unhappy as some pages are loading so slowly that they cannot use them. Using Honeycomb you can:
BREAK DOWNby customer ID and URL with a calculation to quickly spot where in time, and on which page(s), the latency affected that particular customer.
Most engineers today would like to be more effective at debugging their code and understanding how it runs in production, but in practice the ability to do so remains concentrated in the hands of a few.
There are at least two major drivers for this:
At Honeycomb we want to eliminate these heartaches and democratize debugging.
Since Honeycomb’s architecture is based on an internal tool our founding members used at Facebook, Scuba, it is bringing the power of what was previously only available to engineers at big companies to the masses. In addition to passing along the power of this system, Honeycomb is simpler to use and more effective for teams. Honeycomb includes features such as:
Effective visibility shouldn’t be concentrated in the hands of the few. It should be available to your whole team!