We use cookies or similar technologies to personalize your online experience and tailor marketing to you. Many of our product features require cookies to function properly. Your use of this site and online product constitutes your consent to these personalization technologies. Read our Privacy Policy to find out more.

X

About instrumentation


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.

What’s an Event?

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.

Example of a JSON event

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.

Requests and Tracing

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.

Example execution lifecycle

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.

Example trace

Some Honeycomb integrations such as Beelines even add this data automatically!

Batch Jobs and Serverless

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.

Execution flow of a batch job

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.

Example serverless flow execution

Here are some ways to get started:

Honeycomb Beelines and SDKs

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.

We have Honeycomb Beelines for Node.js, Go, Ruby, and Python.

Or, you can use one of our SDKs to add instrumentation to your app: we have SDKs for Go, JavaScript, Python, Ruby, and Java.

Example applications

Our Examples repository contains a wide range of instrumented sample applications that illustrate how to generate custom events and send them to Honeycomb.