Slf4j настройка логирования в файл

Обновлено: 07.07.2024

  • Open with Desktop
  • View raw
  • Copy raw contents Copy raw contents Loading

Copy raw contents

Copy raw contents

Логирование в Java

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

Слово log , на самом деле, имеет множество значений, например протокол или журнал. Однако обычно все говорят именно лог и производные от него: логирование и логировать.

Хотя правильнее было бы говорить наверное журналирование/протоколирование и вести журнал/протокол соответственно.

Но так никто никогда не говорит, конечно ¯\(ツ)/¯

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

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

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

Поэтому "логи всякие нужны, логи всякие важны".

Пришла пора сформулировать требования - чего вообще хотелось бы от логера.

Еще одним важным вопросом на который надо ответить - это что логировать.

Работа приложения - это происходящие в нем события, которые в свою очередь могут быть классифицированы на:

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

Все ли нужно логировать?

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

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

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

С другой стороны, при возникновении проблем, особенно спорадических ошибок, чем больше у вас информации - тем лучше.

Т.е возникает требование управления информацией, которая нам нужна в данный момент, а также форматом ее вывода.

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

Уровень логирования - это разделение событий по приоритетам, по степени важности. Например, error - пишем ошибки, debug - пишем более подробно в лог и т.д.

Если проиллюстрировать это:

Уровни логирования

Принципы и понятия

В основе большинства библиотек логирования лежат три понятия: logger , appender и layout .

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

Логер - это объект, область ответственности которого - вывод данных в лог и управление уровнем (детализацией) этого вывода.

Логер создается с помощью фабрики и на этапе создания ему присваивается имя. Имя может быть любым, но по стандарту имя должно быть сопряжено с именем класса, в котором вы собираетесь что-то логировать:

Это дает нам имя логера в виде: ru.aarexer.example.SomeClass .

Почему так рекомендуется делать?

Потому что важным свойством логгеров является то, что они организованы иерархично. Каждый логгер имеет имя, описывающее иерархию, к которой он принадлежит. Разделитель – точка. Принцип полностью аналогичен формированию имени пакета в Java .

Получается выстраивается следующая иерархия логеров:

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

При этом во главе иерархии логеров всегда стоит некотрый дефолтный рутовый(корневой) логер.

Поэтому у всех логеров будет уровень логирования, даже если явно мы не прописали для ru.aarexer.example.SomeClass его, то он унаследуется от рутового.

Вопрос:

Мы установили рутовый уровень в INFO , а ru.aarexer в DEBUG , остальным в иерархии уровень не назначен, т.е:

Логер Назначенный уровень
root INFO
ru Не назначен
ru.aarexer DEBUG
ru.aarexer.example Не назначен

Какой у какого логера будет уровень логирования?

Ответ:

Вспоминаем, что, если уровень логирования не назначен для логера, то он унаследует его от родительского, смотрим на иерархию:

root <- ru <- aarexer <- example

И получаем ответ:

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

Задача логера одна - это вызывать событие, которое приведет к логированию.

Это событие по сути состоит из двух полей:

Аппендер – это та точка, куда события приходят в конечном итоге. Это может быть файл, БД, консоль, сокет и т.д.

Получается у нас есть две точки, первая - это логгер, это начало пути, вторая - аппендер, это уже конечная точка.

Логеры и аппендеры связаны в отношении many-to-many .

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

Логеры при этому наследуют от родительских не только уровни логирования, но и аппендеры.

Например, если к root-логгеру привязан аппендер A1, а к логгеру ru.aarexer – A2, то вывод в логгер ru.aarexer попадет в A2 и A1, а вывод в ru – только в A1.

Вопрос:

Пусть у нас есть несколько аппендеров и логеров

Logger Appender
root А1
ru.aarexer А2
ru.aarexer.example.SomeClass А3

Ответ:

У логеров есть такое свойство как additivity . По умолчанию она установлена в true .

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

Смотрим на иерархию:

root <- ru <- aarexer <- example

Из всего вышесказанного делаем вывод, что событие "hello" с уровнем Level.INFO попадет во все три аппендера.

