Как вы регистрируете ошибки (исключения) в своих приложениях ASP.NET?

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

В моей компании у нас был собственный ErrorMailer, который ловил все в Global.asax Application_Error. Это было "Хорошо", но не очень гибкое и настраиваемое.

Недавно мы переключились на NLog. Он гораздо более настраиваемый, мы можем определять разные цели для ошибок, фильтровать их, буферизовать их (еще не пробовал). Это очень хорошее улучшение.

Но в последнее время я обнаружил, что для этой цели существует целое пространство имен в структуре .Net: System.Web.Management, и его можно настроить в раздел healthMonitoring в файле web.config.

Вы когда-нибудь работали с мониторингом здоровья .Net? Каково ваше решение для регистрации ошибок?

Ответ 1

Я использую elmah. У него есть некоторые действительно приятные функции, и вот статья CodeProject. Я думаю, что команда StackOverflow также использует elmah!

Ответ 2

Я использовал Log4net, настроенный для отправки сообщений о фатальных ошибках. Он также настроен для регистрации всего файла журнала, что неоценимо при попытке отладки проблем. Другое преимущество заключается в том, что если эта стандартная функциональность не делает то, что вы хотите, довольно легко написать пользовательский appender, который может обрабатывать информацию о протоколе по мере необходимости.

Сказав это, я использую это в сочетании с настраиваемым обработчиком ошибок, который отправляет html-адрес электронной почты с немного большей информацией, чем включен в стандартные сообщения журнала log4net: страница, переменные сеанса, файлы cookie, переменные HTTP-сервера, и др.

Они оба связаны в событии Application_OnError, где исключение регистрируется как фатальное исключение в log4net (которое затем вызывает его по электронной почте на указанный адрес электронной почты), а также обрабатывается с помощью настраиваемого обработчика ошибок.

Сначала услышал о Elmah из записи блога Coding Horror, Crash Responsible, и хотя это выглядит многообещающе, я еще не реализовал его в каких-либо проектах.

Ответ 3

Я использую объекты регистрации журналов Enterprise Library. Он позволяет иметь различные типы ведения журнала (плоский файл, электронная почта и/или база данных). Он довольно настраиваемый и имеет довольно хороший интерфейс для обновления вашего web.config для настройки ведения журнала. Обычно я вызываю свой журнал с помощью функции "Ошибка" в Global.asax.

Здесь ссылка на MSDN

Ответ 4

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

У меня также будет установлено приложение Application_Error, чтобы поймать любое исключение, которое не ожидалось, и ошибка регистрируется как фатальный приоритет через log4net (ну, 404 обнаружены и зарегистрированы как информация, поскольку они не настолько высоки).

Ответ 5

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

Например, наш код будет выглядеть так:

Try
  Dim p as New Person()
  p.Name = "Joe"
  p.Age = 30
Catch ex as Exception
  Log.LogException(ex,"Err creating person and assigning name/age")
  Throw ex
End Try

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

Это не совсем то, что вы ищете. Другой подход, подобный использованию Global.asax, - это метод ввода кода, например AOP с PostSharp. Это позволяет вводить пользовательский код в начале и в конце каждого метода или для каждого исключения. Это интересный подход, но я считаю, что он может иметь тяжелые эксплуатационные издержки.

Ответ 6

Моя команда использует log4net от Apache. Это довольно легкий и простой в установке. Лучше всего, он полностью настраивается из файла web.config, поэтому, как только у вас есть крючки в настройке кода, вы можете полностью изменить способ ведения журнала, просто изменив файл web.config.

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

Ответ 7

Недавно я создал веб-сервис asp.net с NLog, который я использую для всех своих настольных приложений. Журналирование отлично работает, когда я отлаживаю Visual Studio, но как только я переключаюсь на IIS, файл журнала не создается; Я еще не определил, почему, но тот факт, что мне нужно найти решение, заставляет меня хотеть попробовать что-то еще для моих потребностей asp.net!

Ответ 8

Мы используем EnterpriseLibrary.ExceptionHandling.Logging. Мне нравится немного лучше, чем log4net, потому что мы не только полностью контролируем ведение журнала, но и можем управлять решением Throw/NoThrow внутри config.