This is a great article on how to include an event id in the WADLogs table.

The trick is to use a custom trace source as follows

TraceSource ts = new TraceSource(“My Custom Event Source Name”, SourceLevels.Information);

ts.TraceEvent(TraceEventType.Warning, 102, “This is a test log using trace source”);

and then to configure the azure listener to get this into the appropriate log file:

This gets added to the appropriate system.diagonstics section:

<sources>

<source name=”MyTraceSource” switchName=”sourceSwitch” switchType=”System.Diagnostics.SourceSwitch”>

<listeners>

<add type=”Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics, Version=2.2.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ name=”AzureDiagnostics”>

<filter type=”” />

</add>

</listeners>

</source>

</sources>

<switches>

<add name=”sourceSwitch” value=”Warning”/>

</switches>

The big advantage of this is that you get to assign your own error codes to the messages.

Practically all of the default Azure stuff will be coded as zero.

This means that you can assign defined ranges of code to indicate that these are for example:

Timing Messages.

Notification for information.

Notification for action.

These make analysing the logs much easier.

Btw are you aware of the WADLogs powershell trick:

“0” + [DateTime]::UtcNow.AddHours(-1).Ticks

This gives a partition key of an hour ago.

This is great for getting extracted logs.

Extract the logs into csv and use the powershell import-csv command.

This is an amazingly fast way of analysing logs.