TOC

Руководство по возврату

1. Обзор

Logback - одна из наиболее широко используемых сред ведения журналов в сообществе Java. Это replacement для его предшественника Log4j. Logback предлагает более быструю реализацию, чем Log4j, предоставляет больше возможностей для конфигурации и большую гибкость в архивировании старых файлов журнала.

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

2. Logback Architecture

Три класса составляют архитектуру Logback; Logger , Appender и Layout .

Регистратор - это контекст для сообщений журнала. Это класс, с которым приложения взаимодействуют для создания сообщений журнала.

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

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

3. Настроить

3.1. Maven Dependency

Logback использует Simple Logging Facade для Java (SLF4J) в качестве собственного интерфейса. Прежде чем мы сможем начать регистрацию сообщений, нам нужно добавить Logback и Slf4j в наш pom.xml : 

<dependency>
    <groupId>ch.qos.logback</groupId>
    <artifactId>logback-core</artifactId>
    <version>1.2.3</version>
</dependency>

<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-api</artifactId>
    <version>1.8.0-beta2</version>
    <scope>test</scope>
</dependency>

Maven Central имеет latest версию ядро обратного входа и https://search.maven.org/classic/#search%7Cgav%7C1%7Cg%3A%22org.slf4j%22%20AND%20a%3A%22slf4j-api%22 ---- последняя версия из slf4j-api ].

3.2. Classpath

Для входа в систему также требуется logback-classic.jar в пути к классам для времени выполнения.

Мы добавим это в pom.xml как тестовую зависимость: 

<dependency>
    <groupId>ch.qos.logback</groupId>
    <artifactId>logback-classic</artifactId>
    <version>1.2.3</version>
</dependency>

4. Базовый пример и конфигурация

Давайте начнем с быстрого примера использования Logback в приложении.

Во-первых, нам нужен файл конфигурации. Мы создадим текстовый файл с именем logback.xml и поместим его где-нибудь в наш путь к классам: 

<configuration>
  <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
    <encoder>
      <pattern>%d{HH:mm:ss.SSS}[%thread]%-5level %logger{36} - %msg%n</pattern>
    </encoder>
  </appender>

  <root level="debug">
    <appender-ref ref="STDOUT"/>
  </root>
</configuration>

Далее нам нужен простой класс с методом main : 

public class Example {

    private static final Logger logger
      = LoggerFactory.getLogger(Example.class);

    public static void main(String[]args) {
        logger.info("Example log from {}", Example.class.getSimpleName());
    }
}

Этот класс создает Logger и вызывает info () для создания сообщения журнала.

Когда мы запускаем Example , мы видим, что наше сообщение занесено в консоль: 

20:34:22.136[main]INFO Example - Example log from Example

Легко понять, почему Logback так популярен; мы бегаем за несколько минут.

Эта конфигурация и код дают нам несколько советов о том, как это работает.

, У нас есть _appender name STDOUT_ , который ссылается на имя класса

ConsoleAppender. , Существует шаблон, который описывает формат нашего сообщения журнала.

, Наш код создает Logger , и мы передали ему сообщение через

info () метод _. _

Теперь, когда мы понимаем основы, давайте ближе рассмотрим.

5. Logger Контексты

5.1. Создание контекста

Чтобы записать сообщение в Logback, мы инициализировали Logger из SLF4J или Logback: 

private static final Logger logger
  = LoggerFactory.getLogger(Example.class);

А потом использовал это: 

logger.info("Example log from {}", Example.class.getSimpleName());

Это наш контекст регистрации. Когда мы создали его, мы передали LoggerFactory наш класс. Это дает Logger имя (есть также перегрузка, которая принимает String) .

Контексты ведения журнала существуют в иерархии, которая очень похожа на иерархию объектов Java:

, ** Логгер является предком, когда его имя, за которым следует точка, ставит префикс

имя потомка , Регистратор является родителем, когда между ним и

ребенок **

Например, класс Example ниже находится в пакете com.baeldung.logback . В пакете com.baeldung.logback.appenders есть еще один класс с именем ExampleAppender .

ExampleAppender’s Logger является дочерним для Example’s Logger.

  • Все регистраторы являются потомками предопределенного корневого регистратора. **

Logger имеет Level, , который можно установить либо с помощью конфигурации, либо с помощью Logger.setLevel () . Установка уровня в коде переопределяет файлы конфигурации.

Возможные уровни в порядке приоритета: TRACE, DEBUG, INFO, WARN и _ERROR . _ Каждый уровень имеет соответствующий метод, который мы используем для регистрации сообщения на этом уровне.

  • Если логгеру не назначен уровень явно, он наследует уровень своего ближайшего предка. ** Корневым логгером по умолчанию является DEBUG. Мы увидим, как переопределить это ниже.

