So far, I've been quite happy with Microsoft's Enterprise Instrumentation Framework (EIF). It takes a while to get used to the configuration schema, and there are a fair number of knobs and buttons to twist, but once you get the mental model right the design is actually fairly clean. All the problems I've encountered so far have been mine.
Until now. I recently moved the project I was working on to a load-balanced machine, to test it in that environment. I had a problem, so I did what I usually do: fire up the log viewer I wrote against the EIF reader API to check out the log. And I saw no events.
At first I thought it was configuration - that I might not have set up the remote machine properly. Nope - the trace service (I'm using the trace service they ship with the project as my event sink) wrote a file, and when I copied that file to my local machine, I was able to view it just fine. Next I thought it might be a bug in my viewer. Nope - the viewer they ship with the product has the same problem.
I whipped out Reflector to decompile the EIF libraries to see if I could find the problem. Unfortunately, TraceLogReader.Read disappears into some native code that they wrote at some point, and the problem pretty much has to be in there.
So basically, at this point, I'm thinking there's a bug in the EIF TraceLogReader.Read method around reading from logfiles on remote machines. Given that the product is supposed to support enterprise applications, this seems almost ludicrous. I'm hoping that I'm missing something - but it doesn't look like it.
Not sure about this one, but watch-out using EIF with services or other time-critical systems -- the initialization cost incurred with EventSource tracing is non-negligible!
ReplyDeletehttp://blog.gatosoft.com/PermaLink.aspx?guid=7bbc5a70-70a1-4a76-980e-03db04469fd3
I think you are right :(, from what I can tell TraceLogReader is a thin wrapper around good old Win32 OpenTrace/ProcessTrace API (check out Microsoft.EnterpriseInstrumentation.Internal.NativeMethods in the same assembly).
ReplyDeleteMaros
Interesting. Probably not an issue for us, since we're doing everything in ASP.NET, but good to know!
ReplyDelete