Мы реализуем структурированное ведение журнала с помощью System.Diagnostics.Tracing.EventSource и используем собранные манифесты поставщика при сборе трассировок, чтобы избежать головной боли при установке с EventRegister и wevtutil.Мы разработали наши EventSources для регистрации на достаточно низком уровне для непрерывной, постоянной регистрации.Я изо всех сил пытаюсь реализовать коллекцию с массивом контроллеров ETW, доступных от Microsoft.Я хочу определить сеанс ETW, который:
- Устанавливает максимальный размер файла для моих файлов ETL
- Переход к новому файлу с увеличенной информацией о версии / отметке времени, когда файлы ETL достигают максимального размера,Я не хочу, чтобы циклические журналы перезаписывали старые события.Мы будем управлять архивом самостоятельно.
- Сохраняет данные манифеста с начала потока событий в каждом новом файле - помните, что мы используем встроенные манифесты провайдера.
Я получилзакройте с помощью следующей команды logman (указанный guid провайдера из пользовательского источника событий):
logman start "Session" -p "{55a51afc-22e0-5581-6db2-01d5bbe42500}" -mode newfile -max 1 -o .\test%d.etl -ets
При просмотре в Perfview первый сгенерированный файл ETL выглядит великолепно:
Каждый последующий файл выглядит следующим образом, предположительно из-за потери данных манифеста:
Есть ли опция, которую я могу предоставить logman для удовлетворения моих 3-х требований?Ванс Моррисон намекнул в своем блоге , что ETW поддерживает команду CaptureState для повторной отправки данных манифеста:
Решение для случая циклического буфера состоит в том, чтобы попросить EventSource сбросить егоснова проявите в конце следа (где это будет обязательно в окне).Это всего лишь один пример необходимого набора подробностей.ETW поддерживает это с помощью команды CaptureState.
Если logman не может этого сделать, может ли один из других контроллеров ETW удовлетворить все мои требования?Я открыт для perfview, Windows Performance Recorder, xperf, tracelog или любых других, которые я пропустил.