Я использую свои приложения .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 в качестве значения полезной нагрузки.