Riesige NodeManagerLogs aus dem Ruhezustand in Weblogic

Question

Einer unserer Weblogic 8.1 hat plötzlich begonnen, riesige Mengen an Protokollen zu protokollieren und die Festplatte zu füllen.

Die Protokolle, die uns Ärger bereiten, liegen darin

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

und die Einträge in der Protokolldatei sind genau die gleichen Einträge, die immer wieder wiederholt werden.Zeug wie

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

Ich kann nirgendwo irgendwelche Debug-Einstellungen finden.Ich habe im Remote-Start-Klassenpfad und in den Argumenten nach dem verwalteten Server gesucht.

Kann mir jemand Hinweise geben, wie ich die Kontrolle über diese Protokolldatei erlangen kann?

Answer 1

Da diese Protokolleinträge kein Problem darstellen, hört es sich so an, als ob die globale Protokollebene auf DEBUG erhöht wurde.Alternativ wurde möglicherweise ein neuer Protokollierungsmechanismus implementiert oder ein neuer Protokoll-Appender, der auf stdout schreibt und daher von Weblogic erneut protokolliert wird.Ich würde mir die Konfiguration Ihres Loggers ansehen.(Oder stellen Sie eine bereit, wenn eine Standardkonfiguration verwendet wird.)

Wenn Sie beispielsweise Hibernate mit einem aktiven Log4J-Setup verwenden, verbindet sich Hibernate automatisch mit der Log4J-Instanz, die Sie in Ihrer eigenen Anwendung eingerichtet haben

Es kann wie in der normalen Log4J-Konfiguration optimiert werden.In diesem Beispiel wird der Eigenschaftenkonfigurationsstil verwendet:

log4j.category.org.hibernate=WARN

Hibernate kann über die Apache Commons-Protokollierungs-API mit anderen Protokollierungsmechanismen verbunden werden.Sehen Sie sich an, wie Sie Ihren eigenen Logger konfigurieren und die org.hibernate.*-Frequenzen ausschalten.

n.b.Beim Debuggen wieder einschalten

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

kann nützlich sein.

Answer 2

Handelt es sich um ein großes System mit vielen Programmierern?Wenn ja, lohnt es sich möglicherweise zu überprüfen, ob die Konfiguration des Loggers an keiner Stelle im Code programmgesteuert geändert wurde.

In log4j kann dies mit dem erfolgen LogManager oder BasicConfigurator Klassen.Auch über die PropertyConfigurator Und DomConfigurator.Nur eine einzige betrügerische Codezeile könnte mithilfe des in Ihrem Beispiel gezeigten PatternLayout einen neuen Logger für die Standardausgabe einrichten.

BasicConfigurator.configure();