Giant NodeManagerLogs de mise en veille prolongée dans weblogic

Question

L'un de nos weblogic 8.1 a soudainement commencé à enregistrer d'énormes quantités de journaux et à remplir le disque.

Les journaux nous donnant Hassel résident dans

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

et les entrées dans le fichier journal sont exactement les mêmes types d'entrées répétées encore et encore.Choses comme

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

Je ne trouve aucun paramètre de débogage défini nulle part.J'ai regardé dans le chemin de classe et les arguments de démarrage à distance pour le serveur géré.

Quelqu'un peut-il m'indiquer comment prendre le contrôle de ce fichier journal ?

Answer 1

Étant donné que ces entrées de journal ne posent pas de problèmes, il semble que le niveau de journalisation global ait été augmenté sur DEBUG.Alternativement, peut-être qu'un nouveau mécanisme de journalisation a été implémenté ou qu'un nouvel appender de journal écrit sur la sortie standard et est donc reconnecté par Weblogic.Je regarderais la configuration de votre enregistreur.(Ou fournissez-lui-en un, s'il utilise une configuration par défaut)

Par exemple, lorsque vous utilisez Hibernate avec une configuration Log4J active, Hibernate se joindra automatiquement à l'instance Log4J que vous avez configurée dans votre propre application.

Il peut être réglé, selon la configuration normale de Log4J.Cet exemple utilise le style de configuration des propriétés :

log4j.category.org.hibernate=WARN

Hibernate peut se joindre à d'autres mécanismes de journalisation via l'API de journalisation Apache Commons.Regardez comment configurer votre propre enregistreur et désactiver les fréquences org.hibernate.*.

n.b.Lors du débogage, remise sous tension

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

peut être utile.

Answer 2

Est-ce un grand système avec de nombreux programmeurs ?Si tel est le cas, il vaut peut-être la peine de vérifier que nulle part dans le code la configuration de l'enregistreur n'est modifiée par programme.

Dans log4j, cela peut être fait en utilisant le LogManager ou BasicConfigurator Des classes.Également via le PropertyConfigurator et DomConfigurator.Une seule ligne de code malveillante pourrait configurer un nouveau Logger sur la sortie standard à l'aide du PatternLayout présenté dans votre exemple.

BasicConfigurator.configure();