5:42 a.m.
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/jbos...) 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
8:16 a.m.
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/jbos...) 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.
9:36 a.m.
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
>
(http://gerrit.ovirt.org/#patch,sidebyside,257,3,backend/manager/conf/jbos...)
> 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.
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
6:35 a.m.
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(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
> >
(http://gerrit.ovirt.org/#patch,sidebyside,257,3,backend/manager/conf/jbos...)
> > 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
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?"
8:12 p.m.
----- Original Message -----
From: "Doron Fediuck" <dfediuck(a)redhat.com>
To: engine-devel(a)ovirt.org
Cc: "Laszlo Hornyak" <lhornyak(a)redhat.com>, "Jon Choate"
<jchoate(a)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(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
> > >
(http://gerrit.ovirt.org/#patch,sidebyside,257,3,backend/manager/conf/jbos...)
> > > 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
use syslog.
That sounds like we've recreated our own syslog since syslog aggregates logs from
several different applications and across different machines.
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.
--
/d
"Who's General Failure and why's he reading my disk?"
4:48 a.m.
On Monday 21 November 2011 04:12:57 Jon Choate wrote:
----- Original Message -----
> From: "Doron Fediuck" <dfediuck(a)redhat.com>
> To: engine-devel(a)ovirt.org
> Cc: "Laszlo Hornyak" <lhornyak(a)redhat.com>, "Jon Choate"
<jchoate(a)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(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
> > > >
(http://gerrit.ovirt.org/#patch,sidebyside,257,3,backend/manager/conf/jbos...)
> > > > 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
> 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?"
6:32 a.m.
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(a)redhat.com>
To: "Jon Choate" <jchoate(a)redhat.com>
Cc: "Laszlo Hornyak" <lhornyak(a)redhat.com>, engine-devel(a)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(a)redhat.com>
> > To: engine-devel(a)ovirt.org
> > Cc: "Laszlo Hornyak" <lhornyak(a)redhat.com>, "Jon
Choate"
> > <jchoate(a)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(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
> > > > >
(http://gerrit.ovirt.org/#patch,sidebyside,257,3,backend/manager/conf/jbos...)
> > > > > 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
> > 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?"
4754
days inactive
4757
days old
6 comments
3 participants
participants (3)
-
Doron Fediuck -
Jon Choate -
Laszlo Hornyak