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

Ответ 1

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

Ответ 2

В целом, я следую этим рекомендациям:

• DEBUG: материал низкого уровня. кэш, пропустить кеш, открыть соединение db
• INFO: события, имеющие деловое значение - создание клиента, загрузка cc...
• WARN: может быть проблемой, но не останавливает ваше приложение. адрес электронной почты не найден/недействителен
• ОШИБКА: неожиданная проблема. не удалось открыть соединение db. и т.д...

Ответ 3

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

DEBUG. Здесь вы размещаете всю информацию о трассировке и, в частности, информацию, которую вы не хотите видеть, когда ваш уровень комфорта "system.out".

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

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

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

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

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

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

Ответ 4

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

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

Ответ 5

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

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

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

WARN: Предупреждения о неожиданных событиях. Они недостаточно серьезны, чтобы прервать ваше приложение.

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

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

Ответ 6

ОШИБКА ведение журнала всегда должно быть включено.

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

Ответ 7

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

Ответ 8

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

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

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

• INFO: информация высокого уровня, такая как задача X, завершена или выполняется некоторое правило, и вот что я буду делать дальше из-за этого правила.

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

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

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