Трассировка против логирования и как вписывается log4net?

Question

Мне интересно, в чем разница между ведением журнала и трассировкой.

Разница в основном в том, что трассировка - это более подробный журнал, дающий разработчикам инструмент для отладки приложений во время выполнения?

Я экспериментировал с log4net и делал логи. Теперь мне интересно, должен ли я также выполнять трассировку и могу ли я / должен использовать log4net для этой цели. Должен ли я выполнять трассировку с log4net и есть ли какой-то уровень трассировки для логгеров log4net? Должен ли я использовать другой уровень журнала для целей отладки или трассировки, или можно использовать один и тот же? Можете ли вы привести простой пример того, как я буду вести логи и трассировку для простого метода?

Edit: Несмотря на несколько полезных ответов ниже, я все еще не уверен, как мне вести трассировку по сравнению с ведением журнала.

У меня есть следующий метод на моем бизнес-уровне, и я хочу добавить в него логирование / трассировку. Мне интересно, как это сделать эффективно. Является ли следующий метод приемлемым с точки зрения регистрации / отслеживания? Должны ли сообщения журнала иметь тип Info вместо Debug? Считаются ли отладочные сообщения, которые я записываю, трассировкой? Как бы вы изменили это?

IEnumerable<Car> GetCars()
{
   try
   {
      logger.Debug("Getting cars");
      IEnumerable<Car> cars = CarAccessor.GetCars().ConvertAll(DataAccessToBusinessConverter);
      logger.Debug("Got total of " + cars.Count + " cars"); 
   } catch (Exception e) {
      logger.Error("Error when getting cars", e);
      throw new Exception("Unexpected error when getting cars");
   }
}

Answer 1

Ведение журнала - это общий термин для записи информации, а трассировка - это особая форма ведения журнала, используемая для отладки.

В .NET объекты System.Diagnostics.Trace и System.Diagnostics.Debug позволяют вести простой журнал для нескольких «прослушивателей событий», которые можно настроить в app.config. Вы также можете использовать TraceSwitches для настройки и фильтрации (например, между ошибками и информационными уровнями).

private void TestMethod(string x)
{
    if(x.Length> 10)
    {
        Trace.Write("String was " + x.Length);
        throw new ArgumentException("String too long");
    }
}

В ASP.NET есть специальная версия Trace (System.Web.TraceContext), которая записывает в конец страницы ASP или Trace.axd. В ASP.NET 2+ также имеется более полная структура ведения журнала, которая называется Health Monitoring.

Log4Net - более богатый и более гибкий способ трассировки или ведения журнала, чем встроенная трассировка или даже мониторинг работоспособности ASP. Как и Diagnostics.Trace, вы конфигурируете прослушиватели событий («appenders») в config. Для простой трассировки, использование просто, как встроенная трассировка. Решение использовать Log4Net - есть ли у вас более сложные требования.

private void TestMethod(string x)
{
    Log.Info("String length is " + x.Length);
    if(x.Length> 10)
    {
        Log.Error("String was " + x.Length);
        throw new ArgumentException("String too long");
    }
}

Answer 2

IMO ...

Ведение журнала должно , а не быть предназначенным для отладки разработки (но это неизбежно используется таким образом)
Регистрация должна быть рассчитана на оперативный мониторинг и устранение неисправностей - это его смысл.

Трассировка должна быть разработана для отладки разработки и настройки производительности. Если он доступен в полевых условиях, его можно использовать для оперативного устранения неполадок низкого уровня, но это не является его основной целью

Учитывая это, наиболее успешные подходы, которые я видел (и разрабатывал / реализовывал) в прошлом не объединял их вместе. Лучше держать два инструмента раздельно, каждый из которых выполняет одну работу наилучшим образом.

Answer 3

log4net хорошо подходит для обоих. Мы различаем журналирование, которое полезно для диагностики после выпуска, и «отслеживание» в целях разработки с использованием уровня ведения журнала DEBUG. В частности, разработчики регистрируют свои результаты трассировки (вещи, которые представляют интерес только при разработке), используя Debug(). Наша конфигурация разработки устанавливает уровень DEBUG:

<root>
        <level value="DEBUG" />
        ...
</root>

Перед выпуском продукта уровень изменяется на "INFO":

<level value="INFO" />

Это удаляет все выходные данные DEBUG из журнала релизов, но сохраняет INFO / WARN / ERROR.

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

Answer 4

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

Answer 5

Я бы сказал, да. Регистрация - это единственный способ определить, что произошло в прошлом - если клиент звонит и говорит, что что-то не произошло, как ожидалось, без журнала все, что вы можете сделать, это пожать плечами и попытаться воспроизвести ошибку. Иногда это невозможно (в зависимости от сложности программного обеспечения и зависимости от данных клиента).

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

Затем существует протоколирование для отчетов, для которого большинство людей считают, что протоколирование.

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

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

Answer 6

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

Например, хотя в целом может быть нормально регистрировать ошибку с указанием

«Пользователь« X »попытался получить доступ, но был отклонен из-за неправильного пароля»,

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

«Пользователь« X »попытался получить доступ, но был отклонен, поскольку пароль« secret »неверен».

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

Конечно, это должно выполняться и проверяться обзорами кода.

Answer 7

регистрация! = Отладка

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