To EIF or not to EIF...that is the question

When Microsoft released Enterprise Instrumentation Framework last year I investigated it to replace the Paul Bunyan logger we are currently using under our ASP.NET application. I liked EIF a lot, but we weren't able to incorporate it at the time for a variety of reasons. One of them was lack of a decent viewing tool. There is a simple little "Trace Viewer" sample app that comes with EIF, but when you hold it up against the Paul Bunyan Message Viewer that our operations people use today, it's just a toy. The Paul Bunyan viewer is able to view messages across many machines, with very powerful filtering (although the filtering interface is horrible, I've watched as people familiar with it make it work).

I expected that as EIF was more widely adopted we'd see some advanced viewing tools get written that could be given to our Paul Bunyan-partial operations folks without having to apologize. Maybe I'm not looking in the right place, but I haven't seen anything yet. When there was a better tool, I thought I'd bring up EIF again.

Then...At the PDC, I attended the tail-end of a session on ASP.NET diagnostics in Whidbey which confused me a little more. It was the “ASP.NET: Troubleshooting, Auditing and Tracing ASP.NET "Whidbey" Applications on IIS” WSV351 session presented by Erik Olson, and here is the Powerpoint:

I went in to this session fully expecting to see or hear about EIF, but unless I missed it, the presenter never mentioned it once. He talks about the Windows Tracing technology which underlies EIF and showed a command line tool for viewing the logs (yeah, the ops folks will love that) but he promoted System.Diagnostics.Trace was the one and only way to log messages. I'm very curious to know the future of EIF, it seemed like perhaps bits of EIF were moving down into the diagnostics system of Whidbey.

Here is an example (from the EIF docs) of how EIF is used, notice the static definition of an EventSource. All events are raised from this object.

using Microsoft.EnterpriseInstrumentation;
using Microsoft.EnterpriseInstrumentation.Schema;

class ExplicitTrace
{
   private static EventSource myEventSource = new EventSource("Explicit Trace");

   [STAThread]
   static void Main(string[] args)
   {
      // explicit
      TraceMessageEvent e1 = new TraceMessageEvent();
      e1.Message = "Costly Hello";
      myEventSource.Raise(e1);

      // slightly less resource-intensive explicit
      if myEventSource.IsEnabledForType(typeof(TraceMessageEvent))
      {
         TraceMessageEvent e2 = new TraceMessageEvent();
         e2.Message = "Less Costly Hello";
         myEventSource.Raise(e2);
      }

      // static one liner (which wraps the above code sequence)
      TraceMessageEvent.Raise(myEventSource, "Static One Liner Hello");
   }
}

What I like about EIF:

  • In flight reconfiguration: The ability to reconfigure logging levels without having to restart the web server.
  • Fine-grained control: You are able to easily turn on just the messages from a single event source.
  • Fast (?): The Windows Tracing is kernel mode so it's bound to be fast (although I never profiled it)
  • IsEnabledForType: The ability to skip costly logging messages with the IsEnabledForType() call (This avoids unnecessary string concatenation or String.Format() calls to build strings that aren't going to be logged anyway.)
  • Request tracing: You can correlate a single request across tiers.
  • Custom Sinks: The ability to write custom sinks (I wrote a Paul Bunyan one for backward compatibility)

What I didn't like about EIF:

  • No decent viewing tool.
  • The static EventSource usage pattern made writing a drop in Facade difficult. We currently have a static diagnostics wrapper that follows the System.Diagnostics.Trace.Write pattern where there doesn't have to be any source class defined in each class, you just call MyTraceFacade.Write("My message"). If I'm thinking about it correctly, you almost need to put a static EventSource in every class that needs to send messages, or else you'd have to keep a hashtable of EventSource's behind the facade and pass an EventSource name with every Write().
  • I also read many people had distribution problems, although we didn't experience this first-hand because we never got that far.

I'm interested in hearing what type of experiences others have had using EIF.

No Comments