Giant NodeManagerLogs из спящего в weblogic

Question

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

Журналы, дающие нам hassel, находятся в

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

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

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

BasicConfigurator.configure();

Answer 2

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

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

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

log4j.category.org.hibernate=WARN

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

n.b. При отладке снова включите

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

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