Log4net/Logging - What have you found to be useful?

Question

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

Answer 1

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.

Answer 2

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.

Answer 3

• All exceptions get logged at ERROR level at the highest level in the call stack that is possible (typically in event handlers etc)
• User input that causes a problem gets logged at WARN level (because it might indicate that we need to improve our UI to better guide the user)
• "Significant" activities get logged at 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)
• Very verbose activities might be logged at DEBUG level

We seldom use FATAL level logging.

We normally deploy with a RollingLogFileAppender at INFO level, and an SmtpAppender at ERROR level.

Answer 4

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:

• 0 code/recompiling to implement it
• has a web ui to view errors
• RSS feed for errors
• can configure it to dump errors to SQL

Answer 5

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
• INFO
• WARNING
• ERROR
• FATAL

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

Answer 6

I use four types of log statements:

• DEBUG
• INFO
• WARNING
• ERROR

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.