2008-08-15 18 views
25

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

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

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

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

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

+0

Я также видел System.Web.Management, но я никогда не использовал его. Я хотел бы услышать любые отзывы о том, хорошо ли это работает. – 2008-12-04 22:00:03

ответ

27

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

+4

В прошлом году я написал учебник [ELMAH Tutorial] (http://blog.elmah.io/elmah-tutorial/), который, я думаю, описывает этот сценарий более подробно, чем статья CodeProject. – ThomasArdal 2014-09-27 18:30:44

0

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

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

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. Это позволяет вводить пользовательский код в начале и в конце каждого метода или для каждого исключения. Это интересный подход, но я считаю, что он может иметь тяжелые эксплуатационные издержки.

0

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

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

2

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

Here's a link to the MSDN

+0

Я был вынужден использовать регистрацию MS Enterprise Library для проекта около года назад. Это было очень запутанно, и я не могу вспомнить точные детали, но в нем отсутствовала минимальная функциональность, которую можно было бы ожидать в решении для регистрации. Для Visual Studio есть надстройка, которая является единственным способом правильно настроить web.config. Этот инструмент переформатирует ваш web.config и удалит из него все комментарии :( – TechSavvySam 2017-09-08 13:43:48

9

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

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

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

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

+0

+1 Не мог бы лучше сказать это! – 2009-03-16 19:24:52

0

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

2

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

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

0

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