Unless mandated by business requirements, all the log statements should be at minimum logging level. The idea is to reduce the logging overhead as much as possible. Sometimes the overhead is significant to impact application performance.
Use asynchronous logging wherever possible.
Use file rolling and archiving features of the logging framework instead of re-inventing the wheel.
It is a practice among developers to log method entry/exit for troubleshooting. This kind of logging should be done using AOP framework such as Spring AOP, and at debug/trace level. A better practice will be log at only those places where there is a significant processing/turning point.
Do not log any kind of sensitive information such as passwords, credit card numbers, national ids, Personal Identifiable information etc. which could lead to privacy and security issues.
Do not hard-code any credentials (e.g. database credentials when doing database based logging) etc. in logging configuration file.
Do not log huge payloads (such as SOAP request/response etc.) in production but log the important details going out and coming in.
Benchmark the log file growth as per production peak volumes and identify storage requirements (SAN/NAS).
Check regulatory/enterprise guidelines (if any) for the retention period of logs. Device the backup/archival/purge policy accordingly.
Suggest use of log analysis tools such as Splunk or ELK stack for monitoring, troubleshooting, quick searches, dashboards etc.
Secure the log files/sources from external access.
Design a new Framework or Use Existing Framework with a wrapper that can help you capture details better.
Make sure the exception or event is logged only at source. Most of the times, every component participating, in the process, logs the exception/event . This not only leads to unnecessary logging but also sometimes logs incorrect information for tracing the issue.
Have a unique event ID(within application & combination with an application id should make it unique across applications) for every Exception/Process/Event so the Support Group can triage, without much hassle.
Use asynchronous logging wherever possible.
Use file rolling and archiving features of the logging framework instead of re-inventing the wheel.
It is a practice among developers to log method entry/exit for troubleshooting. This kind of logging should be done using AOP framework such as Spring AOP, and at debug/trace level. A better practice will be log at only those places where there is a significant processing/turning point.
Do not log any kind of sensitive information such as passwords, credit card numbers, national ids, Personal Identifiable information etc. which could lead to privacy and security issues.
Do not hard-code any credentials (e.g. database credentials when doing database based logging) etc. in logging configuration file.
Do not log huge payloads (such as SOAP request/response etc.) in production but log the important details going out and coming in.
Benchmark the log file growth as per production peak volumes and identify storage requirements (SAN/NAS).
Check regulatory/enterprise guidelines (if any) for the retention period of logs. Device the backup/archival/purge policy accordingly.
Suggest use of log analysis tools such as Splunk or ELK stack for monitoring, troubleshooting, quick searches, dashboards etc.
Secure the log files/sources from external access.
Design a new Framework or Use Existing Framework with a wrapper that can help you capture details better.
Make sure the exception or event is logged only at source. Most of the times, every component participating, in the process, logs the exception/event . This not only leads to unnecessary logging but also sometimes logs incorrect information for tracing the issue.
Have a unique event ID(within application & combination with an application id should make it unique across applications) for every Exception/Process/Event so the Support Group can triage, without much hassle.