[Engine-devel] logging in engine

[Jon Choate]

Got it.  Maybe the long term solution will be some nice person making an oVirt plugin for Nagios, Splunk etc.
As I think about it I realize its better to defer it until we have a real requirement for it anyway.

----- Original Message -----
> From: "Doron Fediuck" <dfediuck at redhat.com>
> To: "Jon Choate" <jchoate at redhat.com>
> Cc: "Laszlo Hornyak" <lhornyak at redhat.com>, engine-devel at ovirt.org
> Sent: Monday, November 21, 2011 5:48:34 AM
> Subject: Re: [Engine-devel] logging in engine
> 
> 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?"
>