Yep, good question. Most Unix/linux sysadmins prefer syslog, whatever
we have on the java+jboss side.
----- Original Message -----
> From: "Jon Choate" <jchoate(a)redhat.com>
> To: engine-devel(a)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
> > 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(a)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
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
"Who's General Failure and why's he reading my disk?"