Почему существует уровень TRACE, и когда я должен использовать его, а не DEBUG?

В Log4J, Slf4J и нескольких других средах ведения журналов в Java у вас есть два уровня «разработки» для ведения журнала:

• DEBUG
• TRACE

Я понимаю, что делает DEBUG, потому что объяснение ясно:

Уровень DEBUG обозначает детализированные информационные события, которые наиболее полезны для отладки приложения.

Но уровень TRACE не очень конкретен в отношении его варианта использования:

Уровень TRACE обозначает более детальные информационные события, чем DEBUG.

(Источник: log4J JavaDoc )

Это не говорит мне, как и когда использовать TRACE. Интересно, что это не уровень серьезности, определенный в стандарте системного журнала . Похоже, что поиск в Google различий между TRACE и DEBUG возвращает «используйте DEBUG, о, да и TRACE тоже есть». Я не смог найти конкретный вариант использования для уровня TRACE. Лучшее, что я мог найти, была эта старая вики-страница, обсуждающая достоинства существования уровня.

Это, как архитектор, вызывает много вопросов и вопросов в моей голове. Если бы молодой разработчик попросил меня добавить TRACE в мою архитектуру, я бы засыпал его вопросами:

• Каковы некоторые примеры информации, которая должна регистрироваться с TRACE, а не с DEBUG?
• Какую конкретную проблему я решаю, регистрируя эту информацию?
• В этих примерах, каковы свойства регистрируемой информации, которая четко различает журналирование на уровне TRACE, а не на уровне DEBUG?
• Почему эта информация должна проходить через инфраструктуру журналов?
  • Каковы преимущества сохранения этой информации в журналах журналов, а не просто использования System.out.println?
  • Почему для этого лучше использовать log, а не отладчик?
• Что будет каноническим примером регистрации на уровне TRACE?
  • Каковы конкретные выгоды, которые были получены путем регистрации на уровне TRACE вместо DEBUG в этом примере?
  • Почему эти выгоды важны?
  • И наоборот: каких проблем я избежал, зарегистрировав их в TRACE вместо DEBUG?
  • Как еще я мог решить эти проблемы? Почему регистрация на уровне TRACE лучше, чем в других решениях?
• Должен ли оператор уровня TRACE оставаться в производственном коде? Почему?

Но учитывая, что он присутствует в большинстве основных структур, я предполагаю, что это полезно для чего-то? Итак ... для чего нужна TRACE, и чем она отличается от DEBUG?

Каков пример информации, которая должна регистрироваться с TRACE, а не с DEBUG?

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

В общем, трассировка будет включать в себя всю отладку (так же, как отладка включает все предупреждения и ошибки).

Какую конкретную проблему я решаю, регистрируя эту информацию?

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

В этих примерах, каковы свойства регистрируемой информации, которая четко различает журналирование на уровне TRACE, а не на уровне DEBUG?

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

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

Почему эта информация должна проходить через инфраструктуру журналов?

Это не обязательно. Некоторые фреймворки имеют отдельный трассировщик.

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

Почему для этого лучше использовать log, а не отладчик?

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

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

Обратите особое внимание, что slf4j особенно рекомендует не использовать трассировку ( http://slf4j.org/faq.html#trace ):

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

Лично я ожидал, что для трассировки будет записано все (например, что-то вроде «введенная функция MyFunc с аргументами A, B, C в момент Y»). Недостатком этого является то, что он не только невероятно шумный, но и вызывает проблемы с дисковым пространством; Я ожидаю, что такая регистрация будет отключена во время нормальной работы. Положительным моментом является то, что это дает вам уровень информации, аналогичный тому, который вы получили бы при пошаговом выполнении вашей программы в тех случаях, когда подключение отладчика может быть менее практичным.

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

Уровни отладки в целом являются произвольными и могут варьироваться в зависимости от языка, библиотеки и компании.

Это, как говорится, вот как я видел, как они использовали:

TRACE: используется для отображения хода выполнения программы на логическом уровне. Ввели функцию? Выбрал ли оператор «if» основную или «другую» ветку? Это кандидат на след. Другими словами, ведение журнала трассировки обычно используется для указания «вы здесь». Это полезно в контексте другого оператора регистрации, который может регистрировать ошибку или другую информацию. Регистрация трассировки может помочь точно определить местоположение в коде ошибки или другого события, зарегистрированного на другом уровне.

DEBUG: используется для выгрузки состояния переменной, определенных кодов ошибок и т. Д. Например: веб-служба может вернуть код ошибки 809214, который может быть зарегистрирован, пока приложение сообщает пользователю «сбой связи». Представьте, что разработчик получает журнал из системы пользователя задолго до возникновения ошибки и задается вопросом « почему произошел сбой?» это хорошая вещь для входа на уровне отладки. Другим примером может быть, если ошибка продолжает возникать в производственной среде, но ее трудно воспроизвести, отладьте журнал определенных переменных или событий в проблемном модуле, чтобы помочь разработчикам сообщить о состоянии программы при возникновении ошибки, чтобы помочь в устранении неполадок.

Обычно можно настроить приложение для регистрации на заданном уровне (или выше). Например, трассировка часто является самым низким уровнем: ведение журнала на этом уровне регистрирует все. Уровень отладки пропускает трассировку, но включает высокие уровни (например, предупреждения и ошибки).

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

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

Я думаю, что превосходный ответ Теластина можно обобщить на мое краткое эмпирическое правило:

• DEBUG регистрация должна быть в состоянии использоваться в производстве (но все еще имеет тенденцию быть выключенной обычно)
• TRACE Ведение журнала допускается таким образом, что его использование в производстве (кроме определенного / короткого сеанса) невозможно

Вот мое эмпирическое правило

error   you need        to do something
warn    you might need  to do something
info    you need        to log this in production
debug   you might need  to log this in production
trace   everything that is happening (no performance concerns)

Предполагается, что команда OPS будет

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

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

Проблема № 1) не слишком сильно замедляет производительность

debugрешает № 1. Именно вы, как разработчик, делаете все возможное, чтобы сбалансировать информацию, которая может вам понадобиться при производстве, и не слишком сильно шуметь, вы замедляете работу машины. Вы говорите: «Это хорошая идея - постоянно регистрировать это на производстве (если хотите)».

Задача № 2) иметь подробную информацию при разработке

traceрешает проблему № 2. Вы абсолютно не заботитесь о том, какое влияние это окажет на производственную машину, но вам нужна эта информация прямо сейчас при разработке кода. Вы говорите: «Я не обещаю, что это хорошая идея - всегда вносить эту информацию в производство».

Конечно (как уже говорили другие), эти вещи являются произвольными; так что просто убедитесь, что ваша команда разработчиков (и команда ops / мониторинга - потому что они также являются пользователями вашей системы регистрации) согласны с чем-то.

Что будет каноническим примером регистрации на уровне TRACE?

ВХОД / ВЫХОД журналы из метода. Эти журналы помогают вам отслеживать ход выполнения программы и имеют тенденцию быть очень полезными, когда:

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

2. Некоторые мошеннические функции не работают, поглощая исключение

Они гарантируют отдельный уровень TRACE, а не просто использование DEBUG, потому что включение журналов ENTRY / EXIT для каждого метода в вашей кодовой базе приведет к созданию огромного количества дополнительных журналов, которые необоснованно всегда включать , даже в контексте DEBUG.