In Windows Azure VM diagnostics is enabled by default so basic log can be collected and transferred to Azure Storage on demand. With Windows Azure SDK 1.6, the default application setting do two things:
1. It enable the diagnostics and transfer diagnostics logs to defined Azure Storage (local or cloud)
2. if you publish your application directly from VS2010, then the default setting use the same Azure Storage details as connection string to transfer Azure Diagnostics data
So if you will not make any change to these two default settings and you deploy your application directly from Visual Studio, the package is temporarily stored in “vsdeploy” container at the Azure Storage which you have configured during Publish setup. Because of the setting below, the same Azure storage is used by Azure Diagnostics to store diagnostics data:
If you deploy your application directly without making change to default diagnostics setting, you will see about ~10,000 transactions added daily to your Azure storage. The best way to disable these transection by disabling the Azure Diagnostics directly in your application and the deploy it again by deleting the previous one. When diagnostics is disabled the setting should look like a below:
Also when default diagnostics is disabled you will NOT see the following configuration in your service configuration and service definition:
ServiceDefinition.csdef: <Imports> <Import moduleName="Diagnostics" /> </Imports> ServiceConfiguration.cscfg: <ConfigurationSettings> <Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="UseDevelopmentStorage=true" /> </ConfigurationSettings>
After that you can just package your Windows Azure Application as below:
And depend on your packaging settings…
The Windows Azure application will be created as below:
Now you can just deploy this package directly at the portal and you will not see any Azure Diagnostics transection in any Azure storage because we haven’t used any.
The trick here is that in this deployment we haven't use any Azure Storage reference (You must not deploy your package form VS2010 or Azure Storage to avoid) so the default Azure Diagnostics will not be able to send diagnostics data anywhere because the Azure VM does not have any reference to Azure VM.
This is just not a good idea to follow. Diagnostics by default do not transfer to storage. Even if they did, and even if they accounted for 10,000 tx per day, I would not disable it. I personally would rather pay the extra penny per day (10K tx == $.01) and know what was happening in my roles. Disabling the diagnostics (removing the plugin) means you have to redeploy to re-enable it.
What are the consequences of disabling the diagnostics? (i.e. Does it affect the ability of Azure to recover from instance failures? When do the diagnostics come in handy?)