Skip to main content

Clean code, clean logs: easy to read, easy to parse (10/10)

There are two groups of receivers particularly interested in your application logs: human beings (you might disagree, but programmers belong to this group as well) and computers (typically shell scripts written by system administrators). Logs should be suitable for both of these groups. If someone looking from behind your back at your application logs sees:



then you were probably not reading my tips carefully enough. The reference to famous Clean code book in the title of this series is not accidental: logs should be readable and easy to understand just like the code should.

On the other hand, if your application produces half GiB of logs each hour, no man and no graphical text editor will ever manage to read them entirely. This is where old-school grep, sed and awk come in handy. If it is possible, try to write logging messages in such a way, that they could be understood both by humans and computers, e.g. avoid formatting of numbers, use patterns that can be easily recognized by regular expressions, etc. If it is not possible, print the data in two formats:

log.debug("Request TTL set to: {} ({})", new Date(ttl), ttl);
// Request TTL set to: Wed Apr 28 20:14:12 CEST 2010 (1272478452437)

final String duration = DurationFormatUtils.formatDurationWords(durationMillis, true, true);
log.info("Importing took: {}ms ({})", durationMillis, duration);
//Importing took: 123456789ms (1 day 10 hours 17 minutes 36 seconds)


Computers will appreciate "ms after 1970 epoch" time format, while people would be delighted seeing "1 day 10 hours 17 minutes 36 seconds" text. BTW take a look at DurationFormatUtils, nice tool.

I thought this article is going to be short, but after writing it I decided to split it into 10 parts, each in separate post. Hope you enjoyed my logging series, although still not everything has been covered. This only proves how logging is important and how many pitfalls should be avoided. Remember, logging code should also be clean and reading your logs is supposed to be as pleasant as reading your code.


Comments

  1. A good article series on best logging-related practices, thanks.

    I planed to do the same for Python standard logging library, and see some hints from your article series could be transferred to interpreted environment.

    ReplyDelete
  2. Very interesting posts ! Thanks ! One of the tasks that we have to do in the nearest future is to make our logs right (at the moment they are well... not perfect). I will surely ask my colleagues to read your blog before we decide how to improve our logs.

    --
    Tomek Kaczanowski
    http://kaczanowscy.pl/tomek

    ReplyDelete
  3. great articles! Really good job! Thanks!


    --
    Łukasz Stachowiak
    http://blog.lstachowiak.pl

    ReplyDelete
  4. What do you think about logging as cross-cutting concern?

    ReplyDelete
  5. Sure, logging is one of the best cases for AOP. I can't believe I haven't mentioned that in my series, but for instance look here. In this issue I have given an example of how to configure built-in Spring aspect to log method entry/exit.

    ReplyDelete

Post a Comment