Logging Policy

One point of view on how logging levels should be used in code.

Mar 28, 2017 2 minutes read

There are different points of view on how logging levels should be used in code. I will share mine.

My assumption is: «There should be no errors in logs when everything is fine.»

The idea is that the strongest log level should trigger alarm causing immediate notification (push or SMS) to operations team.

Accordingly, that’s how logging levels should be used:

  • error – Some action should be taken immediately! Ops team should enable email or sms notifications when a message of that king appears in logs.
  • warn – Some action should be taken, but later.
  • info (enabled by default) – Use this to print information you want to see in logs when your application works normally.
  • debug (disabled by default) – Use it to trace application business logic. Normally this should be disabled on production.
  • trace (disabled by default) – Use it to print raw messages (requests and responses). This is dangerous when you deal with confidential information since you may print it to logs causing security leak.

I saw other approaches to logging:

  • Using separate logger for alerts. – In this case only explicitly specified alerts will be sent. You will never receive an alert from third party component since it does not know about your alert logger.
  • Abusing exceptions, throwing them even in expected cases. – It will cause a lot of information noise in logs making difficult to find really important messages.
  • Not using warn level at all. Just «Black or White» approach. – Why not make use of this logging level making logs more fine-grained?

How the logging is used depends much on type of the business and SLAs required and also on agreements and collaboration between developers and operations team. The mentioned policy may not fit your project and it’s OK :-)

See Also

Secure Java Coding Best Practices

Making your web application flawless against security attacks is a challenge for every java developer. In this article I will briefly describe common practical development techniques that can help you to achieve it.

Secure Java Logging with Logback

Deploying application into secure environment adds some restrictions on logging and log management. OWASP community gives some useful recommendations.

Implementing Automatic Reconnection for Netty Client

One of the first requirement of Netty ISO8588 client connector was the support for automatic reconnect.

One of the first receipts I came across was Thomas Termin’s one. He suggests adding a ChannelHandler which will schedule the calling of client’s connect() method once a Channel becomes inactive. Plus adding ChannelFutureListener which will re-create a bootstrap and re-connect if initial connection was failed.

Although this is a working solution, I had a feeling that something is not optimal. Namely, the new Bootstrap is being created on every connection attempt.

So, I created a FutureListener which should be registered once a Channel is closed.

logo   Never miss a story, subscribe to our newsletter