Но такое наследование аппендеров можно отключить через конфигурацию, для этого стоит посмотреть в сторону выставления флага additivity="false" на логгерах.

Layout - это формат вывода данных.

Теперь пришла пора посмотреть - что вообще есть в Java .

Библиотеки логирования в Java

Ну и самым первым логером, который можно представить себе, был и есть System.out.println и System.err.println . При этом надо помнить, что err и out - это два разных потока вывода, где err вывод не буферизуется и работает быстрее, чем out .

Однако он не отвечает всем тем требованиям, которые мы сформулировали выше, поэтому рассмотрим альтернативы.

Наиболее популярные библиотеки логирования в Java :

  • java.util.logging или JUL , является частью JDK .
  • Apache log4j
  • logback , разработанная создателями log4j
  • Apache log4j2 , продолжение log4j

Это все по сути реализации логеров в Java , ну а мы бы не писали на Java , если бы не попытались сделать нечто объединяющее, чтобы иметь возможность подменять реализации, не изменяя свой код. Некоторый адаптер.

И поэтому появились еще две библиотеки:

  • Apache Commons Logging - JCL
  • Simple Logging Facade for Java - SLF4J

Это самая первая библиотека логирования, появилась еще в 1999 году.

Конфигурируется через xml , либо через properties .

Поддерживает большое количество способов вывода логов: от консоли и файла до записи в БД.

Также имеет поддержку обширного формата логирования: от обычного текстового вывода до html .

Благодаря подобной иерархии лишнее отсекается и поэтому логер работает быстро.

Отсеки лишнее и не думай

Проект сейчас не развивается и по сути заброшен, с версией Java 9 уже не совместим.

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

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

Зачем нужно было изобретать что-то новое, если уже был log4j мне лично не понятно, однако в рамках формирования JSR 47 взяли не log4j , так появился JUL .

Логер включен в стандарт(в рамках JSR 47 ) и поставляется вместе с JDK . JUL имеет следующие уровни логгирования по возрастанию: FINEST , FINER , FINE , CONFIG , INFO , WARNING , SEVERE , а так же ALL и OFF , включающий и отключающий все уровни соответственно.

jul is fine

Чувствуете насколько все переосложнено?

JUL очень похож на log4j , но предоставляет гораздо меньше возможностей.

Так как стандартных средств форматирования логов недостаточно, то все сводилось к тому, что писались свои. Это при том, что log4j предоставлял больший функционал, работал как минимум не медленнее и в целом себя чувствовал хорошо.

Настраивается только с помощью properties .

И вот мы уже имеем два логгера, одни библиотеки использовали log4j , другие jul и это было начало хаоса.

Именно это послужило толчком к созданию Apache Commons Logging или JCL .

Как уже было сказано, JCL - это обертка над log4j и JUL .

Уровни логгирования у JCL совпадают с log4j, а в случае взаимодействия с JUL происходит следующее сопоставление:

Конфигурация JCL содержит отдельные блоки для log4j , JUL и собственной реализации.

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

JCL на данный момент почти никогда не встречается в новых проектах, это довольно старая библиотека, которая встречается разве что в старых legacy -проектах.

С уверенностю можно сказать сейчас, что в эту сторону даже смотреть не стоит. Пациент мертв.

Лицензия Apache License Version 2.0
Последняя версия 1.2
Дата выпуска последней версии июль 2014

Какое-то время все так и существовало, но по мере попытки усидеть на двух стульях происходит раскол и создание log4j2 - на новых идеях, использующая все модные фишки.

При этом она оказывается полностью несовместима с log4j .

Но добавили много нового, парочка из них:

  • Система плагинов, которая позволяет добавить новые appender -ы, layout -ы и т.д
  • Улучшения производительности.
  • Появилась поддержка конфигруаций через json и yaml .
  • Поддержка jmx .

Правда перестали поддерживать properties конфигурации и конфигурации от log4j на xml надо было переписывать заново.

На данный момент рекомендуется использовать именно log4j2 . Однако надо помнить, что Log4j 2 работает только с Java 6+ .

