Why Did My Azure Application Crash? Using the Windows Azure Diagnostics API to Find Code Problems
- Sep 8, 2011
- Application Monitoring
- Setting Up Windows Azure Diagnostics
- Accessing Windows Azure Diagnostic Data
- Windows Azure Diagnostics Configuration Demo
- On-Demand Transfer for the Windows Azure Diagnostics Configuration?
- Modifying the Windows Azure Diagnostics Configuration
- Tradeoffs with Windows Azure Diagnostics Configuration
- Windows Azure Service Dashboard
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.
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?