Simon,
I would use FATAL for errors that cause my program to stop functioning alltogether, or close to it. For example, an application of mine monitors several external mailboxes for events and acts on them if they occur. If one of the mailboxes would stop functioning due to an error, I would log that as an ERROR. If my main service that manages the threads that do the monitoring would fail, I would consider this a FATAL error. Admittedly, this is merely the way I intuitively think about it. I am sure there are more "scientifically correct" approaches to logging.
In production, I use DEBUG to log information I MIGHT need during a support incident. That is, values of variables, states of my program, etc. If I would want to go into even more detail (like your example, exiting and entering a function), I would at the moment have to use DEBUG as well, but I would suggest creating (as you did) a lower log level. Or you could use ALL.
The overhead of logging is kept to a minimum in this because you will only turn on DEBUG if there is a situation that requires it. DEBUG is called that for a reason. If all goes well you will barely use it while in production.
Anytime,
Erik
-----Original Message-----
From: Simon Wallis [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 10, 2005 4:48 PM
To: Log4NET User
Subject: RE: when to use each log level
Thanks for your thoughts Erik.
I would have said that FATAL is for serious errors affecting system functionality, and ERRORs were less serious problems that should still be monitored to see if they reoccur.
It seems like your use of WARN is like my ERROR, and your ERROR is like my FATAL. How do you use FATAL events then?
I added a new log level called TRACE which is lower in priority to DEBUG. I use for statistical info.
How do you use DEBUG? Is it just for things like "entering function X", "exiting function X", etc? Or do most people not use that level of detail? If you wanted to investigate why a problem occurred, wouldn't you need such DEBUG statements to do a full investigation? I think the overhead of logging all that in production might be too great though.
Thanks and hopefully others have some input on this too.
Simon.
---------- Original Message ----------------------------------
From: "Burger, Erik" <[EMAIL PROTECTED]>
Reply-To: "Log4NET User" <[email protected]>
Date: Mon, 10 Jan 2005 16:12:37 +0100
>Simon,
>
>I would use INFO for, well, informational messages like 'User 234
>successfully logged in' or statistical information if you shoose to log
>that in this manner. WARN is for non-critical errors like 'Unable to
>access SQL server, but will try again later' that will not greatly
>affect system functionality. ERROR is for problems that WILL affect
>system functionality (like a failure to access the database that cannot
>be recovered from at a later time).
>
>In production, I would (but that's just me) turn on everything except
>DEBUG. At the very least you should turn on everything more severe than
>WARN.
>
>Hope this helps. I would be interested in what others have to say about
>this. Erik
>
>-----Original Message-----
>From: Simon Wallis [mailto:[EMAIL PROTECTED]]
>Sent: Monday, January 10, 2005 3:05 PM
>To: [email protected]
>Subject: when to use each log level
>
>
>Hi,
>
>I would like to set some guidelines for developers in my team on when
>each logging level should be used. Can someone who's been using this
>for a while provide some guidance?
>
>Eg.,
>FATAL - use when a critical system failure happens. This is a situation
>where someone would want to be paged in the middle of the night to fix.
>
>ERROR - for recording exceptions and other definite problem situations.
>You might not need to be paged in the middle of the night, but this is
>important enough that an email should be sent to a mailbox that's
>monitored on a regular basis. Recurring errors need immediate
>attention.
>
>WARN - ???
>
>INFO - ???
>
>DEBUG - self-explanitory. Basic debugging statements that someone would
>only care about if they were investigating a problem with your
>component.
>
>The situation I want to avoid is developers logging things as errors
>when they're not that important, or conversely some people logging
>everything as debug events.
>
>Another question: what is the minimum log level that most people turn
>on in production? Just errors or all levels of logging?
>
>Thanks for your guidance,
>Simon.
>
>The information transmitted by this e-mail message is intended solely
>for the use of the person to whom or entity to which it is addressed.
>The message may contain information that is privileged and
>confidential. Disclosure, dissemination, distribution, review,
>retransmission to, other use of or taking any action in reliance upon
>this information by anyone other than the intended recipient is
>prohibited. If you are not the intended recipient, please do not
>disseminate, distribute or copy this communication, by e-mail or
>otherwise. Instead, please notify us immediately by return e-mail
>(including the original message with your reply) and then delete and
>discard all copies of the message.
>
>Although we have taken precautions to minimize the risk of transmitting
>viruses we nevertheless advise you to carry out your own virus checks
>on any attachment to this message. We accept no liability for any loss
>or damage caused by viruses.
>
>
The information transmitted by this e-mail message is intended solely for the use of the person to whom or entity to which it is addressed. The message may contain information that is privileged and confidential. Disclosure, dissemination, distribution, review, retransmission to, other use of or taking any action in reliance upon this information by anyone other than the intended recipient is prohibited. If you are not the intended recipient, please do not disseminate, distribute or copy this communication, by e-mail or otherwise. Instead, please notify us immediately by return e-mail (including the original message with your reply) and then delete and discard all copies of the message.
Although we have taken precautions to minimize the risk of transmitting viruses we nevertheless advise you to carry out your own virus checks on any attachment to this message. We accept no liability for any loss or damage caused by viruses.
