Chapter 6. Azure Website Diagnostics and Debugging

Diagnostics is an extremely important feature of any server application, and we have some great tools available in Microsoft Azure to effectively implement various types of diagnostics for our websites.

We need diagnostics on websites to help us track down and fix bugs and performance issues during all phases of the website's life cycle.

If we instrument our applications properly with tracing and error handling, we can determine where and why errors occur, and work out which parts of an application are taking too long to complete, causing performance issues, using tracing.

Using server logging, we can log all HTTP traffic, detailed error messages for HTTP response codes greater than or equal to 400 (which can help us diagnose why an error response is being returned), and failed request logging, which will help us detect server performance issues (possibly from under-resourcing) causing requests to fail.

In this chapter, we're going to look at...

Enabling diagnostics

We can configure basic website diagnostic settings through the Server Explorer window in Visual Studio by right-clicking on the website and selecting View Settings:

We can configure Web Server Logging, Detailed Error Messages, Failed Request Tracing, Application Logging (File System only, not storage), and Remote Debugging. This example shows Web Server Logging enabled; to apply changes, click on Save:

The same settings with some more advanced options (which we will cover in more detail in this section) are available in the CONFIGURATION tab in the website's workspace.

Tip

When you swop a staging website for a production website, the configuration (including logging) settings are swopped too, so make sure the staging configuration is correct before swopping.

Working with logfiles

Filesystem logging is the lowest common denominator for all the logging types in an Azure website, whether it's application logging or server diagnostics. We'll look at how we can access and work...

Application logging

Within our websites, we can use the System.Diagnostics.Trace object to help write trace information to the Azure website trace listeners, which write data to the file, table storage, and blob storage. If implemented properly, tracing is useful to help diagnose problems with errors and performance. In normal operations, we can log errors at the Error trace level to minimize storage and performance impact; however, if we experience difficulties, we can raise the LOGGING LEVEL value to show us more detailed information.

Visual Studio's Server Explorer only allows us to configure file logging, but we have full control of the trace listener options in the portal:

Here, we can enable logging to the file, table storage, and blob storage, and control the LOGGING LEVEL value for each option. There are five LOGGING LEVEL options, which correspond to the following trace levels:

• Off: This indicates that nothing is logged

• Error: This indicates 1 or lower logged

• Warning: This indicates...

Site diagnostics

Websites give us a number of site-diagnostic capabilities, which provide us insight into what our website is doing above the application layer (performing REMOTE DEBUGGING falls more into the application layer, but the configuration controls whether a debugger can be attached to a web server, which is a site layer). I think of this category of diagnostics in the same way as IIS logging on an on-premises web server.

Site diagnostics offers us the following diagnostic facilities:

• WEB SERVER LOGGING: This logs all HTTP transactions for a website, which can be helpful for monitoring transactional throughput of a site and gathering metrics. Logs can be stored to the FILE SYSTEM and are limited to a configurable QUOTA that ranges between 25 MB and 100 MB, or to a blob storage, which allows greater flexibility for storage size but will incur costs.

• DETAILED ERROR MESSAGES: This logs extra detailed error information for HTTP status codes that are 400 or higher and are returned by...

Kudu

Kudu is an open source (https://github.com/projectkudu/kudu) engine, which powers Azure website Git deployments and continuous deployments on all Azure websites. There is a Kudu service in every website, which can be accessed via the following URL https://mysite.scm.azurewebsites.net. If you have a custom domain name implemented, you will need to use the azurewebsites.net endpoint unless you do extra DNS configuration for this endpoint.

The Kudu service website looks like this:

There are some useful tools in here for working with logs; the Diagnostic Console (under Debug Console) has a CMD and PowerShell console in the browser along with a directory explorer, which allows you to work with logfiles:

You can get more information on the Kudu service at https://github.com/projectkudu/kudu/wiki/Accessing-the-kudu-service.

Remote debugging

Azure websites have great remote debugging support integrated into Visual Studio; we can enable remote debugging in the portal, and then attach the debugger through Server Explorer. Unfortunately, this is not supported in Visual Studio Express, so I will use Visual Studio 2013 Ultimate to demonstrate it (Premium and Professional are fine too). To start remote debugging, use the following procedure:

1. Make sure the website is deployed in the Debug configuration because the Release configuration is optimized and cannot be debugged. If the website is not deployed in the Debug configuration, you will see an error message like this:

   

2. To publish the website in the Debug configuration, change the Configuration setting under the Settings tab in the Publish Web dialog before publishing:

   

3. In the Azure portal, go to the CONFIGURATION tab in our website workspace, scroll down to the site diagnostics section, enable REMOTE DEBUGGING, and set REMOTE DEBUGGING VISUAL STUDIO VERSION to 2013:

   

4. Notice...

Summary

We've learned some really useful diagnostic techniques in this chapter to help us find problems in our Azure websites. I was planning on finishing this chapter by covering how to use Entlib SLAB (which is a more advanced logging block from the Microsoft patterns and practices team) with Azure table storage, but ran out of space, so you can read about it on my blog here:

http://webbercross.azurewebsites.net/entlib-slab-with-mvc5-website-and-azure-trace-listener/

In the next chapter, we're going to start configuring our Service Bus topic and integrate the sales customer website so that order messages will be sent to the other business domain systems when orders are created by the customers.

Questions

1. In terms of logging configuration, why is it important to be careful when swopping a staging table to live?

2. What type of logging is available to application logging and server diagnostics?

3. What information does the APPLICATION LOGGING (FILE SYSTEM) file-naming convention give us?

4. How do we filter streaming logs in Visual Studio?

5. Which .NET object helps us write trace information in our website?

6. What is a sensible normal logging level for an application and why?

7. What method can we use to trace a formatted message at the Information level?

8. In the controller example, why are we catching and rethrowing the exception?

9. How long is application logging to a file enabled for?

10. What types of application logging storage are not configurable through Visual Studio?

11. What type of filter query do we use with table storage?

12. What information do site diagnostics DETAILED ERROR MESSAGES give us?

13. What is the URL for a website's Kudu service?

14. Does Visual Studio Express support remote debugging?

15. Why must we publish...

Answers

1. Configuration settings are swopped with the website, so logging settings will be swopped.

2. File logging.

3. Log Files/application/[Instance Id]-[PID]-[EventTickCount].txt - Instance Id, Process ID.

4. Open the filter options using the double-chevron button on the right-hand side of the streaming log output toolbar and enter a filter string.

5. System.Diagnostics.Trace.

6. Error: This will allow us to catch or log any errors but minimize storage with additional information.

7. TraceInformation (string, object[]).

8. This is because the controller doesn't swallow the exception and allows the error to be handled globally by the default FilterConfig.

9. 12 hours.

10. Table and blob storage.

11. WCF Data Service filters.

12. Extra information about error response codes 400 or greater.

13. https://mysite.scm.azurewebsites.net.

14. No.

15. This is because the Release configuration is optimized and cannot be remote debugged.

16. 48 hours.

17. NA.

18. NA.