Logging information on how our application behaves is very often omitted or not properly handled by developers. We don’t know what and when to log. We don’t have a logging strategy. In this post, I’ll share my thoughts on this topic. Let’s start with what hurts us when it comes to logging information from our projects.
Most common issues
- Misunderstanding between log levels in your project and logging information in wrong places
- Not checking logs frequently
- Logging too little information
- Logging too much information
- Logging information in various locations
- Logging unnecessary information
I face all those issues myself and at some stage, I started to identify perspectives from which I needed to organize logging in my projects.
Logging perspectives (how to log)
At the moment I usually tend to organize a logging strategy as a mix of:
- Log level - like info, error, warning
- Log details - for example stack trace
- Log rotation - possibly with archiving strategy
- Log storage - file, database
- Local/remote logging - web service/email/FTP/queue
- Application module creating the log information
Everything depends on the actual context. One program needs a simple log file where all events are stored and the file is removed by the user manually. Another needs remote asynchronous and encrypted way of sending log information - like a mobile app. You, as the system architect, need to figure out what suits your particular context best.
A web app can have the following mix of logging perspectives:
- Log level:error + remote mail + log details - to notify admin about some critical issues that occurred in the system
- Log level:info + log rotation + file storage - to store general system behaviour
Usually, this simple configuration is enough to have some understanding of how our system behaves.
Developers logging agreement (what to log)
This is the most difficult part when it comes to logging. All team members need to follow the same strategy. There should be a common understanding of what to do for event A and what for event B.
What worked for me is to have a document describing what to do in a particular situation. In short: we should always log somewhere. Later, when we see that some log entries are annoying, we can log them somewhere else, so they don’t trigger false alarms for example :)
Tools
In the .Net world I know 2 good libraries:
Both of them have similar functionality and broad feature sets.