More Support for EventSource and strongly typed logging: The Semantic Logging Application Block

If you have been following my blog at all, you have seen my articles about System.Diagnostics.Tracing.EventSource, a class that introduced in V4.5 of the .NET Runtime for production logging.    This class replaces the System.Diagnostics.TraceSource class  and we strongly encourage people to consider using EventSource instead of TraceSource for any future work (You can events from one go to the other 'stream' so you can transition slowly if you need to)   We like to believe EventSource is  'ultimate' in logging APIs for .NET in that you should be able to do pretty much any logging you desire with it and we should not have to change it in incompatible ways, ever.   We believe this simply because of the 'shape' of a logging statement, here is a prototypical one

  • myEventSource.MyEvent(eventArg1, eventArg2, ...)

Basically at the call site you specify

  1. The EventSource (myEventSource)
  2. The Name of the Event being raised as a method (MyEvent)
  3. Any 'payload' arguments you wish to log as part of logging that event. 

Notice I did not specify any formatting strings, logging levels, or other meta data at the call site, just what 'has to be there'.   What may not be quite so obvious is that all the event arguments are passed without loss of type information (the MyEvent method is strongly typed, not a 'params object[]').   Unlike 'printf' 'string.Format' logging we did not 'stringify' anything and loose information. It is all passed to the logging method.   This information is preserved in the EventSource 'pipe' which means that when you access a particular event you can do so in a strongly typed way, accessing each payload argument with a property accessor as this snipped of code demonstrates. 

MySourceParser.MyEvent += delegate(MyEventTraceEvent data) {

    Console.WriteLine("MyEvent: Arg1 = {0}  Arg2 = {2} ", data.MyArg1, data.MyArg2);    // Where MyArg1, and MyArg2 are the names of the parameters of the 'MyEvent' method.

}

Thus you really can get to the point where your logging is what you wanted, it is like passing data a method call in the program being monitored, through the logging pipeline (serialization) to pop out as a  to strongly typed structure in some automation that processes logging information files.    Basically you get a 'full fidelity' (without loss of type information or 'metadata' like payload names) end to end pipeline for logging information.   This is ideal in event logging, and EventSource is in a position to deliver it.

We are not completely there yet as there are missing pieces.  However far more of it is actually in place, people just don't know about it.  I am trying to fix this with my blog, but there is a lot to tell and event that is a work in progress.    Well in the blog entry I am here to tell you about one of the big pieces of this overarching 'strongly typed eventing story' that is falling into place:

The Semantic Logging Application Block

Microsoft has a team called the 'Patterns and Practices' team whose job it is to illustrate gpod and proven practices in using Microsoft technologies.   As part of their work they write guidance and build samples of real applications, but they also write utility libraries that 'flesh out' Microsoft technologies that currently only provided 'the basics'.   This team recognized that the strongly typed pipeline that EventSource provides is a great foundation, but only provided the basics, and they could provide the next layer of 'value add' libraries.  

This is what the Semantic Logging Application Block is.    'Semantic Logging' is their term for strongly typed logging.   They like the term because it strongly conveys the fact that the logging happens at a more structural level, and is much closer to the logging the semantics of the program (since you pass strongly typed fields without losing the types or the names of the event or fields), than classic string based logging does.    This 'Embracing Semantic Logging' article gives a great summary of their view of why they like semantic logging and why you should too. 

As you might expect, I heartily endorse their philosophy on logging, and their efforts to 'flesh out' the EventSource foundation, and make it as useful as possible to as many as possible.   If you are not already a convert to EventSource, I strongly encourage you to read 'Embracing Semantic Logging'. 

For those of you who are already 'on board' with strongly typed logging, what can Semantic Logging Application Block do for you?    

  1. EventListeners that send your EventSource data to various places like a flat files, Azure storage, the windows event log, a database etc. 
  2. An EventListener host/service that can process events from any processes on the system and do application specific monitoring / rollups. 

 For more complete details see their the PDF file documentation on the 'Download' tab.  Here are the links for the current release (but are likely to be broken in the future)

  1. SemanticLogging-DevelopersGuide-draft-CTP.pdf
  2. SemanticLogging-ReferenceDocs-draft-CTP.pdf

So, if you are doing logging on the .NET platform, you should be using EventSource.   If are looking around for what reusable code you can leverage, take a look at the Semantic Logging Application Block. 

Vance