Why use ETW in product?
Before I go further, here are some diagrams can help you get a whole understanding about ETW.
Compared to default trace/OutputDebugString(), ETW has those advantages.
- Cross modules
- Leverage with system events.
- Fully integrated with OS
Those features make ETW the best choice of instrumentation.
According to MS document, ETW is high-speed-low-overhead.
High speed: 1200 to 2000 cycle per logging event.
Low overhead: Less than 5% of the total CPU cycles for 20,000 events/sec
In my test, at least 3 times faster than OutputDebugString() in the case of enable ETW session. You can check my previous post for detail number and get the sample code.
Needless to say that ETW can be disabled anytime. If you have put OutputDebugString() in critical path, now is the time to change it.
The ETW events carry more information for filtering / grouping such as Events / Channels / Levels / Tasks / Opcodes / Keywords. (a Manifest-based event provider)
You can check Writing an Instrumentation Manifest for the meaning of each type.
Think about hundred of thousand debug messages showing over DebugView. You will thank MS for this.
Once you complete the instrumentation, you are no longer need to modify your code/app configuration.
Depends on whether the ETW session exists and interested providers’ GUID are assigned, ETW providers will be enabled or disabled at run-time.
- you don’t have to re-start you application and can start to investigate issues on-site .
- Only interested event providers will produce events.
What a great feature.
4. Cross modules
Having messages created from app-level to component-level under a specific task is very useful while integration debugging.
Now, use ETW, we are able to collect data as a whole.
5. Leverage with systemevents.
It is often that we want to understand where the computation resource spend. Knowing how system reacts to your operations is the key to performance.
Therefore, it is very important that your debug or profiling data can works with system’s.
Here is the example of using XPerf. The yellow and green dots is my task.
6. Fully integrated with OS
you can subscribe your events via EventViewer
After thinking all over again, I do believe ETW is the right way to go.
Practically, on my experience on .Net, publishing ETW events is also very easy. On the contrast, Consuming or visualizing the data is not that easy.
But, we do have to worried about the consumer. There are already a lot of ETW tools. Ex: TraceViewr, XPerf, ETViewer, logman.
- About Event Tracing
- How To Use Event Tracing For Windows For Performance Analysis
- Improve Debugging And Performance Tuning With ETW
- Writing an Instrumentation Manifest
- Event Tracing in Windows Presentation Foundation
- Writing Events with System.Diagnostics.Eventing
- How to consume ETW events from C#