Spring Boot використовує Commons Logging для комплексного логування (журналювання, logging) на внутрішньому рівні, але залишає відкритою базову реалізацію лога. Стандартні конфігурації передбачені для Java Util Logging, Log4J2 та Logback. У кожному випадку диспетчери логування попередньо налаштовані на використання консольного виводу з можливістю виведення у файл.

За умовчанням, якщо використовуються "Стартери", для ведення лога використовується Logback. Відповідна маршрутизація Logback також передбачена для забезпечення коректної роботи залежних бібліотек, що використовують Java Util Logging, Commons Logging, Log4J або SLF4J. Для Java доступно безліч фреймворків логування . Не турбуйтеся, якщо наведений вище список вводить у ступор. Як правило, змінювати залежності логування не потрібно, і налаштування Spring Boot за замовчуванням працюють просто відмінно. Якщо ви розгортаєте свою програму в контейнері сервлетів або на сервері програм, логування, що виконується за допомогою API-інтерфейсу Java Util Logging, не маршрутизується до логів програми. Це запобігає появі в логах програми записів, що виконуються контейнером або іншими додатками, які були розгорнуті в ньому.

2022-10-20 12:40:11.311 INFO 16138 --- [ main] o.s.b.d.f.s.MyApplication : Starting MyApplication використовуючи Java 1.8.0_345 on myhost with PID 16138 (/opt/apps/myapp.jar started by myuser in /opt/apps/) 2022-10-20 12:40:80 - [ main] o.s.b.d.f.s.MyApplication : Немає активного profile set, falling back do 1 default profile: "default" 2022-10-20 12:40:13.056 INFO 16138 --- [ main] o.s.b.w.embed port(s): 8080 (http) 2022-10-20 12:40:13.070 INFO 16138 --- [ main] o.apache.catalina.core.StandardService : Starting service [Tomcat] 2022-10-20 12:40 :13.070 INFO 16138 --- [ main] org.apache.catalina.core.StandardEngine : Starting Servlet engine: [Apache Tomcat/9.0.68] 2022-10-20 12:40:13.178 INFO 16138 --- o.a.c.c.C.[Tomcat].[localhost].[/] : Initializing Spring embedded WebApplicationContext 2022-10-20 12:40:13.178 INFO 16138 --- [ main] w.s.c.Servlet - 20 12:40:13.840 INFO 16138 --- [ main] o.s.b.w.embedded.tomcat.TomcatWebServer : Tomcat started on port(s): 8080 (http) with context path '' 2022-10-20 12:40 --- [ main] o.s.b.d.f.s.MyApplication : Started MyApplication в 4.062 seconds (JVM running for 5.452)

Виводяться такі елементи:

  • Дата та час: точність до мілісекунди та легке сортування.

  • Рівень ведення логу: ERROR, WARN, INFO, DEBUG або TRACE.

  • Ідентифікатор процесу.

  • Розділювач --- для поділу початку фактичних повідомлень лога.

  • Назва потоку: укладено в квадратні дужки (може бути усічено для виведення в консоль).

  • Ім'я диспетчера логування: зазвичай це ім'я вихідного класу (часто скорочене).

  • Повідомлення лога .

Logback не має рівня FATAL. Він відображається на ERROR.

Консольний висновок

У конфігурації лога за замовчуванням повідомлення відображаються в консоль у міру їх запису. За замовчуванням в лог записуються повідомлення рівнів ERROR, WARN та INFO. Ви також можете активувати режим "налагодження", запустивши програму з прапором --debug.

$ java -jar myapp.jar --debug
Також можна задати debug=true у файлі application.properties.
Якщо режим налагодження активовано, набір основних диспетчерів логування (вбудований контейнер, Hibernate і Spring Boot) конфігурується для виведення додаткової інформації. Активація режиму налагодження не конфігурує програму на реєстрацію всіх повідомлень з рівнем DEBUG.

Крім того, можна активувати режим "трасування", запустивши програму з прапором --trace (або trace=true у файлі application.properties). Це дозволяє реєструвати лог трасування для ряду основних диспетчерів логування (вбудований контейнер, генерація схеми Hibernate і весь портфель Spring). колірний висновок. Можна встановити spring.output.ansi.enabled у підтримуване значення щоб перевизначити автоматичне виявлення.

Колірне кодування конфігурується за допомогою слова перетворення %clr. У своїй простій формі перетворювач забарвлює виведення відповідно до рівня лога, як показано в наступному прикладі:

%clr(%5p)

У наступній таблиці описано відповідність рівнів логу кольорам:

Рівень Колір

FATAL

Червоний

ERROR

Червоний

WARN

Жовтий

INFO

Зелений

DEBUG

Зелений

TRACE

