Instrumentation & Logging for SharePoint (Part 1)

Recently I have been defining how the development team will implement Instrumentation and Logging for SharePoint.  I looked at a lot of different options and settled on the built-in .Net Framework diagnostic routines.

Logging

For logging I decided to use the System.Diagnostics.TraceSource class.  This class was introduced with .Net Framework 2 and is a marked improvement over the original System.Diagnostics.Trace (my opinion). 

Out-of-Box System.Diagnostics has trace listeners for Event Log, Console and File System.  For grins I wrote a listener that will write to the SharePoint log system.  It was very easy since the WSS SDK contains an example.

Three really nice features I like about the improved Diagnostics tracing classes are: Trace Options, Source Levels and Trace Filters

Trace Options provide a nice flexible way of indicating what data should be written along with the log message.  Some examples include: Call Stack, Date & Time stamps, Thread ID, Process ID and Logical Call Stack.  These options can be configured in the configuration file so the application does not need to even know about them.

Source Levels provide a nice alternative to the old Trace Switch class.  A source level determines what type of messages should be logged (i.e. Critical, Error, All, ...).

Trace Filters provide a way to tell the Listener what types of errors it should log.  This is really nice because it means that I can create File System listener that will write out every messages passed on by the Trace Source.  At the same time my Trace Source could have an Event Log listener that still only writes critical messages to the Event Log.

The really great thing is all of these classes can be configured in a configuration file.

Below is a sample configuration I used while working with the Trace classes.

<system.diagnostics>
    <trace autoflush="true" />
    <sources>
        <source name="MyLogSource" switchValue="All">
            <listeners>
                <add name="consoleListener" />
                <add name="fileListener" />
                <add name="eventLogListener" />
                <add name="sharepointLogListener" />
            </listeners>
        </source>
    </sources>        
    <sharedListeners>
        <add name="consoleListener" type="System.Diagnostics.ConsoleTraceListener" />
        <add name="fileListener" initializeData="c:\temp\VolvoCWP.txt" type="System.Diagnostics.TextWriterTraceListener" traceOutputOptions="DateTime,ProcessId,LogicalOperationStack">
            <filter type="System.Diagnostics.EventTypeFilter" initializeData="All"/>
        </add>
        <add name="eventLogListener" type="System.Diagnostics.EventLogTraceListener" traceOutputOptions="DateTime,ProcessId,LogicalOperationStack" initializeData="JD Application">
            <filter type="System.Diagnostics.EventTypeFilter" initializeData="Critical"/>
        </add>
        <add name="sharepointLogListener" type="MyLogListener.SharePointTraceListener, MyLogListener, Version=1.0.0.0, Culture=neutral, PublicKeyToken=6bb1c46a01dcf0a2" ApplicationName="JeffD" ProductName="JeffD" CategoryName="Runtime">                
        </add>
    </sharedListeners>        
</system.diagnostics>

This configuration contains one Trace Source (MyLogSource).  It is configured to log all messages that are logged with it (switchValue="All").  It has four listeners it will use to log the message (yes the message can get logged into four places... not very practical in the real world). The consoleListener, fileListener and sharepointLogListener are configured with filters that tell them to log every message.  The eventLogListener is configured to only log messages marked as Critical.

The SharePointTraceListner was actually very simple to write.  I was able to find a really great example of writing to the SharePoint log inside the WSS SDK.  All I did was take that example and plug it into a standard Trace Listener. 

Technorati Tags: SharePoint,Logging,Development,.Net Framework