We’ve made some big changes under the hood at Honeycomb to give you better control over how you put your apps data to work—we’ve expanded our core data model with formal Environments and Services! In short, the best observability (o11y) platform in town just got better! Before we dig in, an important note. Existing Honeycomb teams are not impacted by this update. If you’re already a Honeycomb user, congratulations! Your team is now a Honeycomb Classic team.

Observability came out of microservices and cloud-native, right? If you have a simpler architecture, does o11y matter?” — this question came up during recent office hours Yeah, sort of. On both counts—yeah, it sorta came out of microservices and cloud native, and yeah sorta, you need it with a simpler architecture (though perhaps not as desperately as you otherwise might).

Today, the Honeycomb OpenTelemetry Distribution for Java reaches a major milestone with a 1.0 release. This is the first Honeycomb OTel Distro to come out of beta and go into the general release category, and you can expect more to come!

TL;DR: startSpan is easier and measures a duration. Use it if your work won’t create any subspans. startActiveSpan requires that you pass a callback for the work in the span, and then any spans created during that work will be children of this active span. I’m instrumenting a Node.js app with OpenTelemetry, and adding some custom instrumentation. For this important activity that I’m doing (let’s call it “retrieve number”), I’m creating a custom span.

Previously announced as a community-led project, the Terraform provider for Honeycomb is now officially maintained by Honeycomb in partnership with Hashicorp. We recognize how valuable supporting configuration as code is for our customers, and this change in ownership affirms our commitment to ensuring your ability to quickly make the most of Honeycomb’s Management API.

Dashboards are one of the most basic and popular tools software engineers use to operate their systems. In this post, I'll make the argument that their use is unfortunately too widespread, and that the reflex we have to use and rely on them tends to drown out better, more adapted approaches, particularly in the context of incidents.

Ah, I too have wondered about this. TL;DR: The Resource says what program is sending these spans and where it’s running. You can skip it if you define OTEL_SERVICE_NAME in the environment. When I’m setting up tracing (for instance, in a Node.js app), I have to create a Resource object in order to set up the OpenTelemetry SDK: If I don’t define that resource parameter, then tracing will still work. But my spans will show up with aservice.name of unknown_service:node.

The promise of OpenTelemetry is that it can help you avoid vendor lock-in by allowing you to instrument your applications once, then send that data to any backend of your choice. This post shows you exactly how to do that with code samples that configure your application to send telemetry data to both Honeycomb and New Relic.