Home > Articles > Programming > Windows Programming

Why Did My Azure Application Crash? Using the Windows Azure Diagnostics API to Find Code Problems

  • Print
  • + Share This
  • 💬 Discuss
Michael Stiefel shows a variety of ways to use the Windows Azure Diagnostics API, particularly the new Diagnostic Monitor, to find and fix problems in your Azure code.

Your Azure application isn't working. What should you do now? Better question: What should you have done before now?

You can't put your application in the debugger and run it in the cloud. Your event logs, traces, and performance counters are all stored in the filesystem of the virtual machine. Since you can't assume that your role instances will run on the same virtual machine all the time, the information you need may not be there when you need it.

Your application runs behind a round-robin load balancer, so all the information you need might not be in one virtual machine anyway. If you use queuing, you've introduced a level of indeterminism in your application. In general, distributed applications are more complex because multiple applications or services have to be analyzed together.

In this article, I'll explain how the Windows Azure Diagnostics classes can help you to figure out why your Azure application isn't working correctly. If you want to follow along, I'll assume that you have some basic expertise:

  • You have a basic understanding of Windows Azure.
  • You understand roles and roles instances, as well as Azure Storage (blobs and tables).
  • You know how to build a simple Windows Azure application.
  • You have a basic understanding of the standard .NET diagnostic classes.

Application Monitoring

To understand what went wrong in an application, you have to monitor and record the state of the application. In general, you want to record four categories of information about your application:

  • Programmatic: Exceptions, values of key variables[md]in general, any information needed to debug the application.
  • Business process: Auditing needed for security, change tracking, compliance.
  • System stability: Performance, scalability, throughput, latencies.
  • Validation of business assumptions: Is the application being used the way you thought it would?
  • + Share This
  • 🔖 Save To Your Account

Discussions

comments powered by Disqus