Какова наилучшая практика использования уровней log4j во время кодирования. Я имею в виду, когда мы используем каротаж INFO, когда мы используем регистрацию журналов DEBUG/ERROR и т. Д.Использование уровней log4J
Лучший способ узнать на примере. Читайте источник некоторых вещей с открытым исходным кодом, например, oh, Tomcat или что-то еще в вашей области приложений, и посмотрите, что вы видите.
Hibernate - еще одна хорошая для справки –
Hibernate на самом деле не такая отличная ссылка для этого IMO, см., Например, ссылку в моем ответе. Я думаю, что весной является хорошим примером, а также кварцем, осью 2 и аналогичными проектами. – Yoni
ОШИБКА регистрация всегда должна быть включена.
INFO + DEBUG должен быть включен при обнаружении проблем/ошибок.
Он имеет в виду «использовать», как в «enable» или «use», как в «который я вызываю когда»? – bmargulies
Хм, хороший момент! –
Спасибо за ответ. Из вашего ответа я прочитал, что ERROR - это уровень, который должен использоваться в производстве, и INFO/DEBUG необходимо установить в зависимости от требований в случае устранения неполадок. Просьба уточнить, насколько я прав. –
В общем, я следую этим правилам:
log4j также имеет уровень [FATAL] (https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/Level.html#FATAL) и [TRACE] (https: // logging. apache.org/log4j/1.2/apidocs/org/apache/log4j/Level.html#TRACE). Для log4j2 см. [Эта страница] (https://logging.apache.org/log4j/2.0/log4j-api/apidocs/org/apache/logging/log4j/Level.html) –
Мой базовый всегда что INFO уровень эквивалентен System.out и ERROR эквивалентно System.err.
DEBUG - Здесь вы размещаете всю информацию о трассировке и, в частности, информацию, которую вы не хотите видеть, когда ваш уровень комфорта «system.out».
INFO - используйте это для сообщений общего доступа, сообщений о выполнении, для сообщений, связанных с приложением, но не для трассировки.
WARN - сообщите, что что-то не так, возможно, неожиданно, или что обходной путь используется, но приложение все равно может продолжаться (тайм-аут сокета/повторные попытки, неверный ввод пользователя и т. Д.).
ОШИБКА - предупреждает о проблемах, препятствующих нормальной работе вашего приложения, например. база данных отсутствует, отсутствует настройка начальной загрузки.
Распространенная ошибка при написании библиотек заключается в использовании уровня ERROR для указания проблем с вызывающим приложением (кодом, использующим библиотеку) вместо указания реальных ошибок внутри самой библиотеки. См. Например, эта ошибка спящего режима ->http://opensource.atlassian.com/projects/hibernate/browse/HHH-3731
Это действительно раздражает, потому что сообщения с уровня ERROR действительно трудно подавить, поэтому используйте их только для указания проблем с вашим собственным кодом.
Все - Я действительно не использую этот, он практически такой же, как DEBUG или TRACE.
Также NHibernate использует уровень INFO для регистрации каждого SQL, который генерирует, что раздражает, поскольку я, как правило, оставляю INFO по умолчанию в производственных системах. Это должно быть DEBUG IMHO. – Andy
Я согласен со списком значений, но у меня совсем другое понимание System.out/err (которое основано на Unix-оболочке: out для «вывода, на который надеялся пользователь», а err - «материал, который может помогите, если приложение, выполняющее регистрацию, нуждается в исправлении ». Таким образом, * all * log4j output - это материал System.err, приложения из командной строки отправляют свои материалы System.out в System.out; webapps отправляет свои материалы System.out в Интернет ответ DTO). Лучше просто удалить или игнорировать абзац «Моя базовая линия». – jackr
К тому, о чем говорили другие, я бы добавил уровни TRACE и FATAL, первый из них хорош для очень подробного ведения журнала, а позднее - для показа общей стоп-шоу. Существуют общие указания о том, как вы используете уровни, как упоминалось выше. Тем не менее, самый важный - это как YOU будет использовать его и как ваши ПОЛЬЗОВАТЕЛИ будут их интерпретировать. Вам нужны уровни, чтобы сосредоточиться на проблемах, поэтому решите, в чем проблема в вашем случае. Вашим пользователям вряд ли когда-либо понадобятся отчеты о трассировке или отладке, но они обязательно захотят прибить проблемы и сообщить о них вам.
Несмотря на этот вопрос довольно старый, это действительно важный момент, который должен знать каждый разработчик, я настоятельно рекомендую вам ознакомиться с официальной страницей Apache log4j.
Кроме того, я нашел и полезный образ, который описывает это прекрасно, log4jImage взяты из supportweb.cs.bham.ac.uk/documentation/tutorials/docsystem/build/tutorials/log4j/log4j.html
TRACE: Минимальный уровень бревен. Обеспечивает наиболее подробный уровень информации.
DEBUG: Заявление о регистрации здесь предназначено для помощи разработчикам. Подробное описание вашего приложения.
INFO: Общая информация о бизнесе. Прогресс и состояние вашей заявки
WARN: Предупреждения о непредвиденных событиях. Они недостаточно серьезны, чтобы прервать ваше приложение.
ОШИБКА: Серьезные проблемы в вашем приложении.
Также важно иметь правильный уровень ведения журнала в разных средах.
Вот некоторые рекомендации, которые я использую:
DEBUG: регистрация, предназначенная только для глаз разработчиков - содержимое переменных, результаты сравнений и другие биты информации, которые помогают отлаживать бизнес-логику.
INFO: информация высокого уровня, такая как задача X, завершена или некоторое правило выполнено, и вот что я буду делать дальше из-за этого правила.
WARN: может возникнуть проблема, но это не является достаточно серьезным, чтобы нанести реальный вред потоку бизнес-логики. Например, возможно, какая-то переменная иногда будет нулевой, но нам это не обязательно, или мы можем как-то ее обойти. В то же время мы все еще хотим знать об этом на всякий случай, когда нам говорят позже, нам нужно найти примеры этого или более тщательно изучить, почему это происходит.
ОШИБКА: Серьезная проблема, которая, безусловно, нуждается в дальнейшем изучении, но недостаточно серьезная, чтобы остановить приложение от выполнения поставленной задачи.
FATAL: Очень серьезная неожиданная проблема, с которой мы не можем работать или восстанавливаться, а может даже препятствовать приложению делать что-то полезное.
довольно субъективно. Возможно, Community Wiki будет уместным? – bmargulies