Как правильно разделять события жизненного цикла в системе ведения журнала?

Question

У меня есть приложение с множеством различных частей, оно работает на OSGi, так что есть жизненные циклы комплекта, есть несколько обработчиков сообщений и компонентов плагинов, которые могут умереть, могут быть запущены и остановлены, изменены их настройки и т. Д. 1001 *

Мне нужен способ получить хорошее представление о текущем состоянии системы, о том, какие компоненты работают, у которых есть проблемы, как долго они работают и т. Д. Я думаю, что ведение журнала, особенно в сочетании с пользовательскими приложениями (я m использует log4j), является хорошей частью решения и помогает проводить специальный анализ, а также мониторинг в реальном времени.

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

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

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

Answer 1

Хотели ли вы использовать отдельные регистраторы для этих событий?

Думаю, это типичный способ решения такого рода проблем.

Answer 2

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

Если вам нужен текущий статус, вам нужен мониторинг, а на Java это означает JMX. Теперь тот факт, что вы также делаете OSGi, делает это немного сложнее, хотя люди работали над этим: http://code.google.com/p/maexo/

Answer 3

log4 использует концепцию ThreadContext.Stacks ["NDC"] (ранее просто NDC http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/NDC.html).. При каждом событии жизненного цикла вы помещаете текущий контекст в стек, а по завершении этого события вы извлекаете его. снова со стека. Сделано с осторожностью, это может дать вам довольно удобный след, где вы находитесь в последовательности вызовов с каждой записью журнала.

Answer 4

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

Типичная иерархия логгеров, которую все используют, основана на именах пакетов. Но я рекомендую использовать отдельные иерархии, используя префиксы. Если вы ставите префикс класса и имени пакета с помощью LIFECYCLE, вы можете включить, отключить эти сообщения или направить их в специальное место с помощью стандартных параметров конфигурации log4j или slf4j или практически любой разумной среды ведения журнала.