Использование уровней log4J

Как лучше всего использовать уровни log4j при кодировании. Я имею в виду, когда мы используем ведение журнала INFO, когда мы используем ведение журнала DEBUG / ведение журнала ERROR и т. д.


log4j
person Eager Learner    schedule 30.12.2009    source источник
comment
довольно субъективно. Возможно, вики-сообщество было бы уместно?   -  person bmargulies    schedule 30.12.2009

Ответы (8)


arrow_upward
7
arrow_downward

Лучший способ учиться — на примере. Прочтите исходный код некоторых вещей с открытым исходным кодом, например, Tomcat или что-то еще в области вашего приложения, и посмотрите, что вы видите.

person bmargulies    schedule 30.12.2009
comment
Hibernate на самом деле не такой уж хороший справочник для этой IMO, см., Например, ссылку в моем ответе. Я думаю, весна хороший пример, а также кварц, ось2 и подобные проекты - person Yoni; 31.12.2009

arrow_upward
18
arrow_downward

В целом я придерживаюсь следующих рекомендаций:

  • DEBUG: низкоуровневый материал. попадание в кеш, промах кеша, открытие соединения с БД
  • ИНФОРМАЦИЯ : события, имеющие деловое значение: создание клиентов, взимание платы...
  • ПРЕДУПРЕЖДЕНИЕ: это может быть проблемой, но это не остановит ваше приложение. адрес электронной почты не найден / недействителен
  • ОШИБКА: непредвиденная проблема. не удалось открыть соединение с БД. так далее...
person Mike Valenty    schedule 30.12.2009
comment
log4j также имеет уровень FATAL. и уровень TRACE. Для log4j2 см. эту страницу< /а> - person D.B.; 08.10.2016

arrow_upward
10
arrow_downward

Я всегда исходил из того, что уровень INFO эквивалентен System.out, а ERROR эквивалентен System.err.

ОТЛАДКА. Здесь вы размещаете всю информацию об отслеживании, и особенно информацию, которую вы не хотите видеть, когда ваш «уровень комфорта» — system.out.

ИНФОРМАЦИЯ — используйте это для общих сообщений, сообщений о ходе выполнения, для сообщений, связанных с приложением, но не для отслеживания.

ПРЕДУПРЕЖДЕНИЕ — оповещения о том, что что-то пошло не так, возможно неожиданное, или что используется обходной путь, но приложение все еще может продолжать работу (тайм-аут сокета/повторные попытки, неверный ввод данных пользователем и т. д.).

ОШИБКА — оповещения о проблемах, которые мешают нормальной работе вашего приложения, например. база данных не работает, отсутствует конфигурация начальной загрузки.

Распространенной ошибкой при написании библиотек является использование уровня ERROR для обозначения проблем с вызывающим приложением (кодом, использующим библиотеку) вместо указания реальных ошибок в самой библиотеке. См., например, эту ошибку гибернации -> http://opensource.atlassian.com/projects/hibernate/browse/HHH-3731

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

Все — я не использую этот вариант, он практически такой же, как DEBUG или TRACE.

person Yoni    schedule 31.12.2009
comment
Кроме того, NHibernate использует уровень INFO для регистрации каждого генерируемого оператора SQL, что раздражает, поскольку я обычно оставляю INFO включенным по умолчанию в производственных системах. Это должно быть DEBUG ИМХО. - person Andy; 21.05.2012
comment
Я согласен со списком значений, но у меня совсем другое понимание System.out/err (который основан на Unix-оболочке: out предназначен для вывода, на который надеялся пользователь, а err — это то, что может помочь, если приложение ведение журнала требует исправления. Таким образом, все выходные данные log4j являются данными System.err; приложения командной строки отправляют свои данные System.out в System.out; веб-приложения отправляют свои данные System.out в Интернет. ответ DTO). Возможно, было бы лучше просто удалить или проигнорировать абзац My baseline. - person jackr; 26.01.2018

arrow_upward
2
arrow_downward

Несмотря на то, что этот вопрос довольно старый, это действительно важный момент, который должен знать каждый разработчик, я настоятельно рекомендую вам проверить официальную страницу Apache log4j.

Также я нашел полезное изображение, которое прекрасно описывает это, log4jImage взято с сайта supportweb.cs.bham.ac.uk/documentation/tutorials/docsystem/build/tutorials/log4j/log4j.html

person MadMad666    schedule 15.12.2011

arrow_upward
2
arrow_downward

TRACE: наименьший уровень журнала. Обеспечивает наиболее подробный уровень информации.

DEBUG: отчет журнала здесь предназначен для помощи разработчикам. Подробное состояние вашего приложения.

INFO: общая бизнес-информация. Прогресс и состояние вашего приложения

ПРЕДУПРЕЖДЕНИЕ: предупреждения о непредвиденных событиях. Они не настолько серьезны, чтобы прервать вашу заявку.

ОШИБКА: серьезные проблемы в приложении.

Также не менее важно включение правильного уровня ведения журнала в различных средах.

person Showdawn    schedule 19.08.2014

arrow_upward
0
arrow_downward

Регистрация ERROR всегда должна быть включена.

INFO + DEBUG должен быть включен при отслеживании проблем/ошибок.

person Mitch Wheat    schedule 30.12.2009
comment
Имеет ли он в виду «использовать», как в «включить», или «использовать», как в «что мне звонить, когда»? - person bmargulies; 30.12.2009
comment
Спасибо за ответ. Из вашего ответа я прочитал, что ERROR — это уровень, который следует использовать в производстве, а INFO/DEBUG необходимо установить в зависимости от требований в случае устранения неполадок. Уточните, пожалуйста, прав ли я. - person Eager Learner; 30.12.2009

arrow_upward
0
arrow_downward

К тому, что упоминали другие, я бы добавил уровни TRACE и FATAL, первый хорош для очень подробного ведения журнала, а последний указывает на полную остановку шоу. Существуют общие рекомендации по использованию уровней, как упоминалось выше. Однако самым важным является то, как ВЫ будете его использовать и как ваши ПОЛЬЗОВАТЕЛИ будут его интерпретировать. Вам нужны уровни, чтобы сосредоточиться на проблемах, поэтому решите, в чем проблема в вашем случае. Вашим пользователям вряд ли когда-либо понадобятся операторы трассировки или отладки, но они определенно захотят выявить проблемы и сообщить о них вам.

person Dima    schedule 09.01.2010

arrow_upward
0
arrow_downward

Вот несколько рекомендаций, которые я использую:

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

  • ОТЛАДКА: журналирование, предназначенное только для разработчиков: содержимое переменных, результаты сравнений и другая информация, помогающая отлаживать бизнес-логику.

  • ИНФОРМАЦИЯ: информация высокого уровня, такая как задача X, теперь завершена или какое-то правило выполнено, и вот что я собираюсь делать дальше из-за этого правила.

  • ПРЕДУПРЕЖДЕНИЕ: проблема может быть, но она недостаточно серьезна, чтобы причинить реальный вред бизнес-логике. Например, может быть, какая-то переменная иногда будет нулевой, но нам это не обязательно нужно, или мы можем как-то обойти это. В то же время мы все еще хотим знать об этом на случай, если позже нам скажут, что нам нужно найти примеры этого или более тщательно исследовать, почему это происходит.

  • ОШИБКА. Серьезная проблема, которую определенно необходимо исследовать, но она не настолько серьезна, чтобы помешать приложению выполнить поставленную задачу.

  • FATAL: очень серьезная непредвиденная проблема, которую мы не можем обойти или исправить, и которая может даже помешать приложению сделать что-то полезное.

person D.B.    schedule 08.10.2016