Зелений

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

 %clr(%d{yyyy-MM-dd HH:mm:ss.SSS}){yellow}

Підтримуються такі кольори та стилі:

  • blue

  • cyan

  • faint

  • green

  • magenta

  • red

  • yellow

Виведення у файл

За замовчуванням Spring Boot веде лог лише в консолі і не веде запис у файли лога. Якщо потрібно записувати файли лога на додаток до виведення в консоль, необхідно встановити властивість logging.file.name або logging.file.path (наприклад, у файлі application.properties).

У наступній таблиці показано, як властивості logging.* можна використовувати разом:5

Таблиця 5 Властивості логування
logging.file.name logging.file.path Приклад Опис

(відсутня)

(відсутня)

Виводить записи лога виключно в консоль.

Конкретний файл

(відсутня)

my.log

Здійснює запис у вказаний файл лога. Імена можуть бути точним розташуванням або пов'язані з поточним каталогом.

(відсутня)

Конкретний каталог

/var/log

Здійснює запис spring.log у вказаний каталог. Імена можуть бути точним місцезнаходженням або бути пов'язаними з поточним каталогом. у випадку з виведенням в консоль, за умовчанням реєструються повідомлення рівнів ERROR, WARN та INFO.

Властивості логування не залежать від фактичної інфраструктури логування. Отже, специфічні конфігураційні ключі (наприклад, logback.configurationFile для Logback) не знаходяться під керуванням Spring Boot.

Ротація файлів

Якщо ви використовуєте Logback, можна точно настроїти параметри ротації лога за допомогою файлу application.properties або application.yaml. Для всіх інших систем логування потрібно буде самостійно конфігурувати параметри ротації (наприклад, якщо ви використовуєте Log4J2, то можете додати файл log4j2.xml або log4j2-spring.xml).

Підтримуються такі властивості політики ротації:

Ім'я Опис

logging.logback.rollingpolicy. file-name-pattern

Шаблон імені файлу, який використовується для створення архівів лога.

logging.logback.rollingpolicy.clean-history-on-start

Якщо очищення архіву лога має відбуватися при запуску програми.

p>

logging.logback.rollingpolicy.max-file-size

Максимальний розмір файлу лога перед його архівацією.

logging.logback.rollingpolicy.total-size-cap

Максимальний розмір видаленого архіву лога перед безпосереднім видаленням.

logging.logback.rollingpolicy .max-history

Максимальна кількість файлів в архіві лога, які потрібно зберігати (за замовчуванням 7).

Рівні ведення логу

Усі підтримувані системи логування можуть мати рівні ведення логу, встановлені в Environment з Spring (наприклад, application.properties) за допомогою logging.level.<logger-name>=<level>, де level – один з рівнів, серед яких TRACE , DEBUG, INFO, WARN, ERROR, FATAL або OFF. Можна налаштувати root диспетчер логування за допомогою logging.level.root.

У цьому прикладі показано можливі параметри логування в application.properties:

Properties
logging.level.root=warn logging.level.org.springframework.web=debug logging .level.org.hibernate=error
Yaml
logging: level: root: "warn" org.springframework.web: "debug" org.hibernate: "error"

Также можна встановити рівні ведення логу за допомогою змінних оточення. Наприклад, LOGGING_LEVEL_ORG_SPRINGFRAMEWORK_WEB=DEBUG встановить для org.springframework.web значення DEBUG.

Наведений вище підхід спрацює тільки для логування на рівні пакетів. Оскільки несувора прив'язка завжди перетворює змінні оточення на нижній регістр, налаштувати логування для окремого класу таким чином неможливо. Якщо потрібно налаштувати логування для класу, то можна використовувати змінну SPRING_APPLICATION_JSON.

Групи логів

У багатьох випадках корисно мати можливість групувати пов'язані диспетчери логування разом, щоб їх можна конфігурувати одночасно. Наприклад, можна часто змінювати рівні ведення лога для всіх диспетчерів логування, пов'язаних з Tomcat, але легко запам'ятати пакети верхнього рівня не вийде.

Щоб допомогти в цьому, Spring Boot дозволяє визначити групи логування у вашій Environment для Spring. Наприклад, ось як ви можете визначити "tomcat-групу", додавши її до файлу application.properties:

Properties
logging.group.tomcat=org.apache.catalina,org.apache.coyote,org.apache.tomcat
Yaml
logging: group: tomcat: "org.apache.catalina,org.apache.coyote,org.apache.tomcat"

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

Properties
logging.level.tomcat=trace
Yaml
logging: level: tomcat: "trace"

Spring Boot містить такі визначені групи логування, які можна використовувати "з коробки":

Ім'я Диспетчери логування

web

