logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Irwin" <jasonir...@mail.com>
Subject RE: Logging Best Practice?
Date Mon, 03 Mar 2008 10:09:14 GMT
We currently use:
FATAL - logged.  Failure to correctly handle an exception and recover is a
breach of our standards, the application should not fail unless something it
is dependent on (e.g. database) fails first.  If there is some critical
system error (e.g. server runs out of disc space) then we allow the hosting
application server to handle it.

ERROR - The same as you, although I think we over-log here.  We log every
time an exception is caught before being re-thrown.  This means that lower
classes can log an exception a few times (e.g. insufficient privileges)
before a higher class decides that it's not really an issue and simply
reports to the user they don't have permission.

WARN - Only used in a few areas.

INFO - Not used.

DEBUG - Heavily used, but not in any controlled way.  Seems to include lots
of logging just to tell the developer what method of what class they are in.

TRACE - Not used.

One issue we do have is that not all the logic is contained in the classes,
most is expressed in XML defined rules; so what is not a problem for one
rule is critical for another.  I think this may be part of the reason our
logging looks inconsistent if you just consider the code.

Even so, out logging does work.  We can track problems and solve them but it
seems to me to be pretty slap-dash and it strikes me that there must be a
better/more efficient way to use log4j.  We are looking at performance and
one of the areas which is due for examination is logging.  Less is faster,
but more is useful.  Where is that balance?

As for logging the class/method we are in; that's because we do not have
log4j record that as it is considered too expensive (we're using an older
version 1.2_08).  Our customers just want to "Switch on logging" or "Switch
off logging", they do not want to be told they have to go and edit .ini (or
.xml) files etc.

All this is why I was wondering what people use as best practice.

I like your suggestion about the different levels being held for times.  I
take it you just have a variety of appenders which get enabled/disable as
required?

J.

-----Original Message-----
From: Eric Kolotyluk [mailto:eric.kolotyluk@kodak.com] 
Sent: 29 February 2008 16:35
To: Log4J Users List
Subject: RE: Logging Best Practice?

I'd also be interested in seeing some published best practices.

For now here's my rule-of-thumb

FATAL	- Stuff that is catastrophic enough to warrant escalation back
to the developers for thorough investigation and root-cause analysis.

ERROR	- Stuff that should be investigated. Don't log something as an
error unless you are willing to investigate it yourself.

WARN	- Stuff someone reading the log really needs to pay attention
to. Something you may want to consider investigating.

INFO	- Stuff you want to see from logs of your product at a customer
site to help in troubleshooting an issue. You'll want to be able to save
anywhere from a day's to a week's worth of logs.

DEBUG	- Not enabled by default for released product. Enabled for
general development and prerelease testing. Stuff you want to see to
help you during the development process. You'll want to save at least a
day's worth of logs.

TRACE - Not ever enabled by default. Used during code development to
help understand how things are working. Can produce volumes of output.
Should only be enabled for specific packages, not the whole product.
You'll want to save at least an hour's worth of logs.

One of the big problems with reading logs is "burn out" - seeing too
much stuff logged at too high a priority. If your log contains 10%
ERRORs people grow numb and don't take things seriously.

Cheers, Eric

-----Original Message-----
From: Jason Irwin [mailto:jasonirwin@mail.com] 
Sent: Friday, February 29, 2008 1:38 AM
To: log4j-user@logging.apache.org
Subject: Logging Best Practice?

I've been doing a fair bit of trawling around logging for some best
practice
on logging.  Does anyone know of a good resource?  Or a book which goes
into
detail on this?

 

The levels FATAL and ERROR are pretty self-explanatory.  Are there rules
of
thumb for INFO, WARN, DEBUG and TRACE?

Common metrics for the amount of debugging per class?

What should be logged (e.g. parameter values when entering a method to
DEBUG; or something)

The nature of the logged information (e.g. class, file, method - or not)

 

We already have a lot of logging in our application, but we only make
use of
ERROR and DEBUG levels and I am concerned we are not being as pragmatic
as
we should be with what we are logging.  My feeling is that we under-log
some
information which would help the Support team, and over-log a lot of
irrelevant stuff.  I'd like to be able to back this feeling up.

 

Cheers for any advice,

 

J.


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org


Mime
View raw message