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

Question

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

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

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

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

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

Answer 1

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

Answer 2

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

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

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

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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

Answer 6

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

Answer 7

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

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

Answer 8

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

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

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