Introduction to Log Levels
There are different ways to log messages. In order of fatality log levels have been defined as:
Trace – Only when I would be “tracing” the code and trying to find one part of a function specifically.
Warn – Anything that can potentially cause application oddities, but for which I am automatically recovering. (Such as switching from a primary to backup server, retrying an operation, missing secondary data, etc.)
Error: Any error which is fatal to the operation, but not the service or application (can’t open a required file, missing data, etc.). These errors will force user (administrator, or direct user) intervention. SysAdmin should be notified automatically but doesn’t need to be dragged out of bed.
By filtering a log to look at errors and above you get an overview of error frequency and can quickly identify the initiating failure that might have resulted in a cascade of additional errors
Fatal: Any error that is forcing a shutdown of the service or application to prevent data loss.A Fatal error only occurs once in the process lifetime, so if the log file is tied to the process, this is typically the last message in the log.
Examples for each log level:
Fatal – can’t allocate memory, database, etc – can’t continue.
Error – no reply to message, transaction aborted, can’t save file, etc.
Warning – resource allocation reaches X% (say 80%) – that is a sign that you might want to re-dimension your.
Info – user logged in/out, new transaction, file crated, new d/b field, or field deleted.
Debug – dump of internal data structure, Anything Trace level with file name & line number.
Trace – action succeeded/failed, d/b updated.
Conclusion
So generally in your program you do DEBUG, INFO and WARN logging. And only if you are writing some web service/framework you will use FATAL. And when you are debugging application you will get TRACE logging from this type of software.
