We implement structured logging with System.Diagnostics.Tracing.EventSource, and use the inline provider manifests when collecting traces to avoid the installation headaches with EventRegister and wevtutil. We have designed our EventSources to log at a sufficiently low volume for continuous, persistent logging. I'm struggling to implement collection with the array of ETW controllers available from Microsoft. I want to define an ETW session that:
- Sets a max file size for my ETL files
- Rolls to a new file with incremented version / timestamp info as ETL files reach max size. I do not want circular logs that overwrite old events. We'll manage archive on our own.
- Maintains manifest data from the beginning of the event stream in each new file - remember we're using inline provider manifests.
I got close using the following logman command (The provider guid specified is from a custom EventSource):
logman start "Session" -p "{55a51afc-22e0-5581-6db2-01d5bbe42500}" -mode newfile -max 1 -o .\test%d.etl -ets
Viewed in Perfview, the first ETL file generated looks great:
Each subsequent file looks like the following, presumably because the manifest data is lost:
Is there an option I can provide to logman to meet my 3rd requirement? Vance Morrison hinted on his blog that ETW supports a CaptureState command to re-send the manifest data:
The solution to the circular buffer case is to ask the EventSource to dump its manifest again at the end of the trace (where it will be sure to be in the window). This is just one example of a bunch of 'rundown' that is needed. ETW supports this with the 'CaptureState' command.
If logman can't do this, can one of the other ETW controllers meet all my requirements? I'm open to perfview, windows performance recorder, xperf, tracelog, or any other I've missed.