Logging is an important aspect of software development, one that is many a time ignored by developers.
it's important to have clean and helpful logs. They can come real handy when you have to debug an issue.
Below are a few important points to keep in mind while writing your logs
1. Using a good API
In my experience,I find the slf4j API better than the others.
Consider this:
in log4j:
logger.debug("Found employee : name: "+name+"designation: "+designation+" department: "+department);
This is difficult to read and has 3 string concatenation.
it can be rewritten with slf4j as
logger.debug("Found employee : name: {} designation:{} department: {}",name, designation, department);
Now, this is more readable, and avoids the string concatenation.
2. Watch what you are logging
Every time you log, watch what you are logging. Sometimes loggers can be the cause of many exceptions
Example 1: logger.debug("User Details :{}", user.getName());
This might throw a null pointer if the user is null
Example 2: logger.debug("User Details :{}", user);
This is an example where the hibernate object has been sent to the logger. This can give way to one or more of these issue :
Out of memory error, N+1 select problem, lazy initialization exception, logs storage completely used up
It' always a good idea only to log the ids of domain objects instead of the complete object. They are enough information for debugging.
Log no more than necessary in release/production, excessive logging can make you app slow.
The following logger format works best for me:
Who(UserName), When (Timestamp), Where(Context, ServletOrPage,Database), What (Command), Result (Exception/Error)
3. Use categories
The severity values INFO, WARN, ERROR, and DEBUG, can be used to filter logs based on the severity.
The benefit that loggers have over System out is the logging categories and levels.
To read more about logging severity, visit
https://www.tutorialspoint.com/log4j/log4j_logging_levels.htm
Logging is an I/O intensive activity and can get in the way of the application's performance, particularly when logging is done in the traditional way that is, synchronously writing to a FileAppender in the context of application threads.
It can often contribute to heavy heap consumption and garbage collection.
hence, excessive logging can lead to performance issues. So be concise, and log relevant data that would help in debugging.
You can also use isDebugEnabled() to prevent filter the logs for production.
4. Log files locally
Use a file local to the server to write the loggers. It provides a local buffer and you aren't blocked if the network goes down.
5. Rotation policies
Log files can get huge. Maintain a rotation policy to roll logs periodically. You can also have a strategy to destroy or back up your log files after a period of time.
it's important to have clean and helpful logs. They can come real handy when you have to debug an issue.
Below are a few important points to keep in mind while writing your logs
1. Using a good API
In my experience,I find the slf4j API better than the others.
Consider this:
in log4j:
logger.debug("Found employee : name: "+name+"designation: "+designation+" department: "+department);
This is difficult to read and has 3 string concatenation.
it can be rewritten with slf4j as
logger.debug("Found employee : name: {} designation:{} department: {}",name, designation, department);
Now, this is more readable, and avoids the string concatenation.
2. Watch what you are logging
Every time you log, watch what you are logging. Sometimes loggers can be the cause of many exceptions
Example 1: logger.debug("User Details :{}", user.getName());
This might throw a null pointer if the user is null
Example 2: logger.debug("User Details :{}", user);
This is an example where the hibernate object has been sent to the logger. This can give way to one or more of these issue :
Out of memory error, N+1 select problem, lazy initialization exception, logs storage completely used up
It' always a good idea only to log the ids of domain objects instead of the complete object. They are enough information for debugging.
Log no more than necessary in release/production, excessive logging can make you app slow.
The following logger format works best for me:
Who(UserName)
3. Use categories
The severity values INFO, WARN, ERROR, and DEBUG, can be used to filter logs based on the severity.
The benefit that loggers have over System out is the logging categories and levels.
To read more about logging severity, visit
https://www.tutorialspoint.com/log4j/log4j_logging_levels.htm
Logging is an I/O intensive activity and can get in the way of the application's performance, particularly when logging is done in the traditional way that is, synchronously writing to a FileAppender in the context of application threads.
It can often contribute to heavy heap consumption and garbage collection.
hence, excessive logging can lead to performance issues. So be concise, and log relevant data that would help in debugging.
You can also use isDebugEnabled() to prevent filter the logs for production.
4. Log files locally
Use a file local to the server to write the loggers. It provides a local buffer and you aren't blocked if the network goes down.
5. Rotation policies
Log files can get huge. Maintain a rotation policy to roll logs periodically. You can also have a strategy to destroy or back up your log files after a period of time.
