Aaaah! I can't believe how long this took me to work out :( It doesn't really help that the information is spread around a billion different pieces on MSDN and what not. But enough excuses! Here's what I think the steps are (and because I clearly am not a genius, feel free to improve this instruction set)
What we want Tracing (ie calls to System.Diagnostics.Trace.WriteInformation("hello") to be persisted to Table Storage)
How to get it From out of the box, Azure provides a bunch of configuration already, if you check the appropriate boxes in VS, but we'll go through it anyway...
1) Add the Windows Azure Diagnostics monitor trace listener to your web.config as below:
2) Configure Diagnostics within your WebRole.cs (I haven't tested it with Worker roles but I can't imagine it not working):
DiagnosticMonitorConfiguration diagnosticConfig = DiagnosticMonitor.GetDefaultInitialConfiguration(); //this copies across log/debug files (like .svclog files for WCF) diagnosticConfig.Directories.ScheduledTransferPeriod = TimeSpan.FromMinutes(1); diagnosticConfig.Directories.DataSources.Add(AzureLocalStorageTraceListener.GetLogDirectory()); diagnosticConfig.Logs.ScheduledTransferLogLevelFilter = LogLevel.Information; diagnosticConfig.Logs.ScheduledTransferPeriod = TimeSpan.FromMinutes(1); diagnosticConfig.Logs.BufferQuotaInMB = 500; diagnosticConfig.DiagnosticInfrastructureLogs.ScheduledTransferLogLevelFilter = LogLevel.Information; diagnosticConfig.DiagnosticInfrastructureLogs.ScheduledTransferPeriod = TimeSpan.FromMinutes(1); diagnosticConfig.WindowsEventLog.ScheduledTransferLogLevelFilter = LogLevel.Information; diagnosticConfig.WindowsEventLog.ScheduledTransferPeriod = TimeSpan.FromMinutes(1); diagnosticConfig.WindowsEventLog.DataSources.Add("System!*"); diagnosticConfig.WindowsEventLog.DataSources.Add("Application!*"); DiagnosticMonitor.Start("Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString", diagnosticConfig);
So, note that you set up a DiagnosticConfig, and for each category of diagnostic info (such as logs, windows event logs, etc) you specify a transfer period, and a filter/severity level where applicable. You then start the DiagnosticMonitor, by passing in a configuration name (more on this in the next step) and the DiagnosticConfig object.
3) Add connection strings to Azure Storage
In your Cloud.cscfg file, ensure you have a setting with the same name as specified by DiagnosticMonitor.Start():
<ServiceConfiguration serviceName="AdviserPortal.Services.Azure" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration" osFamily="1" osVersion="*" schemaVersion="2012-05.1.7"> <Role name="My.Role"> <Instances count="1" /> <ConfigurationSettings> <Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="DefaultEndpointsProtocol=https;AccountName=YOURACCOUNT;AccountKey=YOURACCOUNTKEY" /> </ConfigurationSettings> <Certificates> </Certificates> </Role> </ServiceConfiguration>
For the Local.cscfg, you can use
<Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="UseDevelopmentStorage=true" />
So now, we should have configured Azure to copy across the trace information, etc across to table storage every minute. You can change the timeouts to a value that suits you, and the information should be logged to a table named WADLogsTable.
If this isn't working for you, make sure you have the filter levels set to the right thing - for example, if you've set your DiagnosticConfig to only pick up Warnings, calls to Trace.Information are going to go missing.
It's essentially the same Tracing you've been using forever; we just need to tell azure what Diagnostics to copy, how often, and where to. It can be a little fiddly to get right, so I hope this helps someone! Again, if there's improvements to be made to the instructions above, for which I am certain there are, please sing out in the comments.