In my previous post, I discussed separate storage accounts and the locality of those accounts as well as transfer, sample and trace logging levels as ways to optimize using Diagnostics using Windows Azure. This post discusses six additional ways to optimize your Windows Azure Diagnostic experience.
- Data selection– Carefully select the minimal amount of diagnostic data that you need to monitor your application. That data should contain only the information you need to identify the issue and troubleshoot your application. Logging excess data increases the clutter of looking through logs data while troubleshooting and costs more to store in Windows Azure.
- Purge Azure diagnostic tables – Periodically purge the diagnostic tables for stale data that you will not need any more to avoid paying storage costs for dormant bits. You can store it back on-premise if you feel you will need it sometime later for historical or auditing purposes. There are tools to help with this including System Center Monitoring Packfor Windows Azure.
- Set Perfmon Counters during role OnStart– Diagnostics are set per role instance. Due to scalability needs the number of role instances can increase or decrease. By putting the initialization of the Perfmon counters in the OnStart method (which is invoked when a role instance is instantiated) you can ensure your role instance will always start configured with the correct Perfmon counters. If you don’t specifically setup the counters during the OnStart method, the configurations might be out of sync. This is a common problem for customers who do not define the Perfmon counters in OnStart.
- Optimize Performance Counters– Sometimes diagnostics are like gift purchases before Christmas sale. You need only a few of them but due to the lower prices you end up buying more than you need. The same goes with performance counters. Be sure what you are gathering are meaningful to your application and will be used for alerts or analysis. Windows Azure provides a subset of the performance counters available for Windows Server 2008, IIS, and ASP.NET. Here are some of the categories of commonly used PerfMon counters for Windows Azure applications. For each of these categories there can be more than one actual counter to track:
- NET CLR exceptions
- NET CLR memory
- ASP.NET process and app restarts
- ASP. NET requests
- Memory and CPU
- TCPV4 connections
- Network Interface (Microsoft Virtual Machine Bus Network Adapter) bytes
- Manage max buffer size– When configuring Perfmon counters to be used in your role’s OnStart method you can specify a buffer size using the PerformanceCounters.BufferQuotaInMB property of the DiagnosticMonitorConfiguration object. If you set this to a value that fills up before the buffer is transferred from local to Azure storage you will lose the oldest events. Make sure your buffer size has room to spare to prevent loss of diagnostic data.
- Consider WAD Config file – There are some cases where you may not want to put all the calls to configure Perfmon counters or logs to use in a config file instead of the code for the role. For instance, if you are using a VM which does not have a startup routine or non-default diagnostic operations, you can use the WAD config file to manage that. The settings in the config file will be set up before OnStart method gets called.