The 10 commandments for writing good logs

Given how easy is to log your application flow these days, it comes as no surprise that many developers abuse and misuse them.  There are many anti-patterns that can be applied to logging and this article tries to help you avoid some of them.

Here’s my list of 10 commandments for logging:

1. Don’t be fancy: avoid formatting the messages and/or adding special characters not related to the event being logged: they add maintenance burden.
   1. This is bad: “****** The application has started ********”
   2. This is good: “The application has started”
2. Be clear: write short statements that go straight to the point. Avoid directly referencing symbols of your code. That makes it easier for production support resources to identify the event in place.
   1. This is bad: “userId=orpiske.net, loginStatus=successful”
   2. This is good: “User ‘orpiske.net’ successfully logged in”
3. Check the spelling and grammar of your log messages. Log messages with spelling and grammar errors sound unprofessional. Include that in the checklist for the peer review sessions.
4. Use the correct message level. If you don’t use them accordingly, there’s a high risk of your support team ignoring them. Eventually, they will miss a message that’s indeed FATAL or that’s indeed a WARNING that something wrong is going on.
5. Do not log too much:
   1. It creates a lot of noise for high volume applications
   2. It increases the I/O and may decrease the performance of your application.
6. Do not forget: the right tool for inspecting your code is called “debugger”.
7. Avoid logging messages into a database: it is a waste of valuable resources, makes it too complicated to maintain and decrease the performance.
   1. If you must log to the database (e.g.: to comply to regulations, legacy designs, etc) then abstract it.
8.  Different transaction types should have different logs. Please note the distinction between transaction types and transaction flows.
9. Logs used to comply with local regulations should be separate from log messages used to trace the transaction flow.
10. Have an style and standard. Document it.