This is a mirror of official site:

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

| Wednesday, August 22, 2012
In my introduction to EventSource  posting and my posting of the EventSource specification, I tried to give you the 'quick start' for using EventSource to generate ETW events from C# (or any .NET language).   

In this posting I would like to back a bit and motivate the 'why' behind event tracing for windows (ETW) and EventSource in particular. 

What is the problem ETW / EventSource are trying to solve?

Simply put, EventSource was designed to solve the 'in the field monitoring/diagnostic' problem.    It can be useful for client applications, but its real value tends to be on the server side.   Diagnosing issues on servers is particularly hard because

  1. The servers are handling real user requests, so you don't have the luxury of disrupting users by attaching a debugger and stepping through code.
  2. Often the problems tend to only reproduce under load, which means they tend to be non-deterministic, so you don't even know when/where to attach.
  3. Within even a single process, server applications tend to be doing dozens of requests simultaneously, making it difficult to separate the processing of a particular request
  4. The problems are often performance issues, which if they are not dramatic, are hard to isolate from everything else going on
  5. You tend to have many servers, which means that even if you log, the volume of data requires that have automation for parsing the logs.

Thus for 'in the field' diagnosis, logging is the 'obvious' solution to getting the information you need.   What would an 'ideal' logging mechanism look like

  1. It would have zero overhead when it was turned off (pay for play)
  2. It would be very fast when it was on
  3. It would purturb the normal workings of the program as little as possible, even processor scheduling decisions (e.g. it would not take locks or cause extra context switches ...)
  4. It would caputure very accurate timestamps that work across processors so that races could be diagnosed. 
  5. It would allow extra data to be logged along with the fact that the particular event happen (e.g. file names URLs)

QR: Inline image 1

Posted via email from Jasper-net


Anonymous said...

You've made some good points there. I looked on the web for more information about the issue and found most individuals will go along with your views on this website.

Feel free to surf to my web blog :: windows registry cleaner