5.2. Использование контекста

Давайте создадим пример программы, которая демонстрирует использование контекста в иерархиях логирования: 

ch.qos.logback.classic.Logger parentLogger =
  (ch.qos.logback.classic.Logger) LoggerFactory.getLogger("com.baeldung.logback");

parentLogger.setLevel(Level.INFO);

Logger childlogger =
  (ch.qos.logback.classic.Logger)LoggerFactory.getLogger("com.baeldung.logback.tests");

parentLogger.warn("This message is logged because WARN > INFO.");
parentLogger.debug("This message is not logged because DEBUG < INFO.");
childlogger.info("INFO == INFO");
childlogger.debug("DEBUG < INFO");

Когда мы запускаем это, мы видим эти сообщения: 

20:31:29.586[main]WARN com.baeldung.logback - This message is logged because WARN > INFO.
20:31:29.594[main]INFO com.baeldung.logback.tests - INFO == INFO

Мы начнем с получения Logger с именем com.baeldung.logback и приведем его к ch.qos.logback.classic.Logger.

Контекст Logback необходим для установки уровня в следующем операторе; обратите внимание, что абстрактный логгер SLF4J не реализует setLevel () .

Мы устанавливаем уровень нашего контекста на INFO ; _ we, затем создаем еще один регистратор с именем com.baeldung.logback.tests._

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

Logback регистрирует сообщения WARN, и INFO и фильтрует сообщения _DEBUG _ .

Теперь давайте используем корневой логгер: 

ch.qos.logback.classic.Logger logger =
  (ch.qos.logback.classic.Logger)LoggerFactory.getLogger("com.baeldung.logback");
logger.debug("Hi there!");

Logger rootLogger =
  (ch.qos.logback.classic.Logger)LoggerFactory.getLogger(org.slf4j.Logger.ROOT__LOGGER__NAME);
logger.debug("This message is logged because DEBUG == DEBUG.");

rootLogger.setLevel(Level.ERROR);

logger.warn("This message is not logged because WARN < ERROR.");
logger.error("This is logged.");

Мы видим эти сообщения, когда выполняем этот фрагмент: 

20:44:44.241[main]DEBUG com.baeldung.logback - Hi there!
20:44:44.243[main]DEBUG com.baeldung.logback - This message is logged because DEBUG == DEBUG.
20:44:44.243[main]ERROR com.baeldung.logback - This is logged.

В заключение мы начали с контекста Logger и напечатали сообщение DEBUG .

Затем мы извлекли корневой логгер, используя его статически определенное имя, и установили его уровень ERROR.

И наконец, мы продемонстрировали, что Logback действительно фильтрует любое утверждение меньше, чем ошибка.

5.3. Параметризованные сообщения

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

Рассмотрим следующее сообщение: 

log.debug("Current count is " + count);

Мы несем расходы на создание сообщения вне зависимости от того, регистрирует ли его регистратор или нет.

Logback предлагает альтернативу с ее параметризованными сообщениями: 

log.debug("Current count is {}", count);

  • Скобки \ {} принимают любой Object и используют его метод toString () для создания сообщения только после проверки необходимости сообщения журнала. **

Давайте попробуем несколько разных параметров: 

String message = "This is a String";
Integer zero = 0;

try {
    logger.debug("Logging message: {}", message);
    logger.debug("Going to divide {} by {}", 42, zero);
    int result = 42/zero;
} catch (Exception e) {
    logger.error("Error dividing {} by {} ", 42, zero, e);
}

Этот фрагмент дает: 

21:32:10.311[main]DEBUG com.baeldung.logback.LogbackTests - Logging message: This is a String
21:32:10.316[main]DEBUG com.baeldung.logback.LogbackTests - Going to divide 42 by 0
21:32:10.316[main]ERROR com.baeldung.logback.LogbackTests - Error dividing 42 by 0
java.lang.ArithmeticException:/by zero
  at com.baeldung.logback.LogbackTests.givenParameters__ValuesLogged(LogbackTests.java:64)
...

Мы видим, как String, int, и Integer могут быть переданы в качестве параметров.

Кроме того, когда Exception передается в качестве последнего аргумента методу ведения журнала, Logback выведет для нас трассировку стека.

6. Подробная конфигурация

В предыдущих примерах мы использовали 11-строчный файл конфигурации, который мы создали по ссылке: #example[section 4]для печати сообщений журнала на консоль. Это стандартное поведение Logback; если он не может найти файл конфигурации, он создает _ConsoleAppender _ и связывает его с корневым регистратором.

