Transferring your custom trace log files in Windows Azure for remote inspection

You can write your trace data explicitly to files or use tracing facilities like .NET’s trace source and listener infrastructure (or third party frameworks like log4net or nlog or…). So, this is not really news

In your Windows Azure applications you can configure the diagnostics monitor to include special folders – which you obtain a reference to through a local resource in VM’s local storage - to its configuration whose files will then be transferred to the configured Azure Storage blob container.

Without any further ado:

public override bool OnStart()
{
    Trace.WriteLine("Entering OnStart...");

    var traceResource = RoleEnvironment.GetLocalResource("TraceFiles");
    var config = DiagnosticMonitor.GetDefaultInitialConfiguration();
    config.Directories.DataSources.Add(
        new DirectoryConfiguration
        {
            Path = traceResource.RootPath,
            Container = "traces",
            DirectoryQuotaInMB = 100
        });
    config.Directories.ScheduledTransferPeriod = TimeSpan.FromMinutes(10);

    DiagnosticMonitor.Start("DiagnosticsConnectionString", config);
         
    return base.OnStart();
}        

Note: remember that there are special naming conventions in Azure Storage, e.g. for naming blob storage containers. So, do not try to to use ‘Traces’ as the container in the above code!

And a side note: of course this whole process incurs costs. Costs for data storage in Azure Storage. Costs for transactions (i.e. calls) against Azure Storage and costs for transferring the data from Azure Storage out of the data center for remote inspection.

Alright – this is the base for the next blog post which shows how to use a well-known trace log citizen from System.Diagnostics land in the cloud.

Hope this helps (so far).