Operations | Monitoring | ITSM | DevOps | Cloud

As a software engineer, I’m always evaluating tools and technologies that can optimize my workflow. Developer productivity isn’t just about writing more code—it’s about reducing friction, whether that’s context-switching, making repetitive edits, or understanding unfamiliar parts of a codebase. That’s where GitHub Copilot comes in: making tasks that once felt monotonous or time-consuming into faster, more intuitive processes.

The Collector is one of many tools that the OpenTelemetry project provides end users to use in their observability journey. It is a powerful mechanism that can help you collect telemetry in your infrastructure and it is a key component of a telemetry pipeline. The Collector helps you better understand what your systems are doing—but who watches the Collector? Let’s look at how we can understand the Collector by looking at all the signals it’s emitting.

This post was written by Martin Thwaites and Vivian Lobo. The OpenTelemetry Collector is an exceptional solution for proxying and enhancing telemetry, but it’s also great for generating telemetry from machines too. In this post, we’ll go through a basic, opinionated setup of using the OpenTelemetry Collector to extract metrics and logs from a Windows server.

Logs are more than just records. With proper log monitoring, they become the honey that sweetens observability. Observability is your ability to understand and optimize your system’s behavior. Turning raw logs into actionable insights requires the right tools, practices, and insights. This blog post is a guide on log monitoring key concepts and best practices for sweetening your observability.

You may have wrestled with a web application attempting to call an offsite web service, such as an OpenTelemetry Collector, and gotten an odd error with the word CORS in it. Something like: Or, maybe you got a generic thrown error from your fetch statement that states Error: Failed to fetch …and you wondered, “What’s the problem, and how can I fix it?” These kinds of errors are called CORS errors, and they can be a bit confusing.

Another one in the history books: 2024 is (almost!) over. The OpenObservability Talks podcast, hosted by Dotan Horovits, recently featured a lively discussion with Charity Majors, Co-founder and CTO of Honeycomb, to reflect on the trends, achievements, and future of observability.

Space.com sums up the Big Bang as our universe starting “with an infinitely hot and dense single point that inflated and stretched—first at unimaginable speeds, and then at a more measurable rate to the still-expanding cosmos that we know today,” and that’s kind of how I like to think about November 2022 for junior developers.

Have you ever had an alert go off that you immediately ignore? It’s a nuisance alert—not actionable—but you keep it around just in case. Or maybe you’ve looked at a trace waterfall and wondered what exactly happened during a gap that just doesn’t drill down deep enough to explain what’s going on. Do you know the feeling where you have just enough information to monitor what’s going on in your systems, but not quite enough to put your mind at ease?

This post was written by Charity Majors and Phillip Carter. In May of 2023, we released the Honeycomb Query Assistant, an LLM-backed feature that lets engineers use natural language to generate and execute queries against their telemetry data. Instead of having to master a domain-specific query language, you can simply type in things like “slow endpoints by status code” and the Query Assistant will generate a relevant Honeycomb query for you to iterate on.

Refinery is a powerful tail-based sampler—but with great power comes great challenges. We heard your feedback and are excited to announce the release of Refinery 2.9, a rather large update that is packed with goodies to make your life easier when running Refinery in your network.