Operations | Monitoring | ITSM | DevOps | Cloud

Today’s systems are more distributed, dynamic, and complex than ever before – plus, users have more expectations. Also, the historical reliance on an operations team to monitor, triage, and/or resolve issues has become untenable as the number of services increased. This means that many of the tools that were well-suited before might no longer be adequate.

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.

Unlike traditional IT Ops, the role of the SRE isn’t simply focused on finding and solving technical problems. The big win for today’s SREs is supporting the organization’s strategic innovation initiatives. With the appropriate observability capabilities, it’s possible to quantify the value that software infrastructure contributes to this innovation effort.

What’s the first thing most people do when they’re unhappy with a business? Take to social media to complain about it. Observing those comments – otherwise known as “user sentiment observability” – gives you a head’s up as to when problems become big enough to impact user experience. How can you monitor that voice of the customer? And why is it important to do so? Let’s take a deeper look at the issues.

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.

Every few years, the tech world either rebrands an old term or tries to find a way to use old technology to create new advancements. This rabbit hole is easy to fall into with observability, yet it is distinct from some of its predecessors.

When we talk about observability, we tend to focus first and foremost on the metrics, logs, and traces that you can collect from applications – such as request rates, error rates, and request duration. Infrastructure-level metrics, like CPU and memory utilization, might factor into the discussion as well. Here’s a third category of critical observability insights that teams tend to overlook: the network.