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' share my thoughts on this topic. Let's start with what hurt us when it comes to logging information from our projects.
I face all those issues myself and on some stage, I started to identify perspectives from which I needed to organize logging in my projects.
At the moment I usually tend to organize a logging strategy as a mix of:
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 best to your particular context
Web app can have following mix of logging perspectives:
Usually, this simple configuration is enough to have some understanding of how our system behaves.
This is the most difficult part when it comes to logging. All team members need to follow the same strategy. There should be common understanding 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 :)
In .Net world I know 2 good libraries:
Both of them have similar functionalities and are very wide.comments powered by Disqus