Лицензия Apache License Version 2.0
Последняя версия 2.11.2
Дата выпуска последней версии февраль 2019

Появление нового логера и проблемы JCL послужили появлению slf4j - еще одной обертке.

При этом преобразование параметров в строку и окончательное форматирование лог-записи происходит только при установленном уровне DEBUG .

Лицензия MIT License
Последняя версия 2.0.0-alpha0
Дата выпуска последней версии июнь 2019

logback был сделан разработчиком log4j , поэтому многие фишки перекочевали сразу, а учитывая, что разрабатывался он позже, то старческие болячки log4j обошли.

При этом, logback не является частью Apache или еще какой-то компании и независим.

Может быть сконфигурирован через xml и groovy .

Лицензия EPL/LGPL 2.1
Последняя версия 1.3.0-alpha4
Дата выпуска последней версии февраль 2018

На данный момент это самый мощный логер по количеству предоставляемых возможностей 'из коробки'. Однако, из-за некоторой его обособленности и сложной лицензии многие опасаются его использования и предпочитают log4j или log4j2 .

В данный момент все чаще встречаются проекты, которые выбрали связку SLF4J + Logback .

При этом в версии 1.2.3 стоит явное ограничение на количество файлов, с которым умеет работать логер при ротировании - это трехзначное число, в поздней версии это ограничение убрали.

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

Из минусов logback - это лицензия(LGPL/EPL) и то, что он независимый. Т.е он не принадлежит ни Apache , ни каким-то еще компаниям, а это для некоторых может стать серьезным минусом.

Если минусы для вас существенны, то я бы выбирал log4j2 или log4j .

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

Так как из адаптеров это по сути единственный выбор, да и встречается slf4j все чаще, то стоит рассмотреть его устройство.

Вся обертка делится на две части — API , который используется приложениями, и реализация логера, которая представлена отдельными jar -файлами для каждого вида логирования. Такие реализиации для slf4j называются binding . Например, slf4j-log4j12 или logback-classic .

Достаточно только положить в CLASSPATH нужный binding , после чего — опа! весь код проекта и все используемые библиотеки (при условии, что они обращаются к SLF4J ) будут логировать в нужном направлении.

Вопрос:

А что будет, если в CLASSPATH окажется несколько binding -ов?

Ответ:

SLF4J найдет все доступные binding -и и напишет об этом, после чего выберет какой-то и тоже об этом напишет.

Вот пример поведения slf4j , когда в CLASSPATH оказалось два binding : logback и slf4j-log4j12 :

Что делать при такой ситуации. Если коротко, то надо просто вычистить из CLASSPATH -а все ненужные binding -и и оставить только один.

Т.е вы строите дерево зависимостей проекта, после чего методично вырезаем все, что нам не нужно в CLASSPATH -е.

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

Но это еще не все.

log hell

Например, Spring использует адаптер jcl .

И вот в такой ситуации, чтобы все работало с slf4j используют так называемые bridge -ы.

Что такое bridge ? Это jar -ник, который кладется в CLASSPATH вместо настоящей библиотеки логирования, в этом jar -нике все классы, которые существуют в настойщей библиотеке логирования, но они просто делегируют все события логирования в slf4j .

Таким образом, чтобы работать со Spring получается надо сделать CLASSPATH подобным образом:

Т.е исключить из CLASSPATH уже не нужный нам jcl , после чего добавить bridge , чтобы он перенаправлял все события логирования Spring в slf4j .

Проблемы bridge -а:

Если конфигурация сделана программно, то bridge не будет работать.

Например, log4j-over-slf4j.jar и slf4j-log4j12 в одном CLASSPATH приведут к StackOverflowError .

Если вы внимательно читали то, что мы говорили про bridge , то уже поняли в чем дело: bridge по сути подменяет классы, а подменить классы jdk - нельзя.

Поэтому bridge для jdk логера работает иначе - устанавливается специальный обработчик на root логер, который заворачивает события в slf4j .

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

log final feel

Проблема логирования в Java стоит остро до сих пор. В том, что появилась такая проблема как многообразие логеров и отсутствие какого-то внятного стандарта виноваты все, в том числе и, на мой взгляд, какие-то политические моменты, как например с JSR 47 .

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