6.1. Расположение информации о конфигурации

Файл конфигурации может быть размещен в пути к классам и назван либо logback.xml , либо logback-test.xml.

Вот как Logback попытается найти данные конфигурации:

, Поиск файлов с именами _logback-test.xml, logback.groovy, _ или

logback.xml в пути к классам, в этом порядке.

, Если библиотека не найдет эти файлы, она попытается использовать

в Java ServiceLoader найти разработчика com.qos.logback.classic.spi.Configurator. , Сконфигурируйте себя, чтобы записывать вывод непосредственно на консоль

Примечание: текущая версия Logback не поддерживает конфигурацию Groovy, поскольку версия Groovy не совместима с Java 9

6.2. Базовая конфигурация

Давайте подробнее рассмотрим нашу ссылку: #example[пример конфигурации.]

Весь файл находится в тегах _ <configuration> _ .

  • Мы видим тег, который объявляет Appender типа ConsoleAppender и называет его STDOUT . В этом теге находится кодировщик. У этого есть образец с тем, что похоже на escape-коды sprintf-style : ** 

<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
    <encoder>
        <pattern>%d{HH:mm:ss.SSS}[%thread]%-5level %logger{36} - %msg%n</pattern>
    </encoder>
</appender>

Наконец, мы видим тег root . Этот тег устанавливает корневой регистратор в режим DEBUG и связывает его вывод с Appender с именем STDOUT : 

<root level="debug">
    <appender-ref ref="STDOUT"/>
</root>

6.3. Устранение неполадок конфигурации

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

Чтобы увидеть отладочную информацию, когда Logback обрабатывает конфигурацию, вы можете включить ведение журнала отладки: 

<configuration debug="true">
  ...
</configuration>

Logback распечатает информацию о состоянии на консоль, поскольку это обрабатывает конфигурацию: 

23:54:23,040 |-INFO in ch.qos.logback.classic.LoggerContext[default]- Found resource[logback-test.xml]
  at[file:/Users/egoebelbecker/ideaProjects/logback-guide/out/test/resources/logback-test.xml]23:54:23,230 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender
  of type[ch.qos.logback.core.ConsoleAppender]23:54:23,236 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as[STDOUT]23:54:23,247 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default type
 [ch.qos.logback.classic.encoder.PatternLayoutEncoder]for[encoder]property
23:54:23,308 |-INFO in ch.qos.logback.classic.joran.action.RootLoggerAction - Setting level of ROOT logger to DEBUG
23:54:23,309 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named[STDOUT]to Logger[ROOT]23:54:23,310 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - End of configuration.
23:54:23,313 |-INFO in[email protected]- Registering current configuration
  as safe fallback point

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

Существует второй механизм печати информации о состоянии: 

<configuration>
    <statusListener class="ch.qos.logback.core.status.OnConsoleStatusListener"/>
    ...
</configuration>

  • StatusListener перехватывает сообщения о состоянии и печатает их во время настройки и во время работы программы ** .

Выводится вывод всех файлов конфигурации, что делает его полезным для поиска «мошеннических» файлов конфигурации на пути к классам.

6.4. Автоматическая перезагрузка конфигурации

Перезагрузка конфигурации ведения журнала во время работы приложения является мощным средством устранения неполадок. Logback делает это возможным с помощью параметра scan : 

<configuration scan="true">
  ...
</configuration>

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

<configuration scan="true" scanPeriod="15 seconds">
  ...
</configuration>

Мы можем указать значения в миллисекундах, секундах, минутах или часах.

6.5. Изменение Loggers

В нашем примере файла выше мы установили уровень корневого регистратора и связали его с консолью _Appender _ .

Мы можем установить уровень для любого регистратора: 

<configuration>
    <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
        <encoder>
            <pattern>%d{HH:mm:ss.SSS}[%thread]%-5level %logger{36} - %msg%n</pattern>
        </encoder>
    </appender>
    <logger name="com.baeldung.logback" level="INFO"/>
    <logger name="com.baeldung.logback.tests" level="WARN"/>
    <root level="debug">
        <appender-ref ref="STDOUT"/>
    </root>
</configuration>

Давайте добавим это в наш classpath и запустим этот код: 

Logger foobar =
  (ch.qos.logback.classic.Logger) LoggerFactory.getLogger("com.baeldung.foobar");
Logger logger =
  (ch.qos.logback.classic.Logger) LoggerFactory.getLogger("com.baeldung.logback");
Logger testslogger =
  (ch.qos.logback.classic.Logger) LoggerFactory.getLogger("com.baeldung.logback.tests");

