[Engine-devel] logging in engine

[Doron Fediuck]

On Monday 21 November 2011 04:12:57 Jon Choate wrote:
> 
> ----- Original Message -----
> > From: "Doron Fediuck" <dfediuck at redhat.com>
> > To: engine-devel at ovirt.org
> > Cc: "Laszlo Hornyak" <lhornyak at redhat.com>, "Jon Choate" <jchoate at redhat.com>
> > Sent: Sunday, November 20, 2011 7:35:53 AM
> > Subject: Re: [Engine-devel] logging in engine
> > 
> > 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.
> 
> That sounds like we've recreated our own syslog since syslog aggregates logs from several different applications and across different machines.
> 
Not exactly, we're collecting configurations and coredumps as well. This is not only logging data.

> > 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...
> > 
> 
> Log4J has a syslog appender so switching to syslog would require no code changes other than injecting a new appender. You would still be able to tweak verbosity at runtime. Syslog would also allow you to tee the messages to both a syslog for forwarding to a syslog aggregator and to an application specific log file on the local machine.
> 
> Moreover, syslog is something our users (sysadmins) are comfortable and familiar with and have often built data center monitoring solutions around.
> 
This may cause flooding of the syslog, filling it with messages which may mask host important
issues such as hardware issues, etc. So you can create a filter on message source (facility)
and direct it to a specific file, then you end up with what we already have....

To make is simple, if someone needs it, he can submit a patch with an alternate solution (jboss-log4j.xml.syslog),
and the relevant changes on /etc/syslog.conf, and those who need it can use it.
-- 

/d

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