There are some options available when it comes to logging mechanisms on .Net platform. Fortunately we have standarized log levels.
Currently i am using mostly NLog,this library is very popular and at the moment has all the options i need. There is also Log4Net lib, bit out dated but still good, we are using it at my company mostly because it is used in open source projects integrated into our product. In this post i don’t want to go into details, I just want to talk about logging levels.
Used to log all the details of the function. Parameters, all the actions etc. I am just using it in a more complex debugging process. There is really no need to mess the log files with too much of information.
Turned off by default.
When i am done with debugging, I am converting some of the Trace messages. Just in case I need them and part of the “fixed” code is still not stable enough. Also with some complex algorithms, I am often leaving some Debug log level messages that contain data about transformations and steps performed by the code. This is often very useful, but I am just turning this level when I need additional data.
Only some “big” notifications like new module activated, services started / stopped, or information that user performed some significant action like: logged out. This log should be mainly used to track the big picture and the flow of application. For more detailed information, I am using other type of messages.
First of all, Expected exceptions and some weird behavior that should be noted and there is still possibility to run application. For instance there is a timed job that performs some action that is not affecting overall
Mostly Unhandled exceptions. Errors that are not recoverable and you can’t run the app or perform user action again.
This should be logged when some error causes destabilization of whole app and we know that this will affect all the users.
It can be for instance:
- problem with connecting to the database.
- some important config variable missing that can’t be replaced by default value.
Those are serious errors that should be noted as soon as possible. In one of the project i was sending this kind of errors to my mail so, I can fix them as soon as possible.
- Logging everything is not the way to go. In order to create log you need to write code. Code is our enemy. More code means more maintenance and more bugs. That’s why, I am always defining my logging “strategy” eg. what i need to log, when and why. Most of the time Exception logging is all you need. That’s why you have to treat log levels strategy seriously.
- Debugger is your friend but in some of the projects you don’t have access to production server and you won’t be able to reproduce some failure scenarios. In this situation your only source of information is the logfile
- Even if log file is only a text and you can open it in simple Notepad, I encourage you to use specialized tools like Log2Console.