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

#asp.net #error-handling #nlog #health-monitoring

Вопрос:

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

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

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

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

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

Комментарии:

1. Я также видел System.Web.Management, но никогда им не пользовался. Я хотел бы услышать любые отзывы о том, хорошо ли это работает.

Ответ №1:

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

Комментарии:

1. В прошлом году я написал учебник по ELMAH, который, как мне кажется, описывает этот сценарий более подробно, чем статья CodeProject.

Ответ №2:

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

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

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

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

Ответ №3:

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

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

Комментарии:

1. Я был вынужден использовать журнал MS Enterprise Library для проекта около года назад. Он был очень запутанным и, я не могу вспомнить точных деталей, но в нем отсутствовала некоторая минимальная функциональность, которую можно было бы ожидать в решении для ведения журнала. Существует надстройка для Visual Studio, которая является практически единственным способом правильной настройки web.config. Этот инструмент переформатирует ваш web.config и удалит из него все комментарии 🙁

Ответ №4:

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

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

Ответ №5:

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

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

Ответ №6:

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

Ответ №7:

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

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