Since I started my first job in the IT (a looong time ago) I have noticed that every 6 months there are some buzz words that suddenly become trendy and everyone goes crazy for them. This happened for many things (languages, framework, methodologies, OSs, technologies, best practices, etc.) but it never happened for logging (or at least not yet). The importance of logging (and log analysis) for applications and systems today is still something of secondary importance in many environments. Logging is important and it should be done following some best practices: a good logging can give a lot of useful info about the behaviour of an application at runtime and can speed the identification of problems or potencial problems; a bad logging can affect the performances of a system and can lead people in the wrong direction resulting in a loss of time (and money) to find a solution to the wrong problem. In this post I want to show you a list of best practices to follow in application logging. The following suggestions come from years of dealing with any kind of Java application, but they can be applied in general to any application.
Do logging.
This suggestion seems obvious, but it is not. There are still people ignoring logging.
Use a logging tool.
Don't waste time reinventing the wheel: there a lot of great and stable (and often Open Source) logging solutions to manange the logs of your applications.
Use log levels.
Any log message has a different relevance in a particular context. Many messages could be helpful for developers at development or debugging time, but could be meaningless at runtime in a production environment. Try to use all the levels provided by the logging tool your application use and set the proper level for each message. An incorrect choice of the level for messages could affect the performances of an application and doesn't add value in order to monitor the application behaviour.
Log to files.
Don't redirect the log messages to the standard output. Use files instead. Writing load messages to the standard output and error is much slower than writing them to files. This way the impact of logging to performances is very low.
Use file rotation policies.
This will help you in archieving the log files and save a lot of disk space.
Use timestaps inside the messages.
I think there's no need to explain why :)
Add the source to the messages.
Add the source (class, method, etc.) of any log message to the message itself.
Log undestandable and significant info only.
Avoid messages like these:
logger.error("Exception");
(the examples above are taken from real applications).
Any log message should contain really useful info in a human readable format.
Log data coming from external systems.
If an application interact with external system is a good practice to log data coming out from the application and coming in from the external system. This can help a lot the integration process.
Do logging.
This suggestion seems obvious, but it is not. There are still people ignoring logging.
Use a logging tool.
Don't waste time reinventing the wheel: there a lot of great and stable (and often Open Source) logging solutions to manange the logs of your applications.
Use log levels.
Any log message has a different relevance in a particular context. Many messages could be helpful for developers at development or debugging time, but could be meaningless at runtime in a production environment. Try to use all the levels provided by the logging tool your application use and set the proper level for each message. An incorrect choice of the level for messages could affect the performances of an application and doesn't add value in order to monitor the application behaviour.
Log to files.
Don't redirect the log messages to the standard output. Use files instead. Writing load messages to the standard output and error is much slower than writing them to files. This way the impact of logging to performances is very low.
Use file rotation policies.
This will help you in archieving the log files and save a lot of disk space.
Use timestaps inside the messages.
I think there's no need to explain why :)
Add the source to the messages.
Add the source (class, method, etc.) of any log message to the message itself.
Log undestandable and significant info only.
Avoid messages like these:
logger.debug("I'm here");
...
logger.debug("And now I'm here");
or this one:logger.error("Exception");
(the examples above are taken from real applications).
Any log message should contain really useful info in a human readable format.
Log data coming from external systems.
If an application interact with external system is a good practice to log data coming out from the application and coming in from the external system. This can help a lot the integration process.
Comments
Post a Comment