Почему я должен использовать Трассировка событий для Windows (ETW) по стандарту .NET EventLog class и наоборот? Знает ли мы, что мы будем использовать довольно много счетчиков производительности, повлияет на решение?
То, что я знаю до сих пор:
У ETW есть много преимуществ.
Во-первых, в .NET 4.5 его гораздо проще использовать. Класс EventSource в 4.5 значительно упрощает создание событий из вашего кода.
Однако даже без этого ETW имеет некоторые огромные преимущества, хотя обычно это работает по-разному и, как таковые, служит другой цели, чем EventLog.
EventLog действительно предназначен для ведения журнала. С другой стороны, ETW позволяет отслеживать прогресс вашего приложения в контексте всей системы в целом. Когда вы начинаете собирать события ETW, вы собираете их на системной основе, что позволяет не только трассировать ваше приложение, но и видеть, что происходит по отношению к системе по мере ее запуска. С помощью такого инструмента, как PerfView, вы можете видеть, как работают определенные части вашего приложения, одновременно видя, что происходит с каркасом и Windows в целом.
Эта статья статьи MSDN отлично справляется с описанием преимуществ ETW.
В то время как EventSource обеспечивает отличный идиоматический способ для разработчиков .NET для создания ETW-событий, он не имеет ни одного из знакомых мест для ведения журнала (скользящий файл, база данных и т.д.). ETW использует свои собственные адресаты, такие как .etl файлы, и использует различные инструменты для анализа и анализа данных журнала.
Новый Блок приложений семантического ведения журнала упрощает включение функций EventSource и управление поведением в журнале вашей системы. Это позволяет наследовать большую часть структуры из конвейера ETW, включая метаданные и полезную нагрузку, для записи сообщений журнала нескольким адресатам, таким как базы данных, скользящие файлы или хранилище таблиц Windows Azure, а также для контроля того, что ваша система регистрирует, установив фильтров и протоколирования.