Before continuous integration came to be, setting up builds was no fun because the complexity and overhead involved in a release cycle was compounded by inflexible, manual processes. The release cycle was slow and often resulted in breaking changes. Continuous integration and continuous delivery (CI/CD) has changed much of that through pipelines that automate how we build and test software—today, we can deploy, have builds fail, and resolve any errors faster than ever.

OpenTelemetry is a strong standard for instrumentation because it is built of careful, well-thought-out abstractions created by experts in the space. OpenTelemetry feels painful to start using because it’s full of abstractions that make sense to experts in the space. For a developer who wants to think about their own software and not spend a month becoming an expert in telemetry, this is hard. For high-level conceptual description, there’s the OpenTelemetry specification.

In my last blog post, I talked about the cadence of product planning and delivery at Honeycomb. Tucked away in there was a mention of “demo day”—and I’m back to tell you all about that because it’s a pretty big deal around here, and I want to encourage you to give it a try as a way to see progress on new feature development and get folks excited about what’s on the horizon.

Yes! While data is data (and tools exist on a continuum, and can and often are reused or repurposed to answer questions outside their natural domain), observability and BI/data warehouses typically exist on opposite ends of the spectrum in terms of time, speed, and accuracy, among others.

Ever wonder how your teammates go about debugging? When you use Honeycomb, you’re not only getting observability into your systems; it also provides observability into how your teammates use Honeycomb! Very meta, no? You’re never alone when writing or running Honeycomb queries. Opening up the right sidebar will show you the queries your teammates have recently run on the same dataset.

Should we build and run the full observability stack in pre-prod? How much realism vs. waiting for prod? Answer: Yes. You absolutely want observability in pre-production environments—local, dev, performance test, staging, CI, everywhere.

With more than 1.5M room nights booked per day, Booking.com requires a solid infrastructure that’s constantly monitored. And indeed, Booking.com now has a footprint of 50,000+ physical servers running across four data centers and six additional points of presence. The sheer size of this server fleet makes it viable for Booking.com to have dedicated teams specializing into looking only at the reliability of those servers.

You need not fear a long-lived streaming workload. A few simple tricks can transform a request that may not ever terminate for hours or days into something you can get regular health and status updates on. We in fact have one of those continuous processing services—Beagle, our Service Level Objective stream processor—which we’ve instrumented in this fashion.

We know that you value collaboration. That’s why we share incident reviews and learnings—because we believe the entire community benefits by working together transparently. In the spirit of working better together, we invited ecosystem partners from ApolloGraph, Cloudflare, LaunchDarkly, and PagerDuty to present at Honeycomb Developer Week, a three-day event filled with snackable, time-efficient learning sessions to help you uplevel your observability skills.

TL;DR: Use auto-instrumentation from OpenTelemetry. Traces will happen. Then your code can use global library functions to customize those traces with your specific important data.