As we recently discussed, many of us are still lost in the darkness, grasping for a log line to shed some light on the issue we are trying to troubleshoot. Many of our customers and colleagues have shared the following challenges with us: But what if we didn’t have to make such a choice? What if we could easily and efficiently switch on exactly the logs we needed, without hurting our application?

We have recently launched our disruptive Live Debugger on the Azure Marketplace, making it easier than ever before for teams on the Microsoft stack to slash the time they invest in debugging. We are excited about this, as we have been working closely with Microsoft to make sure that both large international enterprises as well as smaller and scaling startups have direct access to Rookout, to make the most out of our dynamic observability solutions.

One of the more challenging aspects of load testing happens very early on: getting your scripts working. When you run your scripts, you may observe unexpected error status codes (typically in the 4xx-5xx status code range). Other times, you'll run your script and see it receive the expected responses (usually HTTP 200), yet the "thing" your script is meant to create simply doesn't show up anywhere, like on the database or as a record on the site. You start wondering: why on earth is that?

To paraphrase a popular Chinese proverb: “It is better to light a log line than to curse the darkness”. And yet it’s 2021, and many of us are still lost in the dark, struggling to find a match, praying for that one missing log line that would have pointed us in the right direction. How did things get this bad? Since time immemorial, we have relied on logging as the first trustworthy, intuitive, and straightforward debugging method.

The rise in digital transformation over the past few years means that more and more companies are adopting cloud native technologies. While these distributed architectures provide scalability and agility, they also increase complexity. As Arnal Dayaratna, research director in software development for IDC, writes, “One of the challenges faced by contemporary developers is the task of understanding applications that they may not have even developed or used .”

Imagine that you’re at your company’s all-hands meeting and one of the sellers is proudly ringing the office gong to celebrate closing a big deal with a client who’s on the other side of the world. It’s a big deal because it’s a major project. Their logo is going to look sleek on your website, and you are finally breaking into a new region of the world. But two months after the project kicks off, the situation isn’t looking as rosy.

When designing and building software, service reliability is always at the top of the list of critical focus areas for development teams. Every team that builds software typically has, either directly or indirectly, service level agreements with their customers. These are, essentially, agreed-upon metrics or performance criteria that teams use to measure and ensure the reliability of a software system.