To quote my good friend Christian:

“Tracing is probably one of the most discussed topics in the Windows Azure world. Not because it is freaking cool – but because it can be very tedious and partly massively counter-intuitive.”

<rant>

The .NET Framework has this wonderful facility called TraceSource. You define a named trace and route that to a configurable listener. This gives you a lot of flexibility – you can create a single trace file – or multiple ones. There is even nice tooling around that. SvcTraceViewer from the SDK let’s you open the XML trace files – you can filter and sort by trace source and event type, aggreate multiple files…blablabla. Just what you would expect from a decent tracing infrastructure.

Now comes Windows Azure. I was already were grateful that starting with the SDK 1.2 we finally had a way to do tracing and diagnostics in the cloud (kudos!). But the way the Azure DiagnosticMonitor is currently implemented – could be called flawed.

The Azure SDK provides a DiagnosticsMonitorTraceListener – which is the right way to go. The only problem is, that way this works is, that all traces (from all sources) get written to an ETW trace. Then the DiagMon listens to these traces and copies them periodically to your storage account. So far so good.

But guess what happens to your nice trace files:

• the trace source names get “lost”. They appear in your message text at the end. So much for filtering and sorting and aggregating (regex #fail or #win??).
• Every trace line becomes an entry in a Azure Storage Table – the svclog format is gone. So much for the existing tooling.

To solve that problem, one workaround was to write your own trace listener (!) that creates svclog files inside of local storage and use the DiagMon to copy those. Christian has a blog post about that. OK done that.

Now it turns out that this mechanism does not work anymore in 1.3 with FullIIS (see here). Quoting:

“Some IIS 7.0 logs not collected due to permissions issues...The root cause to both of these issues is the permissions on the log files.”

And the workaround:

“To read the files yourself, log on to the instance with a remote desktop connection.”

Now then have fun with your multi-instance deployments….

</rant>