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.


About instrumentation

Observability for modern distributed infrastructure is deeply-rooted in instrumentation. A well-instrumented system provides all the data needed to determine what’s happening inside it, and we should all aim to ship well-instrumented systems. That said, it is worth the effort to do even a basic job of instrumenting your code. Starting at the edge and just collecting timing information will give you much more insight into where to start looking for the source of a problem than you had before.

Here are some best practices for observability, most cribbed directly from this blog post: Best Practices for Observability.

Here are some ways to get started:

Instrumentation Patterns

The high-level instrumentation advice given above can be broken down into a number of different instrumentation patterns, depending on the architecture of the software being instrumented. Check out our recommendations for a number of common patterns listed below:

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.