Подтвердить что ты не робот

Трассировка против регистрации и как в нее входит log4net?

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

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

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

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

У меня есть следующий метод на моем бизнес-уровне, и я хочу добавить к нему журнал/трассировку. Мне интересно, как это сделать эффективно. Является ли следующий метод приемлемым с точки зрения регистрации/трассировки? Должны ли сообщения журнала иметь тип Info вместо Debug? Являются ли сообщения 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");
   }
}

4b9b3361

Ответ 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+ существует также более полная система ведения журнала под названием "Мониторинг работоспособности".

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");
    }
}

Ответ 2

IMO...

Logging должен не быть предназначен для разработки отладки (но это неизбежно используется таким образом)
Каротаж должен быть спроектирован для оперативного мониторинга и устранения неисправностей - это его raison dêtre. Трассировка должна быть разработана для разработки отладки и настройки производительности. Если это доступно в полевых условиях, это может быть полезно для действительно низкоуровневых операционных сбоев, но это не является его основной целью

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

Ответ 3

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

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

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

<level value="INFO" />

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

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

Ответ 4

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

Ответ 5

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

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

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

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

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

Ответ 6

logging!= отладка

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

Ответ 7

Также рассмотрите, какая информация регистрируется или отслеживается. Это особенно актуально для информации senstive.

Например, хотя обычно бывает нормально записывать сообщение об ошибке

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

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

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

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

Это, конечно, должно быть принудительно проверено и проверено просмотром кода.