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:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
