In this blog, I will demonstrate new diagnostics features of the new SDK (April 2012, v2.0) in a sample application. All the diagnostics instrumentation will be done on built-in features by modifying configuration settings. This is well aligned with “Configure before Customize” approach.
- Windows Azure SDK v2.0, Windows Azure .NET Developer Center. This includes azure emulators (compute and storage) as well.
- Storage Explorer (Optional): Azure Storage Explorer tool from Neudesic, http://azurestorageexplorer.codeplex.com/.
- Azure cloud service, please refer to this link http://www.windowsazure.com/en-us/manage/services/cloud-services/
- Azure storage account, please refer to this link http://www.windowsazure.com/en-us/manage/services/storage/
- And an IDE, I am using Visual Studio (VS) 2012.
Ok, time to run the cloud service. Then browse the Task page where some dummy traces are passed to listener as sampled just above this.
Where are the Logs?
All the diagnostics logs are written to files in "C:Users[your_user_account]AppDataLocal” path. Please note, you need change your folder settings, since the AppData is hidden. Here, DevelopmentStorage and dftmp folder are the locations where all the application related logs are written.
From the folder above, the logs matching selected log level (Error by default) are persisted into the storage table (WADLogsTable, etc). To see the entries, you can use different tools (storage explorer, etc.), I am going to use VS for this purpose as well. To do that, click on View on VS’ top menu, then Server Explorer (or Ctrl + W). On the Server Explorer panel, click on Windows Azure Storage then Development (local run), then Tables and "WADLogsTable" (storage table name).
How it works?
As you can see, diagnostics are already enabled for both web and worker roles. If you look at the web.config in the web application, you will see that a trace listener called ‘AzureDiagnostics’ also added (web role and the associated web application runs on different processes).
You can see that from GUI as well by right click on a role then Properties:
Now, we know the reason why error-type logs are written only, because, by default, it is set to ‘Errors only’. Diagnostics settings here are reflected in the diagnostics configuration file called ‘diagnostics.wadcfg’.
How-to Change Settings
Now, if you want to change the settings, please follow the steps picture below:
(1): Role diagnostics configuration window
For example, when I change log level to Information and enable both Event and Performance counters logs, I am able to see all the logs (except Verbose) for application, performance and events, as seen below:
And you can change the setting while your application running (alive!)
Please note that before going to deploy the solution, in regards to diagnostics feature context and the image (1) – "Role diagnostics configuration window" above:
- You need to update storage account accordingly. You should use a separate diagnostic storage table for PROD environment
- Set the log level for errors initially, when troubleshooting, you can set the level accordingly depending on implemented diagnostics features on your application (Information, Verbose, etc.).
- Set the buffer size and transfer intervals (less buffer/interval means, less amount of data and more often data transfer from the local folder to storage table. Please refer this link fore more details: http://msdn.microsoft.com/en-us/library/windowsazure/dn186185.aspx.
I have deployed the solution here. As said, before and sampled in picture below, I am able to see the diagnostic data from VS and to change the configuration settings –alive- if needed.
Software applications in general should have diagnostics enabled. This is exclusively critical for those running in Azure, because they are most likely a composite of applications running in different platforms and networks/locations. Health of the system (the overall application) is dependent on health of each its subsystems and to identify the cause of bugs (and, no mistake they occurs) when alive, you need to instrument your solution with meaningful diagnostics features, at least when passing the message one domain to another.
I have written several blogs about diagnostics features:
- Part 4: this post – Configuration based diagnostics features of Windows Azure SDK 2.0
- Part 3: Customized diagnostics features of Windows Azure SDK 2.0
- Part 2: Diagnostics of Azure Web Sites – Custom Logging, Windows Azure SDK 1.8
- Part 1: Diagnostics of Windows Azure Web Sites – Built-in Diagnostic Features (configuring diagnostics features directly from Azure Management dashboard)