Hi again, I know there's no strict answer on when to use each log level, but here's the final standard I decided on. Maybe others will find it helpful as a starting point.
I did add my own log level, TRACE (for recording metrics), as part of my own extensions to log4net. As seen in the example 'extensions' project in the distribution, such extensions are compiled as a separate assembly so don't affect the original log4net.dll. This lets you add necessary customizations and makes it easy to upgrade log4net in the future. Thanks to those who provided input, Simon. <!-- quote from email to team --> I think it's important for us all to do our logging in the same way, especially when it comes to using the log levels. There are 6 levels of logging; in order of priority from lowest to highest, they are: TRACE, DEBUG, INFO, WARN, ERROR, FATAL. In production we will only turn on WARN (and higher). DEBUG (and higher) would only be used in production if there was a situation that required it. If all goes well we will barely use DEBUG/INFO in production. Here are some guidelines on when we should use each type: TRACE -This should only be used for recording metrics. Likely only to be turned on during performance testing, or in production when trying to find out what part of the site is slow. DEBUG -Use this to log information you might need during a support incident. That is, values of variables, states of your component, etc. INFO -This can be used to record successful events, such as, "User XYZ logged in", or, "Balances for account ABC retrieved successfully". This is also only likely to be used in a support incident. WARN -Use this for recoverable errors. This to put an entry in the log that essentially says, "Hey, something happened here you might want to know about. I can continue, but it may be an indication of something abnormal going on." ERROR -Use this for exceptions and other non-recoverable errors in your code. These are not situations that would warrant someone being paged for, but a list of ERROR events should be reviewed on a daily basis. Recurring errors should be investigated promptly. Perhaps we could have log4net send these events to a mailbox the on-call person would monitor. FATAL -Use this for critical problems that would reduce the functionality of the website. For example, the database is unavailable, or there is no communication with the back-end or one of the vendors. Before using this, ask yourself, "Is this something I'd want anyone to be paged in the middle of the night for?" :) If we follow these guidelines then both our code and the information we store in the log will be consistent!
