As systems get ever more complicated with more layers in the application stack, it can become more difficult to keep track of what is happening at all of the different, discrete levels and this is where distributed tracing comes into play.

When do you delete instrumentation? You delete instrumentation when you delete code. Other than that, if you’re doing things right: almost never. One of the best things about honeycomb is that it completely transforms the incentives around preserving instrumentation. With metrics-based tools, the most valuable metrics are always custom metrics. You need to define a custom metric for literally any question you might ever want to ask about the app and its utilization or performance.

We’re excited to announce that we’ve recently contributed Redis monitoring support to the OpenTelemetry collector. You can check it out here! You can utilize this receiver in conjunction with any OTel collector: including the contrib collector, the observIQ’s distribution of the collector, as well as Google’s Ops Agent, as a few examples.

Spring Boot is a very popular microservice framework that significantly simplifies web application development by providing Java developers with a platform to get started with an auto-configurable, production-grade Spring application. In this blog, we will walk through detailed steps on how you can observe a Spring Boot application, by instrumenting it with Prometheus and OpenTelementry and by collecting and correlating logs, metrics, and traces from the application in Grafana Cloud.

The management of modern software environments hinges on the three so-called “pillars of observability”: logs, metrics and traces. Each of these data sources provides crucial visibility into applications and the infrastructure hosting them. For many IT operations and site reliability engineering (SRE) teams, two of these pillars — logs and metrics — are familiar enough.

Miss O11y is delighted to welcome our newest band member: Martin Thwaites! Martin has been a member of the Honeycomb user community practically since its inception. He is a UK-based consultant who specializes in helping teams scale up and tackle challenging business problems, and a long-time contributor to the Azure and.NET communities. We think he looks ✨amazing✨ in a tiara.

OpenTelemetry has been getting a lot of attention in the observability field. Moreover, in StackState’s latest release, we added support for OpenTelemetry traces. Melcom van Eeden, software developer at StackState, was one of our developer champions who made this possible. In addition to joining us on this episode of StackPod, he wrote a blog post on how to leverage OpenTelemetry with StackState and he recorded a tutorial video about the topic.

Ah, good question! TL;DR: Trace instead of log. Traces show connection, performance, concurrency, and causality. Logs are the original observability, right? Back in the day, I did all my debugging with `printf.` Sometimes I still write `console.log(“JESS WAS HERE”)` to see that my code ran. That’s instrumentation, technically. What if I emitted a “JESS WAS HERE” span instead? What’s so great about a span in a trace? Yeah, and so do logs in any decent framework.

Your applications most likely consist of multiple components. These components could be written in different languages, with each individually instrumented with Sentry’s SDK. The goal of our tracing solution is to make sure developers get a full picture of the data captured within their tech stack. Tracing allows you to follow a request from the frontend all the way to your backend application and back.