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.
Ah, good question! TL;DR: store the start time of the span, and then create the span on the new page. Usually, you want to start a span, do some work, and then end the span. The whole span gets sent to your OpenTelemetry collector (and thence to Honeycomb) when you end it. But when a page load happens, that span object is lost. Honeycomb never hears about it becausespan.end()wasn’t called. How can we deal with this? Create the span only on the new page, where you can end it. But!
A long time ago, in a galaxy far, far away, I said a lot of inflammatory things about metrics. “Metrics are shit salad.” “Metrics are simply nerfed dimensions.” “Metrics suck,” “metrics are legacy,” “metrics and time series aggregates will fucking kneecap you.” I cannot tell a lie; Twitter will testify that I’ve spent the past six years ragging on metrics.
“What is up with the Context in OpenTelemetry? Why do I need to mess with it at all? Why, when I set a span as active, don’t subsequent spans just use it as a parent?” Oh, yikes, yeah. The Context abstraction in OpenTelemetry is hard to understand. Here are several ways it’s tricky.
At the time of writing this post, I have officially been at Honeycomb for one year as a site reliability engineer (SRE). I had shared my initial experiences and impressions in this post and thought it would make sense to check back in now that I’ve had the opportunity to spend time learning about the team, the culture, and the code base more in depth.
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.
