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

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

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

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

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

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

15.08.2008 04:05:10
Я также видел System.Web.Management, но никогда не использовал его. Я хотел бы услышать любые отзывы о том, хорошо ли это работает.
Ben Mills 4.12.2008 22:00:03
8 ОТВЕТОВ
РЕШЕНИЕ

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

29
15.08.2008 04:34:49
Я написал учебник ELMAH в прошлом году, который, я думаю, описывает этот сценарий более подробно, чем статья CodeProject.
ThomasArdal 27.09.2014 18:30:44

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

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

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
30.05.2017 20:15:57

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

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

0
15.08.2008 04:33:02

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

Вот ссылка на MSDN

2
15.08.2008 06:11:57
Я был вынужден использовать журнал MS Enterprise Library для проекта около года назад. Это было очень запутанно, и я не могу вспомнить точные детали, но в нем отсутствовала некоторая минимальная функциональность, которую можно было бы ожидать в решении для ведения журнала. Существует надстройка для Visual Studio, которая является единственным способом правильной настройки web.config. Этот инструмент переформатирует ваш web.config и удаляет из него все комментарии :(
TechSavvySam 8.09.2017 13:43:48

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

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

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

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

9
15.08.2008 06:31:07

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

0
15.09.2008 17:22:49

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

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

2
23.01.2009 09:56:20

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

0
9.08.2015 16:52:46