foobar.debug("This is logged from foobar");
logger.debug("This is not logged from logger");
logger.info("This is logged from logger");
testslogger.info("This is not logged from tests");
testslogger.warn("This is logged from tests");

Мы видим этот вывод: 

00:29:51.787[main]DEBUG com.baeldung.foobar - This is logged from foobar
00:29:51.789[main]INFO com.baeldung.logback - This is logged from logger
00:29:51.789[main]WARN com.baeldung.logback.tests - This is logged from tests

Не устанавливая уровень наших регистраторов программно, конфигурация устанавливает их; com.baeldung.foobar наследует _ DEBUG _ от корневого регистратора.

Регистраторы также наследуют appender-ref от корневого регистратора. Как мы увидим ниже, мы можем переопределить это.

6.6. Подстановка переменных

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

Например, вот конфигурация для FileAppender : 

<property name="LOG__DIR" value="/var/log/application"/>
<appender name="FILE" class="ch.qos.logback.core.FileAppender">
    <file>${LOG__DIR}/tests.log</file>
    <append>true</append>
    <encoder>
        <pattern>%-4relative[%thread]%-5level %logger{35} - %msg%n</pattern>
    </encoder>
</appender>

В начале конфигурации мы объявили _property с именем LOG DIR . _ Затем мы использовали его как часть пути к файлу внутри определения appender__.

Свойства объявляются в теге <property> в ​​скриптах конфигурации.

Но они также доступны из внешних источников, таких как системные свойства. Мы могли бы опустить объявление property в этом примере и установить значение LOG DIR__ в командной строке: 

$ java -DLOG__DIR=/var/log/application com.baeldung.logback.LogbackTests

Мы указываем значение свойства с помощью $ \ {propertyname} . Logback реализует переменные в качестве замены текста. Подстановка переменных может происходить в любой точке файла конфигурации, где можно указать значение.

7. Appenders

Loggers передать LoggingEvents Appenders. Appenders выполнить фактическую работу регистрации Мы обычно думаем о регистрации как о чем-то, что идет в файл или консоль, но Logback способен на гораздо большее. Logback-core предоставляет несколько полезных дополнений.

7.1. ConsoleAppender

Мы уже видели _ConsoleAppender в действии. Несмотря на название, ConsoleAppender добавляет сообщения в System.out или System.err._

Он использует OutputStreamWriter для буферизации ввода/вывода, поэтому направление его в System.err не приводит к небуферизованной записи.

7.2. FileAppender

_FileAppender _ добавляет сообщения в файл. Он поддерживает широкий диапазон параметров конфигурации. Давайте добавим файл appender к нашей базовой конфигурации: 

<configuration debug="true">
    <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
        <!-- encoders are assigned the type
             ch.qos.logback.classic.encoder.PatternLayoutEncoder by default -->
        <encoder>
            <pattern>%d{HH:mm:ss.SSS}[%thread]%-5level %logger{36} - %msg%n</pattern>
        </encoder>
    </appender>

    <appender name="FILE" class="ch.qos.logback.core.FileAppender">
        <file>tests.log</file>
        <append>true</append>
        <encoder>
            <pattern>%-4relative[%thread]%-5level %logger{35} - %msg%n</pattern>
        </encoder>
    </appender>

    <logger name="com.baeldung.logback" level="INFO"/>
    <logger name="com.baeldung.logback.tests" level="WARN">
        <appender-ref ref="FILE"/>
    </logger>

    <root level="debug">
        <appender-ref ref="STDOUT"/>
    </root>
</configuration>

FileAppender настраивается с использованием имени файла через <file> . Тег _ <append> указывает Appender _ добавлять к существующему файлу, а не обрезать его. Если мы запустим тест несколько раз, мы увидим, что вывод журнала добавляется в тот же файл.

Если мы повторно запустим наш тест сверху, сообщения от com.baeldung.logback.tests будут отправляться как в консоль, так и в файл с именем tests.log. Регистратор-потомок наследует ассоциацию корневого регистратора с ConsoleAppender с ассоциацией с FileAppender. Аппендеры являются накопительными.

Мы можем переопределить это поведение: 

<logger name="com.baeldung.logback.tests" level="WARN" additivity="false" >
    <appender-ref ref="FILE"/>
</logger>

<root level="debug">
    <appender-ref ref="STDOUT"/>
</root>

Установка additivity в _false отключает поведение по умолчанию. Tests_ не будет входить в консоль, равно как и ни один из ее потомков.

7.3. RollingFileAppender

Часто добавление сообщений журнала в один и тот же файл - это не то поведение, которое нам нужно. Мы хотим, чтобы файлы «катились» в зависимости от времени, размера файла журнала или их комбинации.

