Logging in application

      No Comments on Logging in application

Logging information 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 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

  • Misunderstanding between log levels in your project and logging information in wrong places
  • Not checking logs frequently
  • Logging to little information
  • Logging to much information
  • Logging information in various locations
  • Logging unnecessary information

I faces 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 logging strategy as a mix of:

  • Log level – like info, error, warning
  • Log details – for example stacktrace
  • 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 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 informations – like 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:

  • 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 how out 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 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 .Net world I know 2 good libraries:

Both of them have similar functionalities and are very widely.

Follow me:

Leave a Reply

Your email address will not be published. Required fields are marked *