Windows high speed logging: ETW in C#/.NET using System.Diagnostics.Tracing.EventSource

re: Windows high speed logging: ETW in C#/.NET using System.Diagnostics.Tracing.EventSource

asava samuel — Sat, 13 Apr 2013 08:48:33 GMT

This logger works really well:

www.kellermansoftware.com/p-14-net-logging-library.aspx

re: Windows high speed logging: ETW in C#/.NET using System.Diagnostics.Tracing.EventSource

Andrey Tamelo — Wed, 06 Feb 2013 12:33:13 GMT

Thanks a lot for bringing this topic up! These posts make a lot to finally convince one of our customers that ETW is the way to go for tracing (the perf figures and other stuff look very compelling).

re: Windows high speed logging: ETW in C#/.NET using System.Diagnostics.Tracing.EventSource

Vance Morrison — Sun, 20 Jan 2013 22:56:19 GMT

As Sreeni has discovered, EventSource and EventListener are designed to work in the same process (actually the same Appdomain in the same process), Thus you can't have a EventSource in one process and communicate with it with an EventListener in another process. That was not the goal of EventListener. EventSource was designed to hook nicely into the Window ETW system, however. what if you wanted strongly typed logging but for whatever reason did not wish to use ETW? For that you would need a 'hook' that allows you to get at the all the events generated by your EventSources, so that you could send the log event data wherever you wanted (file, database, console ...) this is what EventListener does.

For cross-process logging of events, you have two possibilities

1) Use the built in support EventSource has for ETW, and use ETW as your cross-process communication mechanism. The is effectively what the example blogs.msdn.com/.../and-end-to-end-etw-tracing-example-eventsource-and-traceevent.aspx does (this example happens to do it in one process for simplicity, but hopefully it is obvious how you would make two processes).

2) Use EventListener in the process with the EventSources to get the eventSTream, and build your own cross-process communication path you want (e.g a pipe). Note that it non-trivial to keep the events 'strongly typed' so I don't recommend this unless option (1) can't be made to work (e.g. you have a phone or slate app and you want to log your events on your hosting machine).

re: Windows high speed logging: ETW in C#/.NET using System.Diagnostics.Tracing.EventSource

Sreeni — Sun, 20 Jan 2013 03:04:11 GMT

I tried to split the producer and consumer in EventSource demo. Interesting thing is, EventListener.EnableEvents (myListener0.EnableEvents(MinimalEventSource.Log, EventLevel.Verbose)) is taking EventSource's instance as input. As producer's instance and consumer's instance are different, consumer/listener is not receiving any events. Could you share a sample that splits producer (trace sender) and consumer (trace listener) into two different applications? I am able to successfully do this with TraceViewer. But not with EventTrace.

re: Windows high speed logging: ETW in C#/.NET using System.Diagnostics.Tracing.EventSource

Vance Morrison — Thu, 29 Nov 2012 15:47:02 GMT

Sorry for the delay. EventSource was designed so that it could be a complete replacement for TraceSource. Thus in an ideal world, a complete new code base would only use EventSource. The reason is that it is safer/easier (at the logging sites you ONLY specify what is actually needed (only the logger, event name and payload, no 'events ids, or logging levels etc). Moreover, EventSources (through EventListeners can do everything that TraceSources can do (in fact it is very straightforward to build a bridge where EventSource data gets written to TraceListeners (and thus any 'back end' infrastructure based on TraceListeners will 'just work'.

re: Windows high speed logging: ETW in C#/.NET using System.Diagnostics.Tracing.EventSource

Randhir — Tue, 04 Sep 2012 17:34:04 GMT

Thanks Vance for explaining this and making ETW palatable for general .Net public.

Could you pls compare EventSource with TraceSource? I understand EventSource would be much more performant but do you see a place for TraceSource usage as well?

Simply asking, if you are coding a version 1 of your product, would you only use EventSource or combination of EventSource and TraceSource?

-Randhir

re: Windows high speed logging: ETW in C#/.NET using System.Diagnostics.Tracing.EventSource

Vance Morrison — Mon, 13 Aug 2012 16:28:44 GMT

I am not making (or implying) anything about DTrace or how it compares to ETW. For those who don't know, DTrace is the analog to ETW on Unix operating systems. It is simply not an option on Windows platforms so such a comparison can only be useful to the implementors of each system since end users simply don't have a choice. For what it is worth, I do think that ETW could benefit from some of the features of DTrace, but I also believe that both existing systems are more than good enough for the vast majority of diagnostic and performance investigations.

The weakest link frankly is user education about what capabilities are available, and I am trying to fix that at least for people working on windows operating systems (which are the only people who would probably care to read my blog).

re: Windows high speed logging: ETW in C#/.NET using System.Diagnostics.Tracing.EventSource

Barry Kelly — Mon, 13 Aug 2012 15:45:45 GMT

What you write seems to imply that you don't think dtrace is a better solution?

I think ETW is kind of over-engineered on one hand, yet limited and inflexible on the other. Dtrace seems way better to me.