Как мне унифицировать форматы регистрации из стека Java

Question

Используя веб-сервер Jetty, запущенный с maven, который включает iBatis, Spring, Jersey, немного этого и немного того, я получаю вывод журнала с множеством форматов.

Некоторые из Maven:

[INFO] [war:war]
[INFO] Exploding webapp...

Некоторые из Причала:

2009-03-25 21:01:27.781::INFO:  jetty-6.1.15
2009-03-25 21:01:28.218:/example:INFO:  Initializing Spring root WebApplicationContext

Некоторые из весны:

INFO  ContextLoader - Root WebApplicationContext: initialization started (189)
INFO  XmlBeanDefinitionReader - Loading XML bean definitions from ServletContext resource [/WEB-INF/applicationContext.xml] (323)

Некоторые из Джерси:

Mar 25, 2009 9:01:29 PM com.sun.jersey.spi.spring.container.SpringComponentProviderFactory register

все еще другие из моего кода:

INFO  ExampleApp - [User@14ef239 ...stuff] (69)

Я предполагаю, что все они используют стандартные пакеты журналов (log4j, commons-logging, java-logging ...)

Возможно ли это, и какой самый простой способ настроить их все на использование одного и того же формата? Есть ли какая-то польза от их сохранения в разных форматах?

Answer 1

Это возможно при использовании библиотеки logback и ее мостов. Он в основном состоит в удалении любых общих файлов log4j или аналогичных jar-файлов из classpath, файла jar stick logback и мостов jar для log4j и других. Spring, jersey и maven будут использовать фабрики мостов для создания экземпляров регистраторов, которые, в свою очередь, будут использовать logbak для создания унифицированных журналов.

Чек http://logback.qos.ch/ и http://www.slf4j.org/legacy.html

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

Answer 2

Проблема в том, что приложения используют разные библиотеки журналов. Джерси будет использовать JUL, Spring будет использовать регистрацию в общем-то (которая, в свою очередь, выберет log4j, если он находится в вашем пути к классам), а Jetty использует свой собственный регистратор. Вы можете исправить это, заставив все ваши компоненты регистрироваться через JUL.

Сначала вам нужно получить log4j из вашего classpath. Используйте исключения или другие механизмы, чтобы гарантировать, что log4j не включен. Это предотвратит использование log4j над log4j через JUL и заставит Spring войти в тот же формат, что и в Джерси.

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

Если код вашего приложения использует log4j напрямую, вам нужно переключиться на использование общего журнала или JUL.

Мэйвен, я не уверен в этом, но, вероятно, у него есть похожее решение.

Answer 3

Просто используйте http://logback.qos.ch/translator/ для преобразования log4j.properties в формат xml и вставьте его в logback.xml. Это работает как очарование, направляющее ваш журнал настроенному appender.

Answer 4

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

Answer 5

SLF4J позволяет консолидировать ведение журнала, перенаправив его в единую структуру ведения журнала. Вы можете перенаправить вызовы устаревшей регистрации, сделанные с помощью commons-logging, java.util.logging и log4j, как если бы они были сделаны в SLF4J. Для получения дополнительной информации см. Www.slf4j.org/legacy.html.

Все журналы будут затем делегированы в базовый фреймворк по вашему выбору, например, logback, log4j, java.util.logging и другие. Если у вас возникли проблемы, свяжитесь со списком рассылки slf4j-user.

Answer 6

Если и когда они используют стандартный пакет регистрации, вы, конечно, можете объединить общие части (префикс «INFO», метка времени, название категории (обычно класс / пакет)). Просто настройте log4j / J.U.L / logback по своему вкусу. Я не знаю, почему вы получите разные форматы - форматы журналов не настраиваются фреймворками, а приложениями - так что, возможно, они используют разные фреймворки. Но это может быть случайным.

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

Answer 7

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

Если вы определите, какие из них вас интересуют, вы можете получить каждый из них для вывода в файлы журналов в центральном каталоге / var / log / app (например, в Linux). Отсюда вы можете написать простую утилиту, которая анализирует каждый файл журнала и массирует данные в один файл журнала в нужном вам формате. Утилита Awk очень хорошо справляется с подобными вещами.

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

Answer 8

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