Гигантские журналы NodeManagerLogs из спящего режима в weblogic

Question

Один из наших веб-логиков 8.1 внезапно начал записывать огромные объемы журналов и заполнять диск.

Бревна, дающие нам Хассел, находятся в

mydrive:\bea\weblogic81\common\nodemanager\NodeManagerLogs\generatedManagedServer1\managedserveroutput.log

и записи в файле журнала — это одни и те же записи, повторяющиеся снова и снова.Такие вещи, как

19:21:24,470 DEBUG [StdRowLockSemaphore] Lock 'TRIGGER_ACCESS' returned by: LLL-SCHEDULER_QuartzSchedulerThread
19:21:31,923 DEBUG [StdRowLockSemaphore] Lock 'STATE_ACCESS' is deLLLred by: QuartzScheduler_LLL-SCHEDULER-NACDLLLF011219763113220_ClusterManager
19:21:31,923 DEBUG [StdRowLockSemaphore] Lock 'STATE_ACCESS' is being obtained: QuartzScheduler_LLL-SCHEDULER-NACDLLLF011219763113220_ClusterManager
19:21:31,923 DEBUG [StdRowLockSemaphore] Lock 'STATE_ACCESS' given to: QuartzScheduler_LLL-SCHEDULER-NACDLLLF011219763113220_ClusterManager
19:21:31,923 DEBUG [StdRowLockSemaphore] Lock 'TRIGGER_ACCESS' is deLLLred by: QuartzScheduler_LLL-SCHEDULER-NACDLLLF011219763113220_ClusterManager

...

19:17:46,798 DEBUG [CascadingAction] cascading to saveOrUpdate: mypackage.config.common.Share
19:17:46,798 DEBUG [DefaultSaveOrUpdateEventListener] reassociated uninitialized proxy
19:17:46,798 DEBUG [Cascade] done processing cascade ACTION_SAVE_UPDATE for: mypackage.config.common.FileLocation
19:17:46,798 DEBUG [Cascade] processing cascade ACTION_SAVE_UPDATE for: mypackage.config.common.FileLocation
19:17:46,798 DEBUG [CascadingAction] cascading to saveOrUpdate: mypackage.config.common.Share
19:17:46,798 DEBUG [DefaultSaveOrUpdateEventListener] reassociated uninitialized proxy

Я нигде не могу найти какие-либо настройки отладки.Я просмотрел путь к классам удаленного запуска и аргументы для управляемого сервера.

Может ли кто-нибудь указать мне, как получить контроль над этим файлом журнала?

Answer 1

Поскольку эти записи журнала не являются проблемами, похоже, что глобальный уровень журнала переведен на DEBUG.Альтернативно, возможно, был реализован новый механизм ведения журнала или новый Appender журнала, который записывает на стандартный вывод и, таким образом, повторно регистрируется Weblogic.Я бы посмотрел конфигурацию вашего регистратора.(Или предоставьте его, если он использует конфигурацию по умолчанию)

Например, при использовании Hibernate с активной настройкой Log4J Hibernate автоматически присоединится к экземпляру Log4J, который вы настроили в своем собственном приложении.

Его можно настроить согласно обычной конфигурации Log4J.В этом примере используется стиль конфигурации свойств:

log4j.category.org.hibernate=WARN

Hibernate может объединяться с другими механизмами ведения журнала через API ведения журнала Apache Commons.Посмотрите, как настроить собственный регистратор и настроить частоты org.hibernate.*.

н.б.При отладке повторное включение

log4j.category.org.hibernate.SQL=INFO or DEBUG

может быть полезным.

Answer 2

Это большая система со множеством программистов?Если это так, возможно, стоит проверить, что нигде в коде конфигурация регистратора не изменяется программно.

В log4j это можно сделать с помощью LogManager или BasicConfigurator занятия.Также через PropertyConfigurator и DomConfigurator.Всего одна мошенническая строка кода может настроить новый Logger на стандартный вывод, используя PatternLayout, показанный в вашем примере.

BasicConfigurator.configure();