Jump to content

Logging in application

Posted on:January 1, 2016 at 01:00 AM

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.

Most common issues

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.

Logging perspectives (how to log)

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.

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 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.