Для этого у нас есть RollingFileAppender: 

<property name="LOG__FILE" value="LogFile"/>
<appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <file>${LOG__FILE}.log</file>
    <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
        <!-- daily rollover -->
        <fileNamePattern>${LOG__FILE}.%d{yyyy-MM-dd}.gz</fileNamePattern>

        <!-- keep 30 days' worth of history capped at 3GB total size -->
        <maxHistory>30</maxHistory>
        <totalSizeCap>3GB</totalSizeCap>
    </rollingPolicy>
    <encoder>
        <pattern>%-4relative[%thread]%-5level %logger{35} - %msg%n</pattern>
    </encoder>
</appender>

_RollingFileAppender имеет RollingPolicy . В этом примере конфигурации мы видим TimeBasedRollingPolicy . _

Подобно FileAppender, мы настроили для этого приложения имя файла. Мы объявили свойство и использовали его для этого, потому что мы будем использовать имя файла ниже.

Мы определяем fileNamePattern внутри _RollingPolicy . Этот шаблон определяет не только имена файлов, но и частоту их прокрутки. TimeBasedRollingPolicy _ проверяет шаблон и выполняет бросок в наиболее точно определенный период.

Например: 

<property name="LOG__FILE" value="LogFile"/>
<property name="LOG__DIR" value="/var/logs/application"/>
<appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <file>${LOG__DIR}/${LOG__FILE}.log</file>
    <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
        <fileNamePattern>${LOG__DIR}/%d{yyyy/MM}/${LOG__FILE}.gz</fileNamePattern>
        <totalSizeCap>3GB</totalSizeCap>
    </rollingPolicy>

Активным файлом журнала является _/var/logs/application/LogFile . Этот файл переносится в начале каждого месяца на /текущий год/текущий месяц/LogFile.gz , и RollingFileAppender_ создает новый активный файл.

Когда общий размер архивных файлов достигает 3 ГБ, _RollingFileAppender _ удаляет архивы в порядке очереди.

Есть коды для недели, часа, минуты, секунды и даже миллисекунды.

Logback имеет ссылку here .

_RollingFileAppender также имеет встроенную поддержку сжатия файлов. Он сжимает наши свернутые файлы, потому что назвал их их LogFile.gz._

_TimeBasedPolicy - не единственная опция для прокручивания файлов. Logback также предлагает SizeAndTimeBasedRollingPolicy, , который будет катиться в зависимости от текущего размера файла журнала и времени. Он также предлагает FixedWindowRollingPolicy _ , который прокручивает имена файлов журналов при каждом запуске регистратора.

Мы также можем написать свои собственные RollingPolicy .

7.4. Пользовательские Appenders

Мы можем создавать собственные приложения, расширяя один из базовых классов приложений Logback. У нас есть учебник по созданию пользовательских ссылок appenders:/custom-logback-appender[здесь].

8. Layouts

Layouts формат сообщений журнала. Как и остальная часть Logback, _Layouts являются расширяемыми, и мы можем create наших собственных. Однако по умолчанию PatternLayout_ предлагает то, что нужно большинству приложений тогда некоторые.

Мы использовали PatternLayout во всех наших примерах: 

<encoder>
    <pattern>%d{HH:mm:ss.SSS}[%thread]%-5level %logger{36} - %msg%n</pattern>
</encoder>

Этот скрипт конфигурации содержит конфигурацию для _PatternLayoutEncoder . Мы передаем Encoder нашему Appender, , и этот кодировщик использует PatternLayout_ для форматирования сообщений.

Текст в теге <pattern> определяет форматирование сообщений журнала. PatternLayout реализует большое разнообразие конверсионных слов и модификаторов формата для создания шаблонов.

Давай сломаем это. PatternLayout распознает слова преобразования с%, поэтому преобразования в нашем шаблоне генерируют:

  • % d \ {ЧЧ: мм: сс.ССС} - отметка времени с часами, минутами, секундами и

миллисекунды ** [% thread] - имя потока, генерирующего сообщение журнала, в окружении

квадратными скобками ** % - 5level - уровень регистрации событий, дополненный до 5 символов

  • % logger \ {36} - имя регистратора, усеченное до 35 символов

  • % msg% n - сообщения журнала, за которыми следует строка, зависящая от платформы

разделитель

Итак, мы видим сообщения, похожие на это: 

21:32:10.311[main]DEBUG com.baeldung.logback.LogbackTests - Logging message: This is a String

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

9. Вывод

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

Мы рассмотрели три основных компонента архитектуры Logback:

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

Как обычно, фрагменты кода можно найти over на GitHub .

Related