I just started using Log4Net and was looking to see what you have found to be useful in your logging experiences.
What types of things have you found to be useful to log; what ended up being just noise; when do you use the different logging levels (DEBUG, INFO, etc); do you have a standard format for each log entry; are there things you ALWAYS log?
Any pitfalls? Good articles on logging in general?
Update: Where do you log to? What Appenders and why?
Thank you!
ERROR level at the highest level in the call stack that is possible (typically in event handlers etc)WARN level (because it might indicate that we need to improve our UI to better guide the user)INFO level (i.e. anything that involves billing a customer's credit card, queries to a third party API etc), including the data involved (typically XML serialized, with any sensitive information removed)DEBUG levelWe seldom use FATAL level logging.
We normally deploy with a RollingLogFileAppender at INFO level, and an SmtpAppender at ERROR level.
I use four types of log statements:
I use DEBUG for statements I want to check during a debugging session. Usually these don't last to the Release Build. This is where I'm checking on a value of a variable or logging the in and out of a method.
I use INFO for connection strings, configuration and general bits of info that I always want to see in a log.
WARNING is used rarely for things I am not sure about or potential error conditions or maybe even check on an exception that I know will get handled up the stack.
I normally only use ERROR in a Catch Block to report on an exception and in an ExceptionHandler that gets called when no other method handled the exception.
Log4Net with Apache Chainsaw. Chainsaw is a dashboard for viewing your log messages from realtime. It can handle multiple apps, perform on-the-fly filtering, and a few other handy features.
If in doubt, log it (preferrably at a higher level like DEBUG or INFO or create your own level). You can configure what gets output in the config file.
I'm basing my response on the excellent response of Robert Kozak, even though I don't quite use my logging the same way
I use five types of log statements:
DEBUG statements are statements which are useful when you are still writing an application, and when you need a complete understanding of what/where your execution flow is. You can use DEBUG statements to measure the queue in front of a lock, or check usernames of users logging in, or even the parameters for a certain SQL call that's been troubling. DEBUG is for statements which are not generally needed to be known.
INFO should be used whenever there is information which will be very useful if something goes wrong, but does not indicate that anything has gone wrong. If you use too many INFO statements, your logs will become bloated and unuseful, so be careful. Use INFO for any critical information which you will need on error, and it is no where near where the error will be throw.
Use WARN level if you have detected a recoverable, but still unexpected (at least a little expected, because you caught it). It indicates that your application MAY be in an unworkable state, but that you believe you can recover/continue on the current execution path.
ERROR warnings are for whenever you catch an unexpected exception. If you are recovering/retrying the current method, I'd suggest using WARN. If you are canceling/bailing out, use the ERROR. Even if your program can continue, ERROR means that you were attempting to do something and were rejected, and are therefore moving on to other things.
FATAL is for use when you catch something at a level far beneath where it was thrown, and you essentially have no idea what's going on. It means you are not even attempting to continue execution, you are simply going to log every possible bit of information at your disposal and then try to exit gracefully. FATAL errors are infrequently used because generally if you catch an error, you have enough information to try and continue execution. But in the scenarios where corruption might occur if you try and continue, log a FATAL error, and then run away.
As for where you're logging to. I usually like to log to a 'shared' folder on my app servers (be careful about permissioning so that they are not public) so that the logs are very easily accessible and they are always my first step for debugging. If possible, set it up so that any errors that are WARNING, ERROR, or FATAL are sent out by email so that you'll have 'advanced' warning.
Cheers
I've found that I get valuable data by setting up projects to use Log4PostSharp at the start of development. Basically, combined with the PostSharp engine, you can place an attribute on methods and it will log all calls with the parameter and return values. I set it up at Debug level in the Assembly.cs file so that it defaults to logging all method calls that aren't property getters or setters.
If left uncontrolled it can produce a huge amount of data (I make sure that I don't log anything else at debug level so that it is easy to switch on and off and remove it entirely from release builds if performance is an issue) but with a good log viewer - I use BareTail - you can pinpoint complicated errors very quickly. It's especially good at determining the method all your different threads were in at the point a problem arose.
I use a rolling file appender so that the most recent data is always available without the files getting to ridiculous sizes.
There's also another logging framework for ASP.NET called ELMAH. Although it's not a true logging framework, but more of an exception framework.
Cool features include:
There's another log4net log viewer (other than the Apache Chainsaw) which my company has been using for some time, it's called "log4net Dashboard" and is being developed by a Norwegian company (I think) called FaktNet, it's website is http://www.l4ndash.com.
It provides a web based dashboard which is quite intuitive and provides a good overview on the log, can be used with many different appenders (such as rolling file or SQL-server appender) but it isn't free as the Apache Chainsaw is. They do have a developer's license though, which is free and allows local use only, which would be sufficient for example for a freelancer wanting to monitor his sites (a single l4n-dashboard can connect to multiple log-sources).
FaktNet has various licenses, depending on how many users are supposed to be able to access the dashboard, and their Enterprise license isn't really expensive (it's $600 I think). Given its ability to access multiple logs it can be a major asset to a development team that's developing and monitoring many medium to large scale websites.
Another really usefull apender is the DBAppender which may log info in a Database, which is obviously incredibly useful so as to query a log.
More info on this in this article.