With Honeycomb and a bit of technical flash, you can observe almost anything - and we offer a new way of asking questions about what’s actually happening in your apps to help you solve issues in a jiffy.
While you can push all types of data to Honeycomb, it helps to get your head around the mental model of one event per unit of work to learn how you can get to the promised land of observability for HTTP, Lambdas, background jobs or whatever else you might like to observe.
At Honeycomb HQ we describe events in all kinds of abstract ways like “it’s something happening worth tracking”, but at the end of the day, it’s simply a JSON object that you POST to our API.
Events get ingested into our wicked fast storage engine for later querying. No need to define schemas or indexes ahead of time. It’s just that fast out of the box.
One of the most common Honeycomb use cases is to send one event for each HTTP or RPC request in your system. You might even have several services (e.g., A, B, and C) that are touched in the lifecycle of serving what is one request to the end user, and they all send events to Honeycomb.
You can then do all sorts of queries within Honeycomb to answer any question under the sun. For instance, you could group by error code or error message to spot common or recently occurring problems fast. You could SUM time spent on certain MySQL queries to identify if there are not just slow queries, but queries that are running too often.
Not only that, but this model allows you to take advantage of the power of a very exciting new trend: distributed tracing.
If you set events to have the proper fields, you can visualize a full waterfall of how a given request flows through the system. Spotting slow services and sections of code has never been easier.
Some Honeycomb integrations such as Beelines even add this data automatically!
You’re not limited only to requests and ongoing processes either.
You could instrument your background jobs too to gain insight into those pesky and finicky old things. Processing N object files every time the job is run? Send N events and get ready to understand your systems better than ever.
Same thing with Lambda - as we’re moving to a changing world, it’s more important than ever to crack open the black boxes we’re using and send data from within them. One Lambda invocation could easily send a Honeycomb event either using our bindings for that language or via Cloudwatch + Agentless Integrations.
Our Beelines understand the standard packages you’re using, then instrument them to send useful events to Honeycomb. There’s no custom instrumentation required to generate basic events but with a little optional configuration, you can include your own fields too.
Our Examples repository contains a wide range of instrumented sample applications that illustrate how to generate custom events and send them to Honeycomb.