When Google Cloud welcomed StackState to offer our full-stack observability solution to their network of customers, we were thrilled. Our excitement only grew when Google invited us to join other partners this week at Google Cloud Next ’24 at the Mandalay Bay Convention Center in Las Vegas.

As a manager, figuring out how to talk to your engineering teams about building a strong observability strategy can feel overwhelming. But don't worry! This post will help you navigate the challenges to unlock the full power of observability in your IT environment. Drawing on insights from over 40 discussions with larger enterprises, we've put together a strategy assessment that examines three key focus areas — what we’re calling aspects — each encompassing three actionable steps.

StackState had a blast at this year's KubeCon + CloudNativeCon gathering in Paris! The discussions were in-depth, covering a wide array of topics and lasting much longer than in the past. This year, attendees seemed to have a considerably deeper understanding of the cloud-native ecosystem, probably attributed to its rapid growth. We also noticed a pretty dramatic evolutionary shift in the vendors at the expo hall, who were showcasing some truly progressive specialized solutions.

In one of our latest posts, StackState Co-Founder Mark Bakker described how eBPF revolutionizes observability and how StackState’s agents rely heavily on eBPF to capture and analyze the data moving through your cluster. Today, we’re looking at an example where our eBPF code failed and — by diving deep into the intricacies of eBPF implementation in the Linux kernel — share the tale of how we fixed it using even more eBPF.

In the complex and fast-paced world of application deployment, getting a handle on the tangle of services and resources can sometimes feel like trying to find your way through a maze without a map. And if something goes wrong, trying to find out what's happening where is even more difficult. With alert emails flooding in and questions flying left and right, identifying the glitch that's causing issues can seem like a Herculean feat.

A few days ago, I challenged myself: Could I create a CPU throttling monitor without using StackState's docs page? I'll go a bit deeper into CPU throttling later, but first: Why this mission? At StackState, we believe that every software developer should be able to observe the health and reliability of their own application — quickly and easily.

Many companies are using cloud technologies to become more agile, scalable, and cost-effective during their digital transformation. However, this change brings new challenges in maintaining the security and performance of applications and infrastructure in the cloud. Security and observability go hand-in-hand.

Whether you're a system administrator, a developer, or any other DevOps or Site Reliability Engineering (SRE) professional, you know that staying ahead in cloud-native computing is crucial. One way to keep your competitive edge in the technology game is to embrace the benefits of eBPF (Extended Berkeley Packet Filter). On top of advances in security and networking, eBPF-based tools are particularly impacting the observability landscape.

No one wants to get an alert in the middle of the night. No one wants their Slack flooded to the point of opting out from channels. And indeed, no one wants an urgent alert to be ignored, spiraling into an outage. Getting the right alert to the right person through the right channel — with the goal of initiating immediate action — is the last mile of observability.

Imagine a symphony where every musician plays their part flawlessly, but without a conductor to guide the orchestra, the result is just a discordant mess. Now apply that image to the modern IT landscape, where development and operations teams work with remarkable autonomy, each expertly playing their part. Agile methodologies and DevOps practices have empowered teams to build and manage their services independently, resulting in an environment that accelerates innovation and development.