Поэтому следите за CLASSPATH , смотрите что вы используете и не разводите log -зоопарк.

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

При этом, если вы разрабатываете библиотеку, то:

  • Не используейте jul .
  • Задумайтесь о том, что нужна ли библиотека логирования, которую вы используете, другим людям как транзитивная зависимость вашей библиотеки?

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

Поэтому нельзя скатываться в бесмысленные записи в лог, вывод личных данных и так далее.

Давайте разберем реальные случаи, в которых логирование решало бы проблему. Вот пример из моей работы. Есть точки приложений, которые интегрируются с другими сервисами. Я использую логирование этих точек для “алиби”: если интеграция не сработает, будет легко разобраться, с какой стороны возникла проблема. Еще желательно логировать важную информацию, которая сохраняется в базу данных. Например создание пользователя администратора. Это как раз то, что хорошо бы логировать.

Инструменты для логирования в Java

  • log4j
  • JUL — java.util.logging
  • JCL — jakarta commons logging
  • Logback
  • SLF4J — simple logging facade for java

System.err.println

Первоначально был, разумеется, System.err.println (вывод записи в консоль). Его и сейчас используют для быстрого получения лога при дебаге. Конечно, говорить о каких-то настройках здесь не приходится, поэтому просто запомним его и пойдем дальше.

Log4j

Это уже было полноценное решение, которое создавалось из потребностей разработчиков. Получился действительно интересный инструмент, который можно использовать. В силу разных обстоятельств это решение так и не попало в JDK, чем очень расстроило все комьюнити. В log4j были возможности по конфигурации таким образом, чтобы можно было включить логирование в пакете com.example.type и выключить его в подпакете com.example.type.generic . Это позволяло быстро отсечь то, что нужно логировать, от того, что не нужно. Здесь важно отметить, что есть две версии log4j: 1.2.х и 2.х.х, которые несовместимы друг с другом. log4j добавил такое понятие как appender, то есть инструмент, с помощью которого записываются логи и layout — форматирование логов. Это позволяет записывать только то, что нужно и как нужно. Больше о appender поговорим чуть позже.

JUL — java.util.logging

Одно из ключевых преимуществ это решения — JUL включен в JDK (Java development kit). К сожалению, при его разработке за основу взяли не популярный log4j, а решение от IBM, что и повлияло на его развитие. По факту на данный момент JUL есть, но им никто не пользуется. Из “такого себе”: в JUL уровни логирования отличаются от того, что есть в Logback, Log4j, Slf4j, и это ухудшает понимание между ними. Создание логгера более менее похожее. Для этого нужно сделать импорт: Имя класса специально передается для того, чтобы знать, откуда идет логирование. Начиная с Java 8, можно передавать Supplier<String> . Это помогает считать и создавать строку только в тот момент, когда это действительно нужно, а не каждый раз, как это было до этого. Только с выходом Java 8 разработчики решили важные проблемы, после чего JUL по-настоящему стало возможно в использовании. А именно, методы с аргументом Supplier<String> msgSupplier , как показано ниже:

JCL — jakarta commons logging

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

Logback

  • улучшена производительность;
  • добавлена нативная поддержка slf4j;
  • расширена опция фильтрации.

SLF4J — simple logging facade for java

Что нужно логировать

  1. Начало/конец работы приложения. Нужно знать, что приложение действительно запустилось, как мы и ожидали, и завершилось так же ожидаемо.
  2. Вопросы безопасности. Здесь хорошо бы логировать попытки подбора пароля, логирование входа важных юзеров и т.д.
  3. Некоторые состояния приложения. Например, переход из одного состояния в другое в бизнес процессе.
  4. Некоторая информация для дебага, с соответственным уровнем логирования.
  5. Некоторые SQL скрипты. Есть реальные случаи, когда это нужно. Опять-таки, умелым образом регулируя уровни, можно добиться отличных результатов.
  6. Выполняемые нити(Thread) могут быть логированы в случаях с проверкой корректной работы.

