How to troubleshoot Azure Web Apps

In traditional scenarios, you develop a web application (e.g. with ASP.NET) and host it in IIS on a (virtual) server in your datacenter or the server room a couple doors down. Over the years, we have become spoiled with the notion that we can rely on the physical machine on which our applications and services run. For instance; often we still assume that we can get to the file system or that session information will stay in the memory of the server.

When you develop a Web App and host in in Azure, the story changes. The basic idea behind a Web App is that we consume the hosting as a service, which is geographically scalable, redundant and secure. In practice, this means that we no longer have a 1-on-1 relationship between the application and the server. The Web App is hosted on 1 or multiple servers. Or the Web App is running on a shared server, together with application of other Azure customers. The magical Azure abstraction layer (Azure Service Fabric) makes sure that the Web App keeps running. When a server fails, Azure provisions a new one. When the application requires more performance, Azure will provide more server power by running more instance of your application and routing traffic through a load-balancer. In short, you can no longer assume anything about the server on which your Web App runs. You can no longer assume to be able to access the file system of the server as you could be moved to a new server at any point in time. The same goes for other resources, like the server memory.

This requires a new way of working. Your Web App should assume that resources like the file system and server memory are not (always) available. This is something you should already have been doing in your applications (I’m sure you have), but by hosting in Azure, this aspect becomes more visible as resources change more often (server gets added, changed, removed). You should also either work stateless or manage your application state differently. You have to assume that multiple instances of your Web App could be running and that traffic is distributed to these instances by a load-balancer. This means that you can’t keep the state of your application in the memory of just one server, as the state would than not be available on other instances where your user might end up on through the load-balancer.

Troubleshooting of a Web App is also different from troubleshooting an application hosted in a traditional datacenter. This is mainly due to the fact that you cannot log on to the server (through RDP) on which your application is running. Because of this, you can’t view your server log files and use other traditional troubleshooting techniques. This can be difficult if your are having trouble with your application.

I started early on with software development in the Azure Cloud. To me, it’s all about giving away some control to gain the benefits of using capabilities out-of-the-box. Nowadays, I really like developing for the cloud. However, a few years back, Azure was on a completely different level of maturity than it is now. This caused a lot of my customers to not yet get into Azure, often because the loss of control seemed too large to them. A lot of times this came down to the fact that support employees would not have enough tools to troubleshoot the application. A lot has improved in this area

So what are your options after you publish to Azure for the first time and face a weird error message? How can you then get to the bottom of the error and fix it?In this blog post, I’ll show you a couple ways of how to do this and make your manager happy. As always in the world of Microsoft,there are many ways to accomplish the same thing. Therefore, I will restrict this blog post to the following topics:

* Remote debugging

* Log file analysis

* The Azure App Service Support portal

* The Kudu website

* Application insights.

To enable remote debugging, you need to change the settings of your Web App. Please note: you need Visual Studio 2015, 2013 or 2012 with update 4 and you have to have the Azure SDK installed on your machine, which you can get here. Also, remote debugging does not work with Community Editions of Visual Studio.

Switch Remote Debugging to On en select the Visual Studio version that you are going to use. Don’t forget to click Save. You can also change these settings from the Server Explorer Window in Visual Studio.

Next you can attach the debugger by selecting Attach Debugger from the context menu of your Web App, like in illustration 3.

Things to note on remote debugging:

• Remote debugging only works when you have a debug version of your application deployed
• After 48 hours, remote debugging will shut itself off (for performance and security reasons)
• Remote debugging in production is not a good idea, because:

  - You need to publish a debug version of your app. This is not good for your application performance
  - When you hit a breakpoint, your application stops and users might be waiting on you to step through the code
  - Remote debugging in production is possible by using IntelliTrace, which currently is only available for Visual Studio Ultimate Users. As of July 20, 2015, this will also be available for Visual Studio 2015 Enterprise edition users

Remote debugging is a good idea for development and test scenarios.

Debugging can only get you so far. It can’t help you if your application doesn’t even get to a point where you can set breakpoints and analyze things. In those cases, you need different ways to troubleshoot your application. One possibility is to analyze your log files.).

There are several types of log files that can help you troubleshoot your Web App:

* Application logging

    * This log contains trace information you write from your application

    * Application logging can only be turned on for 12 hours. After that, it shuts itself off

    * You can indicate the logging level: Error, Warning, Information or Verbose

* Web server logging

    * Information of the webserver itself

* Detailed error messages

    * Detailed information about exceptions in your Web App

* Failed request tracing

    * Specific information about requests to your Web App that fail

Before we can look at log files, we need to configure the Web App to log things. Navigate to your Web App in the Azure Preview portal and go to All Settings > Diagnostics logs. This takes you to the screen illustration 4.

Depending on the type of logging you need, you enable it per type and click Save to enable your settings. Also these settings can be changed from the Server Explorer in Visual Studio.

This is only useful when you are investigating a specific piece of code in your application. I used this a couple of times to analyze performance problems. When you need to analyze exceptions, you’ll probably run into the fact that your trace messages don’t trace the exact bit you need. Here is how you use it:

The **System.Diagnostics** namespace allows you to write messages from your application. You do this by using Trace.WriteLine:

1 public ActionResult TestTracing() 

2 { 

3 Trace.WriteLine("TestTracing bericht"); 

4 

5 return View(); 

6 }

After calling this method, we can find this trace message in the application log. There are many ways to save logs and access them (through FTP, Azure Storage, the Azure Preview Portal and third-party applications). For now, we will use Visual Studio to analyze the log files.

Go to Server Explorer and select View Streaming Logs from the context menu of your Web App, like in illustration 5.