Logging Policy

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 to on-call engineer.

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

• ERROR – Action should be taken immediately! Ops team should enable PagerDuty or other notification service in order to receive and alert when an ERROR appears in logs.
• WARN – Certain action should be taken, but it can wait till next business day.
• INFO (enabled by default) – Use this to print information you want to see in logs when your application works normally.
• DEBUG (disabled on PROD by default, enabled on DEV) – Use it to trace application business logic. Normally this should be disabled on production and staging environments, but can be enabled on development environment.
• 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.

Some teams practice different 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 it 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 and make logs more fine-grained?

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

Links #

• Yet another logging guidelines