Популярные ошибки в логировании

  1. Избыток логирования. Не стоит логировать каждый шаг, который чисто теоретически может быть важным. Есть правило: логи могут нагружать работоспособность не более, чем на 10%. Иначе будут проблемы с производительностью.
  2. Логирование всех данных в один файл. Это приведет к тому, что в определенный момент чтение/запись в него будет очень сложной, не говоря о том, что есть ограничения по размеру файлов в определенных системах.
  3. Использование неверных уровней логирования. У каждого уровня логирования есть четкие границы, и их стоит соблюдать. Если граница расплывчатая, можно договориться какой из уровней использовать.

Уровни логирования

  • OFF: никакие логи не записываются, все будут проигнорированы;
  • FATAL: ошибка, после которой приложение уже не сможет работать и будет остановлено, например, JVM out of memory error;
  • ERROR: уровень ошибок, когда есть проблемы, которые нужно решить. Ошибка не останавливает работу приложения в целом. Остальные запросы могут работать корректно;
  • WARN: обозначаются логи, которые содержат предостережение. Произошло неожиданное действие, несмотря на это система устояла и выполнила запрос;
  • INFO: лог, который записывает важные действия в приложении. Это не ошибки, это не предостережение, это ожидаемые действия системы;
  • DEBUG: логи, необходимые для отладки приложения. Для уверенности в том, что система делает именно то, что от нее ожидают, или описания действия системы: “method1 начал работу”;
  • TRACE: менее приоритетные логи для отладки, с наименьшим уровнем логирования;
  • ALL: уровень, при котором будут записаны все логи из системы.

Запись и отправка логов: Appender

  • для записи в файл — решение DailyRollingFileAppender;
  • для получения данных в консоль приложения — ConsoleAppender;
  • для записи логов в базу данных — JDBCAppender;
  • для контроля передачи через TCP/IP — TelnetAppender;
  • для того, чтобы запись логов не била по быстродействию — AsyncAppender.

Узлы логирования

При создании приложений мы часто сталкиваемся с ошибками, которые необходимо отлаживать. Итак, с помощью логов мы можем легко получить информацию о том, что происходит в приложении, с записью ошибок и необычных обстоятельств. Теперь вам может показаться, что почему бы не использовать оператор System.out.print() в Java.

Чтобы избежать таких проблем, логирование в Java упрощается с помощью API, предоставляемого через пакет java.util.logging пакет org.apache.log4j.* .

Компоненты

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

Вы можете обратиться к изображению ниже для работы всех трех компонентов:

Компоненты Logger в Java

Когда приложение выполняет вызов регистрации, компонент Logger записывает событие в LogRecord и перенаправляет его соответствующему Appender. Затем он форматировал запись, используя формат в соответствии с требуемым форматом. Помимо этого, вы также можете использовать более одного фильтра, чтобы указать, какие Appenders следует использовать для событий.

Что такое Логгеры (Logger) в Java?

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

Как создать?

Вы должны использовать Logger.getLogger() . Метод getLogger() идентифицирует имя Logger и принимает строку в качестве параметра. Таким образом, если Logger уже существует, он возвращается, в противном случае создается новый.

Синтаксис

Уровни

Уровни журналов используются для классификации их по степени серьезности или влиянию на стабильность приложения. Пакет org.apache.log4j.* и java.util.logging предоставляют разные уровни ведения журнала.

Пакет org.apache.log4j.* предоставляет следующие уровни в порядке убывания:

Пакет java.util.logging предоставляет следующие уровни в порядке убывания:

  • SEVERE(HIGHEST LEVEL);
  • WARNING;
  • INFO;
  • CONFIG;
  • FINE;
  • FINER;
  • FINEST(LOWEST LEVEL).

Пример с использованием пакета org.apache.log4j.*

Вы также можете установить уровень с помощью метода setLevel() из пакета java.util.logging , как java.util.logging ниже:

Пример с использованием пакета java.util.logging

Чтобы включить вход в приложение с помощью пакета org.apache.log4j.* Или пакета java.util.logging , необходимо настроить файл свойств. Далее в этой статье о Logger в Java давайте обсудим файл свойств обоих из них.