org.springframework .core.codec, org.springframework.http, org.springframework.web, org.springframework.boot.actuate.endpoint.web, org.springframework.boot.web.servlet.ServletContextInitializerBeans

sql

org.springframework.jdbc.core, org.hibernate.SQL, org.jooq.tools.LoggerListener

Використання перехоплювача завершення роботи лога

Щоб вивільнити ресурси логування при завершенні роботи програми, передбачено перехоплювач завершення, який запускає очищення системи логування під час виходу з JVM. Цей перехоплювач завершення реєструється автоматично, якщо ваша програма не розгорнуто як war-файла. Якщо програма має складну ієрархію контекстів, перехоплювач завершення може не відповідати вашим потребам. Якщо він не відповідає їм, відключіть перехоплювач завершення та розгляньте варіанти, передбачені безпосередньо базовою системою логування. Наприклад, Logback передбачає контекстні селектори, які дозволяють створювати кожен Logger у своєму власному контексті. Щоб вимкнути перехоплювач завершення, можна використовувати властивість logging.register-shutdown-hook. Встановлення значення false вимикає реєстрацію. Можна встановити цю властивість у файлі application.properties або application.yaml:

Properties
logging.register-shutdown-hook=false
Yaml
logging: register-shutdown-hook: false

Кастомна конфігурація лога

Різні системи логування можна активувати шляхом включення відповідних бібліотек в classpath і додатково специфічно налаштувати шляхом передачі відповідного конфігураційного файлу в корені classpath або в місцеположенні, заданому наступною властивістю Environment для Spring: logging.config.

Можна зробити так, щоб Spring Boot в примусовому порядку використовувати певну систему логування за допомогою системної властивості org.springframework.boot.logging.LoggingSystem. Значення має бути повним ім'ям класу реалізації LoggingSystem. Також можна повністю відключити конфігурацію логування Spring Boot, використовуючи значення none.

Оскільки логування ініціалізується перед створенням ApplicationContext, неможливо керувати логуванням через анотацію @PropertySources у файлах Spring з анотацією @Configuration. Єдиний спосіб змінити систему логування або повністю відключити її через системні властивості.

Залежно від системи логування завантажуються такі файли:

Система логування Налаштування

Logback

logback-spring.xml, logback-spring.groovy, logback.xml, або logback.groovy

Log4j2

log4j2-spring.xml або log4j2.xml

JDK (Java Util Logging)

logging.properties

Якщо це можливо, рекомендуємо використовувати варіанти -spring для конфігурації логування (наприклад, logback-spring.xml , а не logback.xml). Якщо використовуються стандартні розташування конфігурації, Spring не зможе повністю керувати ініціалізацією лога. Існують відомі особливості із завантаженням класів у Java Util Logging, які викликають проблеми при запуску з "виконуваного jar-файлу". Ми рекомендуємо по можливості уникати цього при запуску з "виконуваного jar-файлу".

Для спрощення налаштування деякі інші властивості переносяться з Environment для Spring у системні властивості, як описано в наступній таблиці :

Оточення Spring Системна властивість Коментарі

logging.exception-conversion-word

LOG_EXCEPTION_CONVERSION_WORD

Слово перетворення, яке використовується при реєстрації винятків.

logging.file.name

LOG_FILE

Якщо визначено, використовується в конфігурації лога за замовчуванням.

logging.file.path

LOG_PATH

Якщо визначено, використовується в конфігурації лога за замовчуванням.

logging.pattern.console

CONSOLE_LOG_PATTERN

Шаблон лога для використання з консоллю (STDOUT).

logging.pattern.dateformat

LOG_DATEFORMAT_PATTERN

Шаблон апендера для форматування дати лога.

logging.charset.console

CONSOLE_LOG_CHARSET

Кодування, яке використовується для ведення лога з виведенням у консоль.

logging.pattern.file

FILE_LOG_PATTERN

Шаблон логу для використання у файлі (якщо активовано властивість LOG_FILE).

logging.charset.file

FILE_LOG_CHARSET

Кодування, яке використовується для ведення лога у файлах (якщо активовано властивість LOG_FILE).

logging.pattern.level

LOG_LEVEL_PATTERN

Формат, що використовується при візуалізації рівня лога (за замовчуванням %5p).

PID

PID

Ідентифікатор поточного процесу (розпізнається, якщо це можливо і якщо він ще не визначений як змінна оточення ОС).

Якщо ви використовуєте Logback, також передаються такі властивості:

Оточення Spring Системна властивість Коментарі

logging.logback.rollingpolicy.file-name-pattern

LOGBACK_ROLLINGPOLICY_FILE_NAME_PATTERN

Шаблон для імен архівних файлів лога (за промовчанням ${LOG_FILE}.%d{yyyy-MM-dd}.%i.gz).

