Errors Got You Down? Honeycomb and OpenTelemetry are Here to Help

It’s 5:00 pm on a Friday. You’re wrapping up work, ready to head into the weekend, when one of your high-value customers Slacks you that something’s not right. Requests to their service are randomly timing out and nobody can figure out what’s causing it, so they’re looking to your team for help. You sigh as you know it’s one of those all-hands-on-deck situations, so you dig out your phone and type the "going to miss dinner" text. The team places an order for takeout (a small perk of staying late: expensing dinner) and digs into what’s happening. 

Developer one: "Hey, application load metrics look ok, I don’t see what could be causing this."

Developer two: "Let’s see if I can dig into logs a bit. Wow, there’s a whole lot of these… this is gonna take hours to go through."

Developer three: "I think I found something! Oh, wait, nevermind…" 

The all-too-familiar endless cycle of deadends wears on the team as they try to piece together context from their sprawl of tools. 

It doesn’t have to be this way

You’re in the same situation, but in this timeline, your team ditched their traditional APM tools months ago, and incorporated Honeycomb with OpenTelementry (OTel) for in-depth observability. 

Developer one: "Hey, check this out, that can’t be normal." They Slack a permalink of their query. 

Developer two: "Oh interesting, bubble up on this spike here: what are the traces showing?" 

Developer three: "Damn, didn’t see that coming. Looks like a new feature was pushed live this morning and it introduced a new query on a large dataset without the proper indexes. Let’s roll it back and see if that fixes it."

In minutes, three developers that weren’t even involved in a small feature update isolated and debugged an issue impacting customers. That’s the unique power of instrumenting OTel with Honeycomb. 

Get the context you need

By instrumenting with OTel and analyzing this rich data with Honeycomb, engineering teams have the crucial context they need to find and fix issues in deeply complex and distributed cloud systems. In fact, most of the time, teams using Honeycomb are able to see and fix these issues while they are still small—and fix them before they become customer-noticeable. 

While many observability and monitoring solutions support OTel, we’re here to tell you why Honeycomb is most likely the right platform to maximize insights out of your OTel data.

Ignite OTel benefits with Honeycomb’s spark

Because we’ve been all in on OTel since the beginning, we can provide unparalleled support for teams looking to get actionable insights from the project. A few ways we specifically support OTel include: 

Import the data you need: Honeycomb can receive metrics from all OTel-supported languages including Go, java, and .NET, plus full support for importing and querying logs. 

Send your data easily: Honeycomb uses a technique called distributed tracing—and it’s what makes it such a great match for OTel. Tracing is the best approach for analyzing data as it yields insights into request paths, latency bottlenecks, and dependencies. 

Get more out of SDKS: Use native OpenTelemetry or use Honeycomb-specific SDK distributions for more instrumentation configuration options and automated, multi-span attributes. 

Fully documented guides: Honeycomb provides fully documented instrumentation guides for multiple languages to get you up and running with OpenTelemetry quickly and easily. 

Ready to maximize your telemetry data with Honeycomb?

The number of Honeycomb customers that use OTel jumped nearly tenfold in just a year. This includes teams like Vanguard, who shared:

 “We have hundreds of teams now using OpenTelemetry and Honeycomb. We’re able to bring a different mentality in the way we run and manage our production systems. We were able to really help our engineering teams and change the culture.”  – Rich Anakor, Chief Solutions Architect

Book a Honeycomb demo to see the magic of Honeycomb and OTel combined.