я использую мои приложения .NET 4.5 для генерации событий ETW, используяEventSource учебный класс. Цель состоит в том, чтобы иметь возможность захватить некоторые из этих событий (события уровня ошибки) для регистрации ошибок.

После некоторого чтения и тестирования меня беспокоит надежность этого подхода к ведению журнала ошибок, в частности, относительно возможности пропущенных или пропущенных событий. Если моя ошибка не регистрируетсяЯ должен закрыть приложение (в моем случае небезопасно запускать его с незарегистрированными ошибками). При использовании ETW иEventSourceКак я могу быть уверен, что мои ошибки правильно записываются?

Очевидно, что часть ответа будет зависеть от того, что слушает события. В моем случае я планирую использоватьБлок приложения семантической регистрации » из последней библиотеки MS Enterprise.

Вот один источник, где Microsoft говорит о возможных причинах пропущенных событий:Об отслеживании событий

Там они перечисляют эти возможные причины пропавших событий

Общий размер события превышает 64 КБ. Это включает в себя заголовок ETW плюс данные или полезную нагрузку. Пользователь не может контролировать эти пропущенные события, поскольку размер события настраивается приложением.

Размер буфера ETW меньше, чем общий размер события. Пользователь не может контролировать эти пропущенные события, поскольку размер события настраивается приложением, регистрирующим события.

При ведении журнала в реальном времени потребитель в режиме реального времени не потребляет события достаточно быстро или не присутствует вообще, а затем файл резервной копии заполняется. Это может произойти, если служба журнала событий остановлена и запущена во время регистрации событий. Пользователь не может контролировать эти пропущенные события.

При входе в файл диск слишком медленный, чтобы не отставать от скорости записи.

Чтобы увидеть, были ли эти проблемы как-то смягчены с помощью класса EventSource (например, урезает ли он большие полезные нагрузки), я провел некоторое тестирование. Я попытался записать длинные строки, и у меня не получилось от 30 000 до 35 000 символов (прямо в соответствии с максимальной полезной нагрузкой 64 КБ). Он просто молча ничего не делает из того, что я могу сказать для слишком больших строк, никаких событий вообще в моем журнале блокировки приложений семантической регистрации. События до и после были написаны как обычно.

Таким образом, в любое время у меня есть строка в моей полезной нагрузке, я должен передать ее через некоторый усеченный? Нужно ли вручную избегать генерации событий?слишком быстро" а также (и как это было бы возможно)?

Шаблоны и практики Microsoft должны привести нас к хорошим ... шаблонам и практикам ... так что, может быть, яЯ просто что-то здесь упускаю.

Обновить:

Ну, видимо, есть какое-то уведомление в приложении для потребителя "События слишком быстрые » состояние. Я получил это сегодня впервые:

Уровень: Предупреждение, Сообщение: некоторые события будут потеряны из-за переполнения буфера или задержки синхронизации схемы в сеансе трассировки: Microsoft-SemanticLogging-Etw-svcRuntime

А потом при закрытии сессии:

Уровень: Предупреждение, Сообщение: в сеансе трассировки обнаружена потеря 1 события.Microsoft-SemanticLogging-ETW-svcRuntime.

Update2:

Руководство для разработчиков корпоративных библиотек описывает поведение, которое я только что упомянул.

Вам следует отслеживать сообщения журнала, сгенерированные прикладным блоком семантического ведения журнала, на наличие признаков переполнения буферов и потери сообщений. Например, сообщения журнала с идентификаторами событий 900 и 901 указывают, что приемникпереполнены внутренние буферы; в сценарии вне процесса идентификаторы событий 806 и 807 указывают на переполнение буферов ETW. Вы можете изменить параметры конфигурации буферизации для приемников, чтобы уменьшить вероятность переполнения буферов при ваших типичных рабочих нагрузках.

Мой вопрос остается, могу ли я использовать семантическое ведение журнала, гарантируя, что мое приложение не запускается, если ошибки удаляются? Нормальные события трассировки могут быть отброшены ...

Моя текущая мысль состоит в том, чтобы войтикритический» ошибки с отдельным классом с использованием старомодных методов ведения журналов и хранения менее критических ошибок (а также событий типа отладки), проходящих через конвейер ETW. Это нене так уж и плохо ... Я могу опубликовать это как решение, если смогунайти лучшее предложение.

Обновление 3:

"пропущенные события " предупреждение о том, что я получил, не имеет ничего общего с переполнением буфера, оказывается, это сообщение, которое вы получаете, если передаете нульstring в качестве значения полезной нагрузки.