logging.logback.rollingpolicy.clean-history-on-start

LOGBACK_ROLLINGPOLICY_CLEAN_HISTORY_ON_START

Вказує, чи потрібно очищати файли в архіві лога під час запуску.

logging.logback.rollingpolicy.max-file-size

LOGBACK_ROLLINGPOLICY_MAX_FILE_SIZE

Максимальний розмір файлу лога.

logging.logback.rollingpolicy.total-size-cap

LOGBACK_ROLLINGPOLICY_TOTAL_SIZE_CAP

Загальний розмір резервних копій логу, що зберігаються.

logging.logback.rollingpolicy.max-history

LOGBACK_ROLLINGPOLICY_MAX_HISTORY

Максимальна кількість файлів в архіві лога, які необхідно зберігати.

Всі підтримувані системи логування можуть звертатися до системних властивостей при парсингу конфігураційних файлів. Дивіться приклади конфігурацій за замовчуванням у spring-boot.jar:

Якщо вам потрібно використовувати плейсхолдер як логування, то слід дотримуватися синтаксису Spring Boot, а не синтаксису базового фреймворку. Зокрема, якщо ви використовуєте Logback, слід використовувати : як роздільник між ім'ям властивості та його значенням за умовчанням, а не :-.

Можна додавати MDC-контекст та інший спеціальний вміст у рядки лога, перевизначаючи тільки LOG_LEVEL_PATTERN (або logging). pattern.level у Logback). Наприклад, якщо ви використовуєте logging.pattern.level=user:%X{user} %5p, формат логера за замовчуванням містить запис MDC для "user", якщо вона існує, як показано в наступному прикладі .

2019-08-30 12:30:04.031 user:someone INFO 22174 --- [ nio-8080-exec-0] demo.Controller Handling authenticated request

Розширення Logback

Spring Boot містить низку розширень для Logback, які можуть спростити поглиблене конфігурування. Ці розширення можна використовувати в конфігураційному файлі logback-spring.xml.

Оскільки стандартний конфігураційний файл logback.xml завантажується зарано, розширення в ньому використовувати не можна. Необхідно або використовувати logback-spring.xml, або визначити властивість logging.config.
Розширення не можна використовувати з скануванням конфігурації з Logback. Якщо ви спробуєте зробити це, внесення змін до файлу конфігурації призведе до реєстрації помилки, подібної до однієї з наступних:
ERROR in ch.qos.logback.core.joran.spi.Interpreter@4:71 - не застосовуваний дія для [springProperty], поточний ElementPath is [[configuration][springProperty]] ERROR in ch. qos.logback.core.joran.spi.Interpreter@4:71 - no applicable action for [springProfile], current ElementPath is [[configuration][springProfile]]

Пов'язана з конкретним профілем конфігурація

Тег <springProfile> дозволяє за бажанням включати або виключати розділи конфігурації на основі активних профілів Spring. Розділи профілю підтримуються в будь-якому місці елемента <configuration>. Використовуйте атрибут name, щоб визначити, який профіль приймає конфігурацію. Тег <springProfile> може містити ім'я профілю (наприклад, staging) або вираз профілю. Вираз профілю дозволяє виразити складнішу логіку профілю (наприклад, production & (eu-central | eu-west)). У наступному лістингу показано три зразки профілів:

<springProfile name="staging"> <!-- конфігурація, яка буде активована, якщо профіль "staging" активний --> </springProfile> <springProfile name="dev | staging"> <!-- конфігурація, яка буде активована, якщо профіль "dev" або "staging" активний --> </springProfile> <springProfile name="!production"> <!-- конфігурація, яка буде активована, якщо профіль "production" активний --> </springProfile>

Властивості оточення

Тег <springProperty> дозволяє відкривати властивості з Environment у Spring для використання в Logback. Це може бути корисним, якщо необхідно отримати доступ до значень файлу application.properties у конфігурації Logback. Цей тег працює так само, як і стандартний тег <property> у Logback. Однак замість завдання прямого value ви задаєте source властивості (з Environment). Якщо необхідно зберігати властивість не в local області доступності, можна використовувати атрибут scope. Якщо потрібно запасне значення (на випадок, якщо властивість не встановлена в Environment), можна використовувати атрибут defaultValue. У цьому прикладі показано, як відкрити властивості для використання в Logback:

<springProperty scope="context" name="fluentHost" source="myapp.fluentd.host" defaultValue="localhost"/> <appender name="FLUENT" class="ch.qos.logback.more.appenders.DataFluentAppender"> <remoteHost>${fluentHost}</remoteHost> ... </appender>
Задавати source потрібно в кебаб-реєстрі (наприклад, my.property-name). Однак властивості можна додавати в Environment за допомогою нестрогих правил.