Какой прослушиватель журналов следует использовать в продакшене? (Блок приложения ASP.NET / ведения журнала)

Я использую блок приложения MS Enterprise Logging на веб-сайте ASP.NET.

Для запуска производства я настрою прослушиватель журнала в одном из следующих мест:

  • База данных SQL Server
  • Журнал событий Windows
  • Текстовые файлы

Что меньше всего влияет на производительность?

NB. На данный момент я не могу переключиться на Log4Net или ELMAH, поэтому, пожалуйста, не предлагайте это в своем ответе.


logging asp.net performance enterprise-library logging-application-block
person frankadelic    schedule 10.09.2010    source источник

Ответы (3)


arrow_upward
1
arrow_downward

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

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

Журнал событий - это нормально, но если вы собираетесь его использовать, подумайте об использовании его только для серьезных ошибок, не загромождайте его кучей неважных сообщений. Используйте его вместе с SQL или текстовыми файлами, в которых важные ошибки регистрируются в обоих местах.

Что бы вы ни решили, протестируйте его на производительность перед запуском в производство.

person Jay Cincotta    schedule 10.09.2010

arrow_upward
0
arrow_downward

Мы используем журнал событий, и это, похоже, не влияет на производительность. Я не могу точно сказать вам разницу между ними ... когда дело доходит до базы данных, это зависит от обстоятельств. База данных находится на том же компьютере или на другом? Это на полпути через страну?

Обычно база данных работает быстро, но задержка в сети может замедлить процесс. Дисковый ввод-вывод обычно тоже довольно быстрый. Дисковый ввод-вывод для ведения журнала может быстро расти и может быть не лучшим вариантом, если вы храните все журналы в одном файле.

Кроме того, подумайте о доступности, к которой проще получить доступ без необходимости доступа к машине. База данных будет лучшим кандидатом в этой категории ...

HTH.

person Brian Mains    schedule 10.09.2010
comment
База данных находится на том же переключателе, что и веб-серверы. - person frankadelic; 10.09.2010
comment
Что касается ввода-вывода диска - разве журнал событий в конечном итоге не хранится на диске? - person frankadelic; 10.09.2010
comment
Еще одно - как вы обеспечиваете доступность журнала событий? Можно ли отправить журнал событий на другой компьютер за пределами производственной среды? - person frankadelic; 10.09.2010
comment
База данных на том же сервере будет довольно быстрой, но требует некоторого тестирования с вашей стороны, чтобы определить, какой будет скорость. Журнал событий находится на диске, но управляется менеджером событий. Я не уверен, сможете ли вы его отправить, поэтому я упомянул последнее утверждение о доступе. Если вы используете дисковый ввод-вывод, вам нужно записать его на диск с помощью XML, CSV и т. Д. - person Brian Mains; 12.09.2010

arrow_upward
0
arrow_downward

В итоге я использовал эту конфигурацию в продукте:

  1. FormattedDatabaseTraceListener для сообщений с уровнем серьезности «ошибка» и «критическое».
  2. Прослушиватель трассировки плоских файлов для specialSources на случай, если база данных журнала не работает.

Все, что имеет более низкий уровень серьезности, мы не регистрируем.

person frankadelic    schedule 22.12.2010
comment
Давным-давно, но как вы реализовали переключатель, я имею в виду, как вы сообщаете регистратору, какую категорию журнала использовать, когда db не работает? - person Legends; 04.05.2015