Файл свойств пакета Log4j и Java Util

Пример файла свойств Log4j

  • Файл свойств Log4j создается внутри папки src проекта.
  • log4j.appender.file = org.apache.log4j.RollingFileAppender -> Печатает все журналы в файле
  • log4j.appender.stdout = org.apache.log4j.ConsoleAppender -> Печатает все журналы в консоли
  • log4j.appender.file.File = D: loglogging.log -> Указывает расположение файла журнала
  • log4j.appender.file.MaxFileSize = 10 МБ -> Максимальный размер файла журнала до 10 МБ
  • log4j.appender.file.MaxBackupIndex = 5 -> Ограничивает количество файлов резервных копий до 5
  • log4j.appender.file.layout = org.apache.log4j.PatternLayout -> Указывает шаблон, в котором журналы будут печататься в файл журнала.
  • log4j.appender.file.layout.ConversionPattern =% d % -5p% c :% L -% m% n -> Устанавливает шаблон преобразования по умолчанию.

Пример файла свойств пакета Java Util

  • java.util.logging.FileHandler.pattern =% h / java% u.log -> Файлы журнала будут записаны в C: TEMPjava1.log
  • java.util.logging.FileHandler.limit = 50000 -> Максимальная сумма, которую регистратор записывает в один файл в байтах.
  • java.util.logging.FileHandler.count = 1 -> Указывает количество выходных файлов
  • java.util.logging.FileHandler.formatter = java.util.logging.XMLFormatter -> Упоминает форматер, используемый для форматирования. Здесь используется XML Formatter.
  • java.util.logging.ConsoleHandler.level = WARNING -> Устанавливает уровень журнала по умолчанию для WARNING
  • java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter -> Указывает форматер, используемый всеми ConsoleHandler. Здесь используется SimpleFormatter.

Способ 1

Способ 2

Чтобы убедиться, что Logger регистрирует только события, которые находятся на уровне или выше уровня INFO, вы можете использовать метод setLevel(), описанный выше.

Appender или Handlers

Appender можно отключить с помощью метода setLevel (Level.OFF). Два наиболее стандартных обработчика в пакете java.util.logging :

Layout или Formatters

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

SLF4J расшифровывается как S реализует F академию для J ava. Он обеспечивает простую абстракцию всех каркасов логирования в Java. Таким образом, он позволяет пользователю работать с любой из сред ведения журналов, таких как Log4j, Logback и JUL (java.util.logging), используя единственную зависимость. Вы можете перейти на необходимую инфраструктуру ведения журналов во время выполнения / развертывания.

Ceki Gülcü создал SLF4J в качестве альтернативы каркасу регистрации в Джакарте.

Slf4j Api Jar

Преимущества SLF4J

Используя платформу SLF4J, вы можете перейти на желаемую платформу журналирования во время развертывания.

Slf4J обеспечивает привязки ко всем популярным средам ведения журналов, таким как log4j, JUL, Simple logging и NOP. Поэтому вы можете переключиться на любую из этих популярных платформ во время развертывания.

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

SLF4J предоставляет простой инструмент Java, известный как мигратор. Используя этот инструмент, вы можете перенести существующие проекты, которые используют каркас ведения журнала, например, Jakarta Commons Logging (JCL) или, log4j или Java.util.logging (JUL) в SLF4J.

Используя платформу SLF4J, вы можете перейти на желаемую платформу журналирования во время развертывания.

Slf4J обеспечивает привязки ко всем популярным средам ведения журналов, таким как log4j, JUL, Simple logging и NOP. Поэтому вы можете переключиться на любую из этих популярных платформ во время развертывания.

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

SLF4J предоставляет простой инструмент Java, известный как мигратор. Используя этот инструмент, вы можете перенести существующие проекты, которые используют каркас ведения журнала, например, Jakarta Commons Logging (JCL) или, log4j или Java.util.logging (JUL) в SLF4J.

Обзор каркаса логирования

Каркас регистрации обычно содержит три элемента:

лесоруб

Formatter

укротитель

