Building Your Observability Practice with Tools that Co-exist

In the world of metrics, monitoring, APM, tracing, and related tools for debugging and troubleshooting, many vendors focus on what makes their product different and better, and why it is the only thing a customer should use. We’ve certainly done some of that–we believe that Honeycomb is by far the best tool on the market for digging into gnarly bugs that require the ability to query and break down by the most granular data field (aka high-cardinality values)–but what we sometimes fail to point out is that Honeycomb is not just for when all your other tools have failed you.

Not only that, but Honeycomb is perfect to use alongside the things you’re already using to develop, deliver, and operate your service. If you’ve been in business for any amount of time, you’ve already made choices–choices about what data you’re collecting, how you’re collecting it, where you’re sending it, how you’re visualizing it–and you’ve no doubt put work into making these tools serve your needs. And although Honeycomb can achieve a lot of what you are doing with the tools you’ve got in-house already, you don’t need to use every feature and capability of Honeycomb to get your money’s worth.

To put it another way, the goal is to augment and expand your ability to deliver your service and improve your bottom line, not require you to rip out the tooling your organization has depended on up to now. You can benefit from using Honeycomb alongside what’s been working for you until now.

The reality is that team, skills, and cultural transformation for DevOps is hard and takes time. As your organization evolves toward service ownership and a practice of observability-driven development, you’ll require a different set of tools and processes, and this kind of transformation doesn’t occur between one deploy and the next. While you develop and improve your observability practice, Honeycomb coexists as part of the ecosystem of tools that bring value to your business.