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

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

В моей компании у нас был собственный ErrorMailer, ловящий все в мире.Asax Application_Error. Он был «в порядке», но не очень гибкий и настраиваемый.

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

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

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

8 ответов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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