Некоторые платформы объединяют элементы logger и appender для ускорения операций.

Объект Logger

Уровень опасности

Серьезная проблема, которая приводит к завершению приложения.

Ошибки во время выполнения.

ПРЕДУПРЕЖДЕНИЕ

В большинстве случаев ошибки связаны с использованием устаревших API.

События, которые происходят во время выполнения.

Информация о потоке системы.

Более подробная информация о работе системы.

Серьезная проблема, которая приводит к завершению приложения.

Ошибки во время выполнения.

ПРЕДУПРЕЖДЕНИЕ

В большинстве случаев ошибки связаны с использованием устаревших API.

События, которые происходят во время выполнения.

Информация о потоке системы.

Более подробная информация о работе системы.

Что такое log4j?

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

Сравнение SLF4J и Log4j

В отличие от log4j, SLF4J ( S реализует язык для J ava) не является реализацией каркаса логирования, это абстракция для всех тех каркасов логирования в Java, аналогичных log4J . Таким образом, вы не можете сравнить оба. Однако всегда трудно выбрать один из двух.

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

Обратите внимание на следующую диаграмму для лучшего понимания.

заявка

В этой главе мы объясним, как настроить среду SLF4J в Eclipse IDE. Прежде чем продолжить установку, убедитесь, что в вашей системе уже установлен Eclipse. Если нет, скачайте и установите Eclipse.

Для получения дополнительной информации об Eclipse, пожалуйста, обратитесь к нашему учебному пособию по Eclipse.

Шаг 1: Загрузите JAR-файл зависимости

Откройте официальную домашнюю страницу сайта SLF4J и перейдите на страницу загрузки.

SLF4J Домашняя страница

Теперь загрузите последнюю стабильную версию slf4j-XXtar.gz или slf4j-XXzip в соответствии с вашей операционной системой (если это файл .zip для Windows или файл tar.gz для Linux).

В загруженной папке вы найдете slf4j-api-XXjar . Это необходимый файл Jar.

Шаг 2: Создайте проект и установите путь сборки

Откройте затмение и создайте пример проекта. Щелкните правой кнопкой мыши по проекту, выберите опцию Build Path → Configure Build Path…, как показано ниже.

Проект и установить путь сборки

Во фрейме пути сборки Java на вкладке « Библиотеки » нажмите « Добавить внешние JAR-файлы».

Путь сборки Java

Выберите загруженный файл slf4j-api.xxjar и нажмите « Применить и закрыть» .

Применить и закрыть

SLF4J Привязки

В дополнение к файлу slf4j-api.xxjar , SLF4J предоставляет несколько других файлов Jar, как показано ниже. Это так называемые привязки SLF4J .

SLF4J Привязки

Где каждая привязка для соответствующей структуры ведения журнала.

В следующей таблице перечислены привязки SLF4J и соответствующие им каркасы.

SLF4J-NOP-xxjar

Нет операции, удаляет все записи.

SLF4J-простой xxjar

SLF4J-JCL-xxjar

Каркас лесозаготовок Джакарты.

SLF4J-jdk14-xxjar

Java.util.logging Framework (JUL).

SLF4J-log4j12-xxjar

Каркас Log4J работает. Кроме того, вам нужно иметь log4j.jar .

SLF4J-NOP-xxjar

Нет операции, удаляет все записи.

SLF4J-простой xxjar

SLF4J-JCL-xxjar

Каркас лесозаготовок Джакарты.

SLF4J-jdk14-xxjar

Java.util.logging Framework (JUL).

SLF4J-log4j12-xxjar

Каркас Log4J работает. Кроме того, вам нужно иметь log4j.jar .

Чтобы заставить SLF4J работать вместе с slf4l-api-xxjar, вам нужно добавить соответствующий Jar-файл (привязку) желаемой среды логгера в путь к классам проекта (установить путь сборки).

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

Pom.xml для SLF4J

Если вы создаете проект maven, откройте файл pom.xml, вставьте в него следующее содержимое и обновите проект.

В этой главе мы обсудим классы и методы, которые мы будем использовать в последующих главах этого урока.

Читайте также: