Добавил пользователь Alex
Обновлено: 04.10.2024

Логгирование в Java с помощью java.util.logging

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

С помощью классов расположенных в java.util.logging вы легко можете добавить протоколирование (запись логов/логгирование) в Java. Причём вы можете управлять форматом вывода (XML/HTML/сокеты и т. д.).

Посмотрите на пример простой программы с записью лога:

Как видите ничего сложного тут нет. Вы просто создаёте (или получаете, если он уже создан) экземпляр класса java.util.logging.Logger. Потом пишите лог с его помощью.

Приведённый выше пример пишет лог в файл LogApp. Если вы его откроете (В Linux он будет располагаться где-то в /tmp/LogApp), то увидите следущий текст:

По крайней мере у меня получился именно такой файл.

Запись лога в формате HTML. Пишем свой java.util.logging.Formatter

А что делать, если хочется лог в формате HTML? Всё очень просто. Вам нужно написать ещё один небольшой класс, отнаследовав его от java.util.logging.Formatter и переопределить в нём методы getHead, getTail и format:

Теперь нужно указать логгеру в какой файл выводить информацию с помощью этого HtmlFormatter. Наш класс LogApp станет выглядеть следующим образом (изменённая часть выделена красным цветом):

Наше приложение содержит следующие ветки, очень часто встречающиеся во многих web-приложениях:

Очень важно, чтобы вы понимали, что данное приложение является очень тривиальным. Единственная его цель в этой статье – это помочь вам научиться работать с log4j. Вы вправе спросить, почему было выбрано именно web-приложение, а не обычное Java-приложение. Все просто. На сегодняшний день очень многие web-приложения используют предпочтительно механизм журналирования именно на основе log4j. В свою очередь среди обычных Java-приложений процент несколько ниже, но популярность log4j стремительно растет, что не удивительно.

Настройка

Чтобы использовать классы log4j в своем приложении, вам необходимо добавить в CLASSPATH вашего приложения файл log4j-1.2.4.jar. Этот файл, как уже было упомянуто ранее, находится в директории dist/lib. В случае с нашим примером web-приложения, необходимо чтобы этот файл располагался внутри .jar-архива этого приложения, в директории WEB-INF/lib. Это все что необходимо, чтобы наше приложение могло работать с log4j API. Остальные усилия нужно приложить лишь для написания конфигурационного файла, который будет определять для log4j что, куда и как нужно журналировать, а также для вставки выражений в код самого приложения, которые непосредственно будут журналировать события.

Что такое Logger?

Прежде чем приступить к рассмотрению кусков кода нашего web-приложения, давайте разберем основные понятия в log4j. Log4j имеет три базовые составляющие: logger (журналирующий элемент), appender (элемент, определяющий куда нужно журналировать) и layout (представление в котором будет производится журналирование). Для удобства мы так и будем их называть на протяжении всей статьи. Logger берет на себя функцию журналирования какого-либо события в место назначения, определяемое элементом appender, в специально определенном формате, который задается элементом layout.

Logger можно представлять себе, как компонент некого приложения, который будет принимать и выполнять ваши запросы на запись каких-либо событий в регистрационный журнал, представленный файлом, базой данных, консолью и т.д. (определяется appender’ом). Каждый класс вашего приложения может иметь свой собственный logger или же быть привязанным к общему logger’у. Log4j предусматривает корневой logger, от которого будут наследоваться все создаваемые вами объекты этого типа. Это значит, что если у вас не предусмотрен для каждого объекта свой logger, то вы всегда сможете воспользоваться корневым, с помощью метода Logger.getRootLogger(), однако так поступать не рекомендуется.

Для того чтобы создать logger и использовать его для журналирования каких-либо событий, возникающих в этом классе, вам в самом просто случае необходимо вызвать статический метод класса Logger, который получит за вас этот объект по указанному имени. Если такой объект на данный момент еще не существует, он будет создан. Но нужно учесть, что в любой момент времени может существовать только один экземпляр объекта logger’а с одним и тем же именем.

Logger’ы обязательно должны знать куда им нужно слать ваши запросы на запись событий. Эта функция ложится непосредственно на плечи элементов appender. Log4j поддерживает запись в файлы (FileAppender), на консоль (ConsoleAppender), в базы данных (JDBCAppender), в журнал событий операционных систем семейства Windows NT/2000/XP (NTEventLogAppender), на SMTP-сервера (SMTPAppender), на удаленные сервера (SocketAppender) и не только. Таким образом, понятно, что appender определяет место, куда нужно журналировать события. Так, например, если мы привяжем JDBCAppender к одному из наших logger’ов, это будет означать для log4j, что все запросы на журналирование событий, поступающих от этого logger’а, будут записываться в определенную базу данных с заданными параметрами (URL, имя пользователя, пароль и т.д.). Эти параметры являются свойствами объектов элементов типа appender (в данном случае JDBCAppender).

Итак, logger’ы и appender’ы занимаются созданием и направлением наших запросов на журналирование. А что насчет формата вывода? Тут в игру вступают элементы layout. Эти элементы определяют стиль и содержание выводимых в журнал записей. Log4j предоставляет несколько предопределенных layout’ов. Однако вы можете без проблем создать свой собственный, если возникнет такая необходимость. Элемент layout может определять включать или не включать в выводимые записи дату и время, включать ли информацию об используемом для вывода объекте logger, включать или нет информацию о номере текущей строки, в которой был создан этот запрос на журналирование и т.д.

Все элементы logger следуют шаблону отношений типа родитель-потомок. Как упоминалось ранее, log4j предусматривает по умолчанию корневой элемент logger. Отношение типа родитель-потомок также соответствует шаблону именования классов. Это подразумевает, что абсолютно все наши элементы logger будут наследовать корневой элемент. Отношения типа родитель-потомок хорошо просматриваются в шаблоне именования классов. Скажем, у вас есть класс MyClass, который находится в пакете с именем com.foo.bar. Теперь создадим экземпляр элемента logger с именем com.foo.bar.MyClass. В этом случае, logger с именем com.foo.bar.MyClass будет потомком logger’а com.foo.bar, если такой существует. Если же он не существует, то родителем logger’а com.foo.bar.MyClass будет считаться корневой элемент logger (это конечно в случае, если не существует также logger’ов с именами com.foo и com).

Каждому элементу logger в log4j привязывается свой уровень. Если такой уровень не будет привязан к какому-нибудь конкретному элементу, то этот элемент будет автоматически приобретать уровень своего родителя. Даже в случае, если пользователь совсем не будет присваивать никаких уровней, создаваемым им элементам logger, они будут иметь уровень корневого элемента, который по умолчанию равен DEBUG. Таким образом, каждый элемент logger будет гарантированно иметь определенный уровень.

Log4j предусматривает пять уровней журналирования:

Эти уровни определяют также порядок журналирования, которому следует log4j. Об этом ниже.

Каким образом установленный для элемента logger уровень влияет на его функциональность? Все просто. Дело в том, что запрос на занесение в журнал какого-либо события, с помощью определенного элемента appender, из нашего приложения будет выполнен лишь в том случае, если уровень журналируемого события (запроса) не ниже, чем уровень самого элемента logger, через который этот запрос был создан. Это означает, что все запросы, которые мы можем создавать в нашем приложении, могут быть только какого-то одного из этих пяти уровней. Это очень важное правило и, фактически, это является ядром функциональности log4j. Давайте вернемся к нашему предыдущему примеру com.foo.bar.MyClass и попробуем более подробно рассмотреть все, о чем сейчас говорилось.

Основное конфигурирование log4j происходит посредством внешнего конфигурационного файла. API также предоставляет возможность конфигурировать систему log4j и из приложения. Далее мы рассмотрим простой пример приложения и посмотрим, как правильно создавать конфигурационный файл.

Пример использования log4j

Приложение, которое мы собрались рассматривать в качестве примера, содержит пять сервлетов (SetupServlet (стартует при запуске сервлет-контейнера), LogonServlet, GetCommentsServlet, ForgotPasswordServlet, RegisterServlet), четыре JSP-страницы (forgotpassword, logon, register, welcome), а также базу данных в виде файла, в которой хранится информация о пользователях (файл userDB, который должен располагаться в директории WEB-INF; убедитесь, что путь к нему корректно прописан в конфигурационном файле web.xml).

Откройте файл config-simple.properties в вашем любимом текстовом редакторе. Этот файл содержит всего три строчки (не считая комментариев). Первая строка (log4j.rootLogger=debug, R) сообщает log4j, что уровень корневого элемента logger будет DEBUG. Такой уровень для корневого элемента устанавливается по умолчанию, и поэтому эта строчка не обязательна. Однако значение после запятой (R) является обязательным. Оно сообщает log4j, что корневой элемент logger должен быть привязан к элементу appender с именем “R”. Оставшиеся строки в этом файле определяют свойства этого appender’а R.

Теперь, когда мы разобрались с простым примером конфигурационного файла, самое время посмотреть, как происходит журналирование в самом коде приложения. Для начала откройте файл SetupServlet.java в текстовом редакторе и найдите 81 строку:

Пока не обращайте внимания на выражения, находящиеся рядом с этой строкой. Эта строчка сообщает log4j, что требуется найти файл, определенный переменной props и использовать его для установки настроек log4j. Это и есть тот самый файл, который мы только что с вами разобрали, config-simple.properties. Это строка должна выполняться только один раз за всю работу цельного приложения. Обычно она вызывается при старте приложения, а сервлет, вызываемый при старте сервлет-контейнера – это идеальное место для выполнения этого конфигурирования в web-приложении.

На этом мы завершим рассмотрение нашего примера. Давайте еще раз вспомним, что нужно для того, чтобы начать пользоваться log4j в нашем простом примере:

1. Написать конфигурационный файл. В этом файле:

• Определить уровень корневого элемента logger и привязать его к appender’у.
• Определить свойства appender’а.
• Определить layout для этого appender’а.

3. Начать журналирование с помощью методов: log.debug(), log.info(), log.warn(), log.error(), log.fatal().

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

Дополнительные возможности

JDBCAppender

Итак, давайте начнем с того, что откроем файл config-JDBC.properties из нашего приложения. Первое выражение, которое встречается в этом файле, не должно быть вам незнакомым. Так же как и в случае с простым приложением, которое мы рассмотрели ранее, мы устанавливаем уровень корневого элемента logger в DEBUG, и привязываем его к appender’у R. Следующие несколько строчек определяют R, как объект класса JDBCAppender и объявляют его свойства:

Разработчики, которым раньше доводилось работать с JDBC, сразу заметят схожесть между значениями, которые задаются в этом конфигурационном файле и общими параметрами при соединении с базой данных в нормальном JDBC. Это те значения, которые вы должны обязательно задать в любом нормально JDBC-приложении. Вы, безусловно, можете изменить эти значения так, как вам будет нужно. Например, если вы планируете соединяться с сервером баз данных Oracle, то в этом случае URL будет иметь вид, например вот такой: jdbc:oracle:thin:@yourhostSID. Помимо этого нельзя забывать о том, что эти драйвера (JDBC-драйвера к конкретным СУБД) должны быть доступны вашему приложению, чтобы log4j мог корректно выполнять возложенные на него функции.

Если необходимо, вы можете записывать разные значение в разные поля. Например, как в данном выражении:

Это означает, что в нашей базе данных, мы должны определить таблицу JDBCTEST, которая будет содержать поля Date, Logger, Priority и Message.

NDC/MDC

Так каким образом мы сможем различать наших пользователей? Очень просто, мы будем записывать специфичную для каждого из клиентов информацию. Например, в случае с web-приложением, можно включить, помимо прочих вещей, IP-адрес, который всегда можно получить из сервлета. В NDC вы кладете эту информацию в стек, при входе в контекст, и удаляете (получаете) ее из стека при выходе из этого же контекста. Log4j заменяет шаблон %x на специфичную для контекста информацию при записи в свой appender. Этот шаблон нужно использовать в связанном с appender’ом layout’е. Чтобы посмотреть, как это работает, давайте обратимся к конфигурационному файлу config-NDC.properties и файлу GetCommentsServlet.java.

В конфигурационном файле config-NDC вы можете видеть заметные различия по сравнению с предыдущими. Во-первых, в нем определено несколько logger’ов. Первые несколько строк схожи со строками файла config-simple. Для всех остальных logger’ов в нашем приложении, кроме того, который связан с классом GetCommentsServlet, мы хотим, чтобы вывод был связан с консолью и представлен простым layout’ом (SimpleLayout). Для logger’а с именем demo.log4j.servlet.GetCommentsServlet нам нужно иметь свой appender (R1), который также будет выводить информацию на экран, но помимо этого, его шаблон будет содержать символ %x.

Обратите внимание, как мы ссылаемся на logger GetCommentsServlet. На все logger’ы (кроме rootLogger, который обычно именуется как log4j.rootLogger) можно ссылаться при помощи log4j.logger. . Такого типа именование подходит для большинства элементов log4j.

Теперь обратимся к исходному коду класса GetCommentsServlet. Именно в этом классе мы может посмотреть, как реализована работа с добавлением и удалением уникальной информации о клиенте из стека NDC.

Теперь давайте поговорим немного о Mapped Diagnostic Context (MDC). MDC очень многим похож на NDC, но с той лишь разницей, что вместо записи и удаления информации о клиенте из стека, она сохраняется в структуре Map (java.util.Map). Это подразумевает, что каждый кусок специфичной для клиента информации должен сопровождаться каким-либо уникальным ключом. Если вы посмотрите на строку 43 в файле GetCommentsServlet.java, вы увидите, как это реализовано.

В исходном коде:

А в конфигурационном файле добавить следующее:

Пример такого конфигурационного файла вы можете найти в файле config-MDC.properties. Хоть он и схож с файлом config-NDC.properties, но имеет два очень важных отличия. Во-первых, мы используем MDC вместо NDC, а во-вторых, appender для нашего второго logger’а – это RollingFileAppender, вместо ConsoleAppender.

Несколько советов напоследок

ConfigureAndWatch: Вы уже должны знать, что после того, как вы внесли изменения в конфигурационный файл, чтобы эти изменения вступили в силу, необходимо перезапустить сервлет-контейнер. Но это иногда бывает очень обременительно и неудобно. Lo4j предоставляет механизм, с помощью которого он может постоянно отслеживать изменения в конфигурационном файле из вашего приложения. Для того чтобы воспользоваться этой возможностью замените выражение PropertyConfigurator.configure(props); на PropertyConfigurator.configureAndWatch(props);, которое использует значение по умолчанию (60 секунд) в качестве промежутка времени, по истечению которого, нужно проверить, не изменился ли конфигурационный файл. Естественно, что вы без проблем можете изменить это значение, если вам это понадобится.

Заключение

Log4j – это популярный инструмент для журналирования проекта Apache Project. Помимо него существует еще и другие инструменты для журналирования, включая специальный API, встроенный в JDK 1.4. Однако log4j является признанным лидером среди всех существующих инструментов, поскольку позволяет поддерживать беспрецедентный контроль над всеми аспектами журналирования, помимо этого он является иерархическим. Он предоставляет контроль во время выполнения приложения над процессом журналирования, без необходимости вносить какие-либо изменения в исходный код приложения.

Я помню, что когда я работал в последние несколько лет, фреймворк логирования, используемый компанией, все еще был log4j. Примерно с середины 16-го по настоящее время, будь то проект, в котором я участвовал, или проект, возглавляемый мной, фреймворк логирования в основном был заменен логбэком. Подводя итог, логбэк имеет следующие преимущества:

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

Логбэк напрямую реализует slf4j.Строго говоря, это не преимущество, но таким образом, логбэк легко понять, исходя из предпосылки понимания slf4j, и также легко заменить логбэк другими фреймворками логирования.

logback имеет относительно полный документ объемом более 200 страниц

logback При изменении файла конфигурации поддерживается автоматическая перезагрузка файла конфигурации, процесс сканирования выполняется быстро и Безопасность , Нет необходимости создавать поток сканирования

Поддерживает автоматическое удаление старых файлов журнала и может контролировать максимальное количество создаваемых файлов журнала.

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

загрузка с логбэком

Давайте кратко проанализируем процесс загрузки логбэка. Когда мы используем logback-classic.jar и приложение запускается, логбэк будет сканироваться в следующем порядке:

Найдите значение, соответствующее logback.configurationFile, в файле конфигурации системы System Properties.

Найдите logback.groovy в пути к классам (то есть logback поддерживает методы конфигурации groovy и xml)

Найдите logback-test.xml в пути к классам

Найдите logback.xml в пути к классам

Если что-либо из вышеперечисленного обнаружено, последующее сканирование выполняться не будет, и логбэк будет инициализирован в соответствии с соответствующей конфигурацией. Конкретную реализацию кода можно найти в методе findURLOfDefaultConfigurationFile класса ch.qos.logback.classic.util.ContextInitializer.

Если все перечисленные выше четыре элемента не найдены, функция logback вызовет метод configure ch.qos.logback.classic.BasicConfigurator для создания ConsoleAppender для вывода журналов на консоль. Формат вывода журнала по умолчанию - "% d [% thread]% -5level% logger -% msg% n ".

В центре внимания логбэка должны быть Appender, Logger и Pattern. Перед этим давайте вкратце разберемся с логбэка. имеет только три атрибута:

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

scanPeriod: интервал времени для определения того, был ли изменен файл конфигурации. Если единица времени не указана, по умолчанию используются миллисекунды. Это значение вступает в силу, когда scan = true. Временной интервал по умолчанию составляет 1 минуту.

debug: если установлено значение true, он будет распечатывать внутреннюю информацию журнала регистрации и просматривать информацию о запуске logback в реальном времени, по умолчанию false

Начнем с самых простых и .

name: используется для указания пакета или определенного класса, подлежащего этому регистратору

level: используется для установки уровня печати, пять часто используемых уровней печати от низкого до высокого: TRACE, DEBUG, INFO, WARN, ERROR, если этот уровень не установлен, текущий регистратор унаследует уровень вышестоящего

аддитивность: передавать ли информацию о печати вышестоящему регистратору, по умолчанию истинно

также является элементом , но Это корневой регистратор, только с одним атрибутом уровня, потому что его имя - ROOT. , Об этом месте друг спросил в WeChat, исходный код находится в LoggerContext:

Затем напишите фрагмент кода, чтобы проверить это:

Root устанавливает уровень печати на уровень "info", временно игнорируется, вывод консоли:

Обратите внимание на это Имя представляет LoggerFactory.getLogger (XXX.class), путь к пакету XXX, чем меньше путь к пакету, тем больше родительский Наш тестовый код - это Object.class, то есть name = "java" является родительским элементом name = "java.lang", а root является родительским элементом всех s. Посмотрите на результат как:

Этот результат объясняется тем, что:

В не настроен уровень, то есть уровень родительского элемента наследуется, а родительский элемент - , тогда level = debug

Аддитивность не настроена, тогда additivity = true, что означает, что информация о печати этого передается родительскому

Далее настраиваем еще один :

Если вы понимаете приведенный выше пример, то этот пример должен быть легким для понимания:

LoggerFactory.getLogger (Object.class), сначала найдите name = "java.lang" и распечатайте уровень журнала больше или равный предупреждению с помощью "STDOUT"

name = "java.lang" этот не настроен с аддитивностью, тогда additivity = true, печатная информация передается вверх и передается родительскому объекту name = "java"

name = "java" этот имеет additivity = false и не связан ни с одним , тогда name = "java" этот не будет печатать никакой информации

На основе этого анализа окончательный результат печати:

name указывает имя

class указывает полное имя

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

, а здесь используется для определения

. Давайте кратко поговорим об этом:

был введен после версии 0.9.19, в предыдущих версиях использовался , при логбэке настоятельно рекомендуется использовать вместо

Наиболее часто используемый FileAppender и его подклассы предполагают использовать вместо

Давайте поговорим о формате в в следующей части. Затем мы смотрим на FileAppender, Роль FileAppender - записывать журнал в файл. , Пример конфигурации:

Его несколько узлов:

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

указывает выходной формат, который будет описан позже.

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

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

Это метод записи, который указывает только . Роль заключается в определении поведения RollingFileAppender при выполнении прокрутки. TimeBasedRollingPolicy, описанный выше, является наиболее часто используемой стратегией прокрутки. Он определяет стратегию прокрутки на основе времени и отвечает как за прокрутку, так и за прокрутку. За запуск прокрутки отвечают следующие узлы:

, необходимый узел, включая имя файла и символ преобразования "% d", "% d" может включать формат времени, указанный в Java.text.SimpleDateFormat, например% d , если вы используете% d напрямую Формат: гггг-ММ-дд. Дочерний узел файла для RollingFileAppender является необязательным, и для активных файлов и архивных файлов можно указать разные местоположения, установив файл

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

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

Асинхронное ведение журнала

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

Затем мы рассмотрим, как использовать логбэк для конфигурации асинхронной записи журнала:

То есть мы представили AsyncAppender, давайте сначала поговорим о принципе AsyncAppender, а затем поговорим о нескольких параметрах:

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

Из приведенного выше описания мы видим, что AsyncAppender не обрабатывает журналы, а буферизует журналы в BlockingQueue и внутренне создает рабочий поток для получения журналов из заголовка очереди, а затем циклически записывает полученные журналы в дополнительные другие Appender поднимается вверх, чтобы добиться эффекта отсутствия блокировки основного потока. Следовательно, AsyncAppender действует только как перенаправитель событий и должен ссылаться на другой appender для выполнения действий.

Из приведенных выше принципов мы можем более четко понять роль нескольких параметров:

discardingThreshold, если он равен 20, это означает, что, когда остается 20% емкости, события TRACE, DEBUG и INFO будут отброшены, и будут сохранены только события WARN и ERROR. Чтобы сохранить все события, это значение может быть установлено на 0 , Значение по умолчанию - queueSize / 5.

queueSize легче понять, максимальная емкость BlockingQueue, по умолчанию 256

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

Узел отвечает за две вещи:

Преобразование информации журнала в байтовый массив

Записать байтовый массив в выходной поток

В настоящее время PatternLayoutEncoder является единственным полезным кодировщиком по умолчанию. Существует узел

Некоторые доступные параметры показаны в таблице:

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

1. Отсутствие ввода означает вывод полного имени .

2. Введите 0, чтобы вывести только строку после крайней правой точки .

3. Введите другие числа, чтобы указать количество знаков перед точкой в ​​конце десятичной запятой.

Взгляните на результат:

Видно, что хотя настроен с DEBUG, выводится только предупреждение, потому что в ACCEPT (accept) выполняется, когда уровень WARN совпадает, а DENY (deny) выполняется, когда он не соответствует уровню WARN. Конечно, можно распечатать только журналы WARN.

Еще раз посмотрите на ThresholdFilter, который настроен как:

Посмотрите на результат как:

Поскольку стратегия ThresholdFilter заключается в фильтрации всех уровней журнала ниже , хотя уровень DEBUG указан, можно распечатать только уровни INFO и выше.

Если вы считаете, что эта статья полезна для вас, приглашаем всех обратить внимание на мою публичную учетную запись: Java Technology Learning (javajsxxzd) и долго делиться различными техническими статьями.

SLF4J (Simple Logging Facade for Java) — библиотека для протоколирования, ставящая своей целью предоставить максимально простой, но при этом мощный фасад для различных систем протоколирования на Java.

1. Структура каталогов

2. Зависимости

По умолчанию SLF4j уже включен в стартовый пакет Spring Boot

[ INFO ] + - org . springframework . boot : spring - boot - starter - thymeleaf : jar : 1.5.9.RELEASE : compile

[ INFO ] | + - org . springframework . boot : spring - boot - starter : jar : 1.5.9.RELEASE : compile

[ INFO ] | | + - org . springframework . boot : spring - boot - starter - logging : jar : 1.5.9.RELEASE : compile

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

  
• Как сделать скрин в blade and soul
  
• Как сделать таум катану
  
• Как сделать про аккаунт в тик ток
  
• Как сделать квадрат из символов в паскале
  
• Как сделать из гирлянды цифры