[Engine-devel] logging in engine

[Doron Fediuck]

On Friday 18 November 2011 17:36:16 Laszlo Hornyak wrote:
> Yep, good question. Most Unix/linux sysadmins prefer syslog, whatever we have on the java+jboss side.
> 
> ----- Original Message -----
> > From: "Jon Choate" <jchoate at redhat.com>
> > To: engine-devel at ovirt.org
> > Sent: Friday, November 18, 2011 3:16:11 PM
> > Subject: Re: [Engine-devel] logging in engine
> > 
> > On 11/18/2011 06:42 AM, Laszlo Hornyak wrote:
> > > Hi,
> > >
> > > In oVirt's logging configuration we direct org.ovirt.* loggers to
> > > the engine log appender, org.ovirt.engine.ui to the ui's log and
> > > then the rest to the server log.
> > > The difficulties come when you start to do cross-component
> > > debugging. E.g. you see the logs of the engine in the engine log,
> > > but you would also like to see the logs of the components the
> > > engine is building upon: persistence API's (jdbc, hibernate)
> > > network communication components (e.g. httpclient, vdsm, ssh
> > > client), data processing API's (xml or json-parsers, apache
> > > commons apis) and all these logs go to the generic engine log. So
> > > when debugging you would have to merge these logs, otherwise you
> > > may miss some important details.
> > >
> > > I believe Moti's patch
> > > (http://gerrit.ovirt.org/#patch,sidebyside,257,3,backend/manager/conf/jboss-log4j.xml)
> > > is one step in the another (I believe more useful) direction.
> > > But rather than specifying all the components that the engine uses,
> > > wouldn't it make sense to take just let all the logs flow into a
> > > single appender?
> > >
> > > What is your opinion?
> > >
> > > Thank you,
> > > Laszlo
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > Has any consideration been given to using the syslog appender and
> > sending all messages there? Most data centers already have tools in
> > place for analyzing the contents of syslog.

1. We have a specific log collector tool to collect the relevant logs and configurations
from the setup, since this is not a simple setup. We have hosts we'd like to monitor,
core dumps, etc. So this is not a standalone machine debugging / logging which may
use syslog.
2. Moreover, Java's logging allows you to control log verbosity at runtime. This is
a feature we'd like to preserve, and not re-create all namespaces as filters in syslog...


-- 

/d

"Who's General Failure and why's he reading my disk?"