By Shahr Fogel, CEO at Rookout, winner of Best Product for Web or App Development at 2022 SaaS Awards

Over the past five years, we’ve seen the rise of observability tools. The previous generation of established monitoring tools were great for just that – monitoring issues that engineers could predict in advance and alert on. But what if you needed to ask your system real-time questions about problems you didn’t expect? This is where companies, like Honeycomb, really pioneered the next generation of observability tooling, as well as companies like Lightstep making Change Intelligence and on-the-fly root cause analysis a real thing.

However, much of the information and visualizations supplied by these systems are still geared for DevOps and SRE personas rather than developers.

In other words, we at Rookout feel that DevOps has to shift farther to the left in order to cater to what developers truly care about. Traditional observability players aren’t going away, just as traditional monitoring players like Datadog are still important in today’s contemporary systems, but it doesn’t change the fact that there is a market gap: observability for developers.

Code-level insights of observability

The problem with traditional observability tools is that they are hyper-focused on infrastructure-level metrics, whereas developers care more about code-level insights into their applications. With developer-first observability, the idea is to enable developers to extract data from any code – including production – on the fly, without having to write new code or redeploy the application.

So, in contrast to traditional observability, which collects metrics, logs, and traces in a central location and then requires new code each time a new issue develops… These modifications may happen in real time because to dynamic instrumentation, which also gives developers access to production, where actual customers live.

We’ve seen customers struggle to reproduce issues locally when it’s very difficult to recreate a copy of a remote environment while simulating the scale, complexity, network conditions, and data state in the live app, which is something that every developer does more frequently than staring at monitoring dashboards.

Managing code version changes, configuration changes, variable state, stack trace, and other data points that need to be thrown together to make sense out of the application behavior is a serious undertaking. Fetching log lines, debug snapshots, error messages, and traces from a running app, shipping the data into a centralized pipeline, and creating the relevant dashboards and alerts on top of the collected insight requires a specialized set of tools and skills.

All of this data warrants its own set of dashboards, tailored for the developer experience. In other words, the ability to dynamically generate new log lines and debug snapshots has created a new need for what we like to call a visual debugging experience.

Developer-First Observability at Rookout

We want to help software engineers make sense out of the growing complexity of debugging cloud-native applications. By visualizing the state, scale, and clustering of the application, as well as allowing our users to slice and dice and prioritize problematic clusters and pods with the click of a button, we aim to make the cloud debugging experience something that is as easy and intuitive as, well, local debugging of a single app running on your desktop.

 

Another example of observability shifting left is our integration with the OpenTelemetry project. We are able to ingest tracing data from the OTel collector, and then with Rookout’s Tracing Timeline enrich the debug session with transaction information over a time dimension graph. By viewing debug snapshots side by side with the application’s tracing information, developers get a holistic view that empowers the debugging and troubleshooting experience and allows developers to get knowledgeable decisions.

Developers simply add a breakpoint next to the line of code they wish to trace, then trigger the breakpoint and make sure snapshots were received. They can then view the Tracing Timeline graph which will present spans and context of all the transactions made within this code section.

Tracing Timeline in Rookout

Read More

The “today” of observability

Being able to get real-time feedback is increasingly important for software development teams as the demand from the business and customers to fix issues fast is as critical as ever.

With traditional observability tools, when you want to have access to a specific metric, trace, or other piece of information about your application it often requires you to make a new configuration change, code change, or even a redeployment of your application. If you couple this requirement with enterprise release management practices where environments are more heavily regulated and often require one or more approval gates, this can dramatically slow down the debugging process.

Gone are the days where taking weeks or months to solve issues is acceptable. With all of the options available today to consumers, they have higher expectations for the services they use. Having the ability to gather deeper observibility data directly from the environment where the issue is occurring and where it’s easiest to reproduce is a huge time saver. Teams that can capitalize on developer-first observability will have a leg up on the competition of getting to the root cause of issues faster.

The goal of every development team should be to have the ability to gather any data point within their application in real-time and on-demand.

Cloud native applications are producing more data than ever, and far too often much of that data isn’t accessible to developers who need deeper insight in order to solve defects in their code. If a developer wants to know the value of a variable in their code, for example, and they don’t yet have a log line or a metric that gives them insight into that data, they should be able to collect that information as it’s needed without having to make a change to their code and without having to redeploy their application or service.

Developer-first observability tools make this a reality and give developers the ability to have a deeper understanding of their code and how it executes.