Application Performance Monitors (APMs) such as Azure Application Insights have become standard tools that enterprises use to monitor and maintain the health of their production systems. When something happens in production, they can point you in the direction of a fix, but they can only go so far. To do effective remote debugging on Azure, you need a Production Debugger that can show you the error execution flow, so you do a code-level analysis and determine the root cause of a bug. In this blog post, I’m going to show you how Ozcode Production Debugger works in harmony with APMs by debugging a production error together with Azure Application Insights. Along the way, I’ll show also show you how easy it is to get Ozcode up and running alongside your Azure App Service.
|This post is based on our webinar, “How to reproduce production bugs with Applications Insights and Ozcode.” The full webinar recording is available at the end of this post and on our YouTube channel.|
Here’s what we’re going to do:
- We have .NET Core application set up as an Azure App Service, an eCommerce site that sells cool .NET swag. We’ve built a couple of bugs built into the app.
- I’ll enable Azure Application Insights to monitor our application
- I’ll then trigger one of the bugs and see how far Application Insights can take us with debugging
- Next, I’ll connect Ozcode Production Debugger and trigger the bug again to show you how much further Ozcode can take you with Azure remote debugging.
And if you watch the webinar, you’ll also see what Ozcode does about protecting PII so you can debug in production while complying with privacy regulations.
Setting the stage with Application Insights
Here’s what our eCommerce demo site looks like:
Let’s look at it through the Azure Portal and enable Application Insights to monitor it.
It’s a breeze.
Once Application Insights is enabled, we start seeing a variety of metrics that provide insights into our application’s state. The Live Metrics view shows me things as they’re happening, like the number of requests, their duration, and other cool stuff.
Now let’s see what happens when you get an exception.
We’ve built a bug into our webshop so that if you update the quantity of an item you have selected to zero, you’ll get an exception. Watch.
Now, when we go back to Application Insights, we can see that an exception was thrown, and even the type of exception and the corresponding stack trace. So, in addition to being an APM, Application Insights also provides some error monitoring capabilities.
I can even go into Application Insights’ Failures tab that gives me an aggregate view showing the number of exceptions, their HTTP route, and more.
Pretty cool, right?
But what now?
How does that help me debug the exceptions?
The usual route would be to guess where the problem is, add more logs, redeploy and try to reproduce the error – what we call here at Ozcode, “printf debugging,” but that’s not very effective.
While APMs, like Application Insights, do a great job of monitoring your system for different performance bottlenecks, they don’t give you the code-level visibility that you’re used to getting in your development IDE. Ozcode Production Debugger is the tool that takes the reigns from your APM when you need to dig deep to understand the root cause of an error. And it’s so simple to get started.
Installing Ozcode Production Debugger in minutes
Once you’ve created and signed into your account on Ozcode Production Debugger, what you want to do is install the Ozcode agent alongside your application.
You create an application on Ozcode
Select your deployment type (in this case, we’re on Azure, Windows, and Azure App Service). Ozcode provides the corresponding installation instructions along with a unique token.
Copy the token that Ozcode Production Debugger creates for you. You’ll need that for your Azure App Service configuration.
Then, in the Azure portal:
Select your application
Install Ozcode as a site extension (Tip – just search for “Oz” in your browser to find the Ozcode extension easily)
Remember that token you copied when you created your App in the Ozcode server? Now’s the time to configure it into your Application Settings on Azure. The installation instructions you got on Ozcode tell you exactly what key to use. This takes less than a minute. Watch.
That’s it; the Ozcode agent is now ready to capture exceptions autonomously in our app.
|Can I run Ozcode on other platforms?|
|Yes, you can use Ozcode Production Debugger on any platform that supports .NET, including IIS, on a desktop, or in a Docker container. Both .NET Framework and .NET Core are supported. You can even run it on AWS. For full details, check out Supported Platforms in our documentation.|
Ozcode plays nicely with APMs
Just like other popular APMs such as New Relic, App Dynamics, and Dynatrace, Azure Application Insights monitors your application by adding instrumentation to your code. That’s exactly what the Ozcode agent does to enable time-travel debugging when exceptions are thrown. But here’s the interesting thing to note. To enable working side-by-side with your APM, Ozcode’s lightweight instrumentation uses a multiplexing technique to ensure it doesn’t interfere with your APMs instrumentation. And again, the fundamental difference between these tools is that the APMs do a great job of monitoring and reporting about a variety of metrics related to performance. These metrics enable you to tweak your applications to be the best they can be. In the case of errors and exceptions, the APMs point you in the general direction of the problem while the Ozcode Production Debugger leads you to the root cause by providing code-level debug information. Both of these functions are critical to keep your application healthy and performing optimally. You just need to be aware and use each for the function it’s best at.
Time to start debugging
At the beginning of this post, we saw what Application Insights gives you when an exception is thrown. Now that we’ve installed the Ozcode agent, let’s see what effective production debugging looks like.
If we now go back and reproduce that exception (by updating the quantity of a selected item to zero), it’s reported in the Ozcode dashboard.
At this point, we can see that an exception was thrown, and can even see the stack trace, but we don’t see any code, and can’t debug the exception yet. This is because the first time an exception is thrown is when Ozcode adds its instrumentation to your code.
|Should I worry about one-off exceptions?|
|No, you shouldn’t. The scale of a fully-fledged commercial application makes it very uncommon for an exception to be thrown only once in production environments. And if the exception is rare, the instrumentation is there, and next time the error occurs, Ozcode ensures you’re ready to debug it.|
The second time the exception is thrown is when the magic happens. The Ozcode agent records the complete code execution flow of the error along with full-fidelity time-travel debug information to let you step back in time through each line of code. Now you can see the call stack, step through the code, and see all variable values at every step along the way. Colored highlights show you which conditional parts of the code evaluated to true and were executed, and which were skipped over. You can even collaborate with colleagues who can use point-in-time links to direct you straight to the problem.
That’s it. Within minutes, I connected both Azure Application Insights and the Ozcode agent to my application, giving me both performance monitoring and Azure remote debugging capabilities. The full webinar recording is just below, there you can also see how Ozcode redacts personal information so that you can continue debugging in production while complying with privacy regulations.