Насколько сложна система логирования Java? --Архитектура

Java
Насколько сложна система логирования Java? --Архитектура
Эта статья представляет собой серию, добро пожаловать на внимание

Насколько священно бревно? Зачем использовать структуру ведения журналов?

Я думаю, все его использовалиSystem.outДля выполнения отладки вывода, конечно, очень удобно это делать в среде разработки, но хлопотно делать это онлайн:

  1. Система продолжает работать, выход все больше и больше, а место на диске постепенно заполняется
  2. Разные предприятия хотят выводить журналы в разных местах
  3. В некоторых случаях для достижения более высокой производительности старайтесь максимально контролировать и сокращать вывод журнала, и необходимо динамически регулировать объем вывода журнала.
  4. Автоматически выводить информацию, относящуюся к журналу, такую ​​как: дата, поток, имя метода и т. д.

очевидноSystem.outОн не может решить нашу проблему, но с проблемами, с которыми мы столкнулись, наверняка сталкивались наши предшественники, и бревно не является исключением.Среди них есть большая короваCeki, Ceki участвует почти во всей системе журналов Java или находится под сильным влиянием Ceki. Конечно, сложность системы журналов Java также частично связана с этим большим быком.

Жалобы и жалобы журнала Java

  • В начале 1996 года проектная группа European Security Electronic Market решила написать собственный API трассировки программ (Tracing API). После постоянного улучшения этот API наконец стал очень популярным пакетом ведения журналов Java, а именно Log4j (созданный Ceki).
  • Позже Log4j стал участником проекта Apache Foundation, а Ceki также присоединился к организации Apache. Позже Log4j почти стал стандартом ведения журналов в сообществе Java. Говорят, что Apache Foundation однажды предложила Sun ввести Log4j в стандартную библиотеку Java, но Sun отказалась.
  • В 2002 году, когда была выпущена Java 1.4, Sun запустила собственную библиотеку протоколирования JUL (Java Util Logging), реализация которой в основном имитировала реализацию Log4j. До выхода JUL Log4j стала зрелой технологией, что дает Log4j определенное преимущество при выборе.
  • Затем Apache запустил Jakarta Commons Logging, JCL просто определяет набор интерфейсов журналов (он также обеспечивает простую реализацию Simple Log внутри), который поддерживает реализацию динамической загрузки компонентов журнала во время выполнения, то есть в коде вашего приложения, Просто вызовите интерфейс Commons Logging, и базовой реализацией может быть Log4j или Java Util Logging.
  • Позже (в 2006 году) Чеки покинул Apache, не адаптировавшись к тому, как работает Apache. Затем я создал два проекта, Slf4j (интерфейс фасада журнала, аналогичный Commons Logging) и Logback (реализация Slf4j), и вернулся в Швецию, чтобы создать компанию QOS.Официальный сайт QOS описывает Logback следующим образом: Общий, надежный, быстрый & Гибкая структура ведения журнала (универсальная, надежная, быстрая и гибкая структура ведения журнала).
  • Поле регистрации Java разделено на два лагеря: лагерь Commons Logging и лагерь Slf4j.
  • Commons Logging имеет большую базу пользователей под капотом дерева Apache. Но есть свидетельства того, что форматы меняются. В конце 2013 года кто-то проанализировал 30 000 проектов на GitHub и насчитал 100 самых популярных библиотек, видно, что тенденция развития у Slf4j лучше.
  • Увидев, что у Apache есть импульс, чтобы Logback обогнал его, он переписал Log4j 1.x в 2012-07 годах и создал новый проект Log4j 2, который имеет все функции Logback.
  • Сейчас фреймворк лога развился в: Slf4j как API, реализация разделена на logback и log4j (Commons Logging постепенно уходит со сцены из-за проблем с эффективностью и дизайном API)

Давайте воздадим должное великому богу, ха-ха:

Так как же изящно использовать журналы в хаотичной системе журналирования Java?

По сути, в системе, разработанной Ceki, логи похожи на Java JDBC, Servelt и т. д. После определения стандарта реализации можно переключать друг на друга Проблема в том, что люди, устанавливающие стандарт, придумали много стандарты, такие как JCL, SLF4j и т. д., официальные (компания Sun). Было слишком поздно и неэффективно, и разработка, наконец, была унифицирована SLF4j оригинальным способом (связывание, связывание, см. ниже). Стандартное использование как следует:


Это изображение было взято изруководство по slf4j, упрощает избыточную часть и ясно показывает использование:

Приложение ссылается на SLF4j-API (используйте интерфейс SLF4j при кодировании).org.slf4j.Logger, а не реализация logback или log4j)

  • журнал:slf4j автоматически найдет реализацию logback (по умолчанию logback реализует slf4j)
  • log4j: в основном то же самое, но есть дополнительный уровень адаптера, который ссылается на slf4j-log4j12.jar, официально называемый конкретными привязками, который предназначен для привязки SLF4j-API к log4j и, наконец, вывода журнала.

Конкретные зависимости следующие

logback

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

log4j2

<dependency>
  <groupId>org.apache.logging.log4j</groupId>
  <artifactId>log4j-slf4j-impl</artifactId>
  <version>2.12.1</version>
</dependency>
<dependency>
  <groupId>org.apache.logging.log4j</groupId>
  <artifactId>log4j-core</artifactId>
  <version>2.12.1</version>
</dependency>

Благодаря механизму доставки зависимостей maven нам не нужно явно объявлять зависимости от SLF4j-API.jar.

Видно, что log4j больше полагается на log4j-slf4j-impl.jar, который на самом деле является уровнем адаптера, показанным на рисунке выше.Читателям может быть любопытно, почему используется log4j.адаптерЭтаж? Причина в том, что slf4j не является официальной спецификацией, поэтому ей никто не следует (то есть нет нативной реализации в собственном фреймворке логированияorg.slf4j.Loggerинтерфейс, такой как log4j), а роль уровня привязки (log4j-slf4j-impl.jar) заключается в использовании log4j в качестве реализации через статический поиск (конкретный принцип, пожалуйста, обратите внимание на следующую статью), который должен реализовать использование log4j, не полагаясь на него log4j output log (лучшая практика для интерфейсно-ориентированного программирования, Ceki God использовал эту идею, чтобы сделать slf4j стандартом журнала Java, моделью обращения с плохой картой).

Вышеприведенный абзац объясняет привязку (concrete-bindings) идея - суть этой статьи, читатели должны ее понять, есть сходные идеи, похожие на нее, пожалуйста, продолжайте читать.

резюме

На данный момент мы завершили интеграцию логов, но так ли это просто?

Давайте сначала разберемся, не будет ли проблем в такой хаотичной системе логов (slf4j, jul, jcl, logback, log4j)? Ответ: да, различные сторонние библиотеки используют разные структуры журналов.Если мы полагаемся на Spring, реализация журнала Spring по умолчанию (без загрузки) — это JCL, или если мы уже использовали Log4j в наших существующих проектах и ​​хотим использовать logback, код надо менять по одному (есть официальная миграция)?Можем ли мы использовать только одну структуру для обработки JUL (java.util.logging), JCL (Jakarta Commons Logging), Log4j1, Log4j2?

Ответ — да, Slf4j от Ceki предоставляет решение, которое представляет собой мост (наследие моста), упомянутый выше, что просто означает перехват вышеупомянутого стороннего вывода журнала и перенаправление его в SLF4j, наконец реализуя единый API верхнего уровня журнала. (кодирование) и реализация нижнего уровня (местоположение и формат выходного журнала унифицированы). Давайте посмотрим на схему:


Левая часть изображения выше — это реализация журнала регистрации предыдущего изображения.Для совместимости с другими журналами нам нужно обратиться к пакету моста справа: xxx-over/to-slf4j.jar, xxx соответствует к структуре журналов при использовании logback, за исключением приведенных выше зависимостей logback, также необходимо ввести следующие зависимости, чтобы гарантировать, что все журналы подключены к slf4j.

Как провести мост?

logback следующее

<dependency>
  <groupId>ch.qos.logback</groupId>
  <artifactId>logback-classic</artifactId>
  <version>1.2.3</version>
</dependency>
<dependency>
   <groupId>org.slf4j</groupId>
   <artifactId>jcl-over-slf4j</artifactId>
</dependency>
<dependency>
   <groupId>org.slf4j</groupId>
   <artifactId>jul-to-slf4j</artifactId>
</dependency>
<!-- log4j 桥接包，slf4j官方实现，另有log4j官方实现，二选一即可 log4j-to-slf4j-->
<dependency>
   <groupId>org.slf4j</groupId>
   <artifactId>log4j-over-slf4j</artifactId>
</dependency>

log4j2 следующее

<dependency>
  <groupId>org.apache.logging.log4j</groupId>
  <artifactId>log4j-slf4j-impl</artifactId>
  <version>2.12.1</version>
</dependency>
<dependency>
  <groupId>org.apache.logging.log4j</groupId>
  <artifactId>log4j-core</artifactId>
  <version>2.12.1</version>
</dependency>
<!-- 以下是桥接包，使用了log4j作为底层实现，
     不能再桥接log4j，否则会出现无限递归的情况(具体原因请关注后续文章) -->
<dependency>
   <groupId>org.slf4j</groupId>
   <artifactId>jcl-over-slf4j</artifactId>
</dependency><dependency>
   <groupId>org.slf4j</groupId>
   <artifactId>jul-to-slf4j</artifactId>
</dependency>

Проект SpringBoot ссылается на некоторые зависимости, поэтому его использование немного отличается:

logback следующее

<!-- logback作为内置实现，使用相对简单 -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter</artifactId>
</dependency><!-- 引入缺少的桥接包 --><dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>jcl-over-slf4j</artifactId>
</dependency>

log4j2 следующее

<dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter</artifactId>
   <!-- 使用log4j2要排除logback依赖 -->
   <exclusions>
      <exclusion>
         <groupId>org.springframework.boot</groupId>
         <artifactId>spring-boot-starter-logging</artifactId>
      </exclusion>
   </exclusions>
</dependency>
<!-- Spring已经写好了一个log4j2-starter但缺少桥接包 -->
<dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-log4j2</artifactId>
</dependency>
<!-- 引入缺少的桥接包 -->
<dependency>
   <groupId>org.slf4j</groupId>
   <artifactId>jcl-over-slf4j</artifactId>
</dependency>

заключительные замечания

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

Наконец, давайте посмотрим, как используется slf4j:

static final org.slf4j.Logger logger = LoggerFactory.getLogger(TestLog.class);
logger.trace("A TRACE Message");
logger.debug("A DEBUG Message");
logger.info("An INFO Message");
logger.warn("A WARN Message");
logger.error("An ERROR Message");

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

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

Пожалуйста, укажите источник.

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


Ссылаться на:

Ява-лог рек и озер
www.slf4j.org/manual.html
www.slf4j.org/legacy.html
Woohoo.Принеси арлингтонского терьера.com/spring-boot…




Категории