At Dynatrace Perform in Las Vegas, RedMonk’s Kelly Fitzpatrick explores the newly announced Observability for Developers solution. Dynatrace’s Sharon Sharlin and Michael Winkler explain how Observability for Developers is tailored to developers’ needs, offering real-time code-level insights via functionalities like a Live Debugger, without the need for code redeployment—a crucial advantage in troubleshooting complex cloud-native systems. Also included: a demo of the Live Debugger.

This was a RedMonk video, sponsored by Dynatrace.

Links

• Observability for Developers Launchpad accessed via the Dynatrace playground (public sandbox)
• Observability for Developers (blog post)
• Use Case description (blog post)
• Live Debugger (blog post)

Transcript

Kelly Fitzpatrick (00:00:03)
Hi there. This is Kelly Fitzpatrick with RedMonk here at Dynatrace Perform in Las Vegas. We are here on the expo floor. Now at Perform this morning at the keynote there was an announcement about Observability for Developers. Given that RedMonk is the developer focused analyst firm, we of course had to find out more. And for that, I have asked some of our Dynatrace experts to tell us about Observability for Developers. First off, I’m going to let them introduce themselves, Sharon and Michael, if you will.

Sharon Sharlin (00:00:33) 
Hi Kelly, I’m Sharon Sharlin, and I’m very happy to be here with you today. I’m the go to market lead for Observability for Developers. Previously, I was heading marketing in Rookout that got acquired by Dynatrace a while ago.

Michael Winkler (00:00:50)
Yes. And I’m Michael. I’m a senior principal in our product management responsible for go to market when it all comes to observability, including Observability for Developers.

Kelly Fitzpatrick (00:01:00)
Well, thank you again for answering some of my questions about Observability for Developers. But to start things off, when we think about observability, we don’t typically think about developers as the persona that observability serves. However, with all of this recent talk about observability shifting left, and with observability 2.0 offering better tooling for developers, I really have to ask: for Dynatrace, why are we talking about observability for developers now and then? What is Observability for Developers?

Michael Winkler (00:01:30)
Yes. Very good question. So I’ll take this. When we look at observability, it was very often about how you operate your code. So more answering the known unknowns, things that you could answer with a dashboard. And with shifting left, this is moving a little bit that we want to ask the unknown unknowns. We want to cover things that you don’t know beforehand. Right. It’s not as predictable. And as Dynatrace two and a half years ago already released Grail, our data lake house, and with Grail we have all data, unified observability and security data at the fingertips of our customers at all times. There is no rehydration required. There is no indexing required. This means that you can ask those unknown unknowns at any time. And on top of that, we have Davis AI, which helps with causal AI for root cause analysis, with predictive AI for forecasting. And on top of that, generative AI for this productivity boost that we need on a developer side as well. Right. And all of this together, what we have is a platform plus new and existing functionalities that we have now packaged together as Observability for Developers helps us.

Michael Winkler (00:02:45)
And Sharon, maybe you can add a little bit more color to the Observability for Developer package itself.

Sharon Sharlin (00:02:50)
Yes, definitely. So providing to developers is way more complex today. Cloud native everywhere, systems are getting more complex, bugs are getting more complex, and developers need observability that is set to their specific challenges. They need simple experience and they need actionable insight also from production, because the data they seek and need is not predictable. As Michael mentioned, it’s not something that we can track in dashboards and get alerts for. We need it in real time, down to the code level with things like value variables, debug level logs, stack trace. I can imagine a very beautiful and simple scenario where I can easily get into a snapshot I get from production, and I see a trace ID, I take it with me to a distributed tracing application and I continue the investigation. I need this code level information, and this leads me to a brand new Live Debugger application that we added to this package.

The package is designed to cater to the specific needs of developers, and it packages the existing Dynatrace capabilities that developers need on a regular basis: stuff like logs, distributed tracing, profiling, exception analysis. Those are more related to developers, and we added to that dynamic instrumentation capabilities with the Live Debugger, application, dev workflow, dev mindset to optimize all that for developer resources and tasks. The beauty of the Live Debugger is that it allows developers to gain the option to develop live applications from remote environments, and also from production environments. With a click of a button they set a non-breaking breakpoint that will not stop the application from running, and they get the debug data that they need in order to understand their code behavior. No need to add code, push for redeployment. All those cycles are gone. No need to recreate, reproduce, restarts: everything that developers used to deal with. Just imagine that those issues that you get pulled into an incident, into a production incident in the middle of the night, all this pressure of recreating, reproducing, done with that. Now, we don’t need to rely on data that we have decided to instrument in advance. We have real time capability from any remote environment that we need it from.

Kelly Fitzpatrick (00:05:49)
So I’m very excited about theLive Debugger. And for those of you at home who were not watching the keynote this morning, there was palpable excitement in the room when the Live Debugger was announced. Please tell me that we’re going to get a demo of the Live Debugger.

Sharon Sharlin (00:06:04)
Definitely.

Kelly Fitzpatrick (00:06:06)
So we’ll jump into it: what are we going to see?

Sharon Sharlin (00:06:09)
Yes. So a classic troubleshooting scenario would be that me as a developer, I get some kind of notification. It may be a JIRA ticket or an alert in my problem application, and I start an investigation. I see whatever Davis is prepared for me. I have logs I have tracing everything in the same card and in the same context of the service that I’m in charge of. As developers, we don’t care about everything. We care about what we are in charge of. So I start investigating and I see my logs, I see traces, and I see that it’s not enough. I’m missing information. When it’s missing information, I can easily press a button and be routed to the Live Debugger application. In there, I set a non-breaking breakpoint in the line of code in question. After I realize what service, what file I’m looking for. And in there, when the line of code is triggered, I will get a snapshot.

The snapshot contains this value variable stack trace processes, tracing information, everything I need in order to continue the investigation. And then you will see that under the tracing information, I found the trace ID that I need in order to continue my journey. I take it. I move directly to distributed tracing, and I continue to browse and seek for the reason that I’m here. I’m looking to remediate. And then, when I see the problem, I can go back, have my pull request and be done with this issue.

Kelly Fitzpatrick (00:08:01)
So I think that’s really good context for what we’re going to see. And without further ado, I think it is demo time.

Michael Winkler (00:08:09)
To demonstrate how easy it is to live debug in production, we use this very simple demo application that has a nasty little bug when trying to add credit card information. Once an SRE or operations hands over the issue, the developer is automatically informed–for example with a JIRA ticket including the link directly to the problem card–and we can start troubleshooting. Or it’s easy to get started even without the deep linking from tickets or developer portals like Backstage by using the predefined filters in the problems app, effectively only showing the issues relevant to this particular team. We immediately see we have a high failure rate of 100%, and as a developer, I’ll jump directly to my logs. We see a few error log lines and upon further analysis we will see we have an arithmetic exception: a division by zero which happens in our order controller on line 306. This already gives us enough information to start live debugging in production.

Michael Winkler (00:09:12)
Instead of wasting time in reproducing the issue, we set the non-breaking breakpoint in our Java file. In this case, we set it for all instances without further limiting. We could, however, set snapshots and breakpoints based on certain criteria and conditions. We immediately get the first input, the first snapshot covered. We have a look at the values and we see that in our case the great divider is zero, causing this arithmetic exception. From here we can easily fix the problem and push a new build. Now this was a very easy example. If further debugging would be required, we would see process information stack trace and trace information directly in the Live Debugger. It’s also easy to get further help and further access to developer tools through the problems card. Covering further performance analysis as well as profiling.

Kelly Fitzpatrick (00:10:18)
Thank you for that excellent demo. One question that I have that goes beyond developers is what does this technology and this solution mean for, say, platform teams or organizations that have like a central team?

Michael Winkler (00:10:32)
Yes. So, for a platform engineering team, we as Dynatrace had a lot of focus on platform health. So we had the software development life cycle events that we released. And based on that, we were instrumenting CI/CD pipelines. Right. But with observability for developers, we give platform engineers a tool into their hands that they can drive for self-service, for golden paths. Right. And with these golden paths, they can make Dynatrace more accessible to their main customers, their developers. And that’s happening either through the Dynatrace launchpad itself. So we have launch pads that can be used. On top of that, we have IDE plugins so a developer can set non-breaking breakpoints directly in their IDE. They don’t have to necessarily go to Dynatrace for that. And on top of that, we also have a Backstage plugin that also provides all the information relevant to developers in context with deep links into Dynatrace.

Kelly Fitzpatrick (00:11:28)
Cool. And I am especially excited about the IDE plugins because like the developers I know do not want to leave their IDE for for anything, especially go to another platform.

Well, we are about at time. We are going to put some links in the show notes. For those of you who want to learn more about Dynatrace Observability for Developers, but for now, I’d like to thank Sharon and Michael for speaking with me about this exciting announcement.

Michael Winkler (00:11:53)
Thanks a lot. Kelly.

Sharon Sharlin (00:11:54)
Thank you. Kelly.