I am always posting provoking post on my Linkedin, and I have decided to replicate those here. Let's socialize!
A quick guide to help produce better logs in your applications.
Record events at the correct level
DEBUG - Used for debugging.
INFO - Informs expected system operation.
WARN - A recoverable problem occurred, but with no user experience impact.
ERROR - An unrecoverable problem occurred, with some user experience impact.
FATAL - Indicates fatal errors. Usually, it means the end of the program.
Best practices
Don’t log sensitive information. Make sure you never log (Passwords, Credit card numbers, Social security numbers…)
On error, log all the available information to reproduce the issue
When calling an external service, in case of error, log the request and response for the called service (exclude PII)
When calling an external service, log the request and response for the called service as DEBUG (exclude PII)
When the service fails to respond to a request, add the request-id as part of the error message response
Consider logging the service response data as DEBUG (Exclude PII)
Consider logging the service request data as INFO (Exclude PII)
Log bad request as a WARNING
Include the stack trace when logging exceptions
Include the thread’s name when logging from a multi-threaded application
Timestamps should be at millisecond resolution (YYYY-MM-DD HH:mm:ss.yyy)
DateTime should be UTC
Logged durations should be milliseconds
Log in JSON format
An error should be handled only once. Logging an error is handling an error. So an error should either be either logged or propagated(re throw), make sure you are handling it on the right layer/place
Enable log level change at runtime. You should be able to change the log level when troubleshooting in prod
Split logs of different levels to different targets to control their granularity. Even if using WARN as the production log level. The application start-up INFO should still be logged.
Log all the important environment configuration info on start up. Ex. Service dependency URLs, server ports and etc.
Audit Best practices
Where possible, always log:
- Input validation failures e.g. protocol violations, unacceptable encodings, invalid parameter names and values
- Output validation failures e.g. database record set mismatch, invalid data encoding
- Authentication successes and failures
- Authorization (access control) failures
- Session management failures e.g. cookie session identification value modification
- Application errors and system events e.g. syntax and runtime errors, connectivity problems, performance issues, third party service error messages, file system errors, file upload virus detection, configuration changes
- Application and related systems start-ups and shut-downs, and logging initialization (starting, stopping or pausing)
- Use of higher-risk functionality e.g. network connections, addition or deletion of users, changes to privileges, assigning users to tokens and etc
OWASP
To learn more check the OWASP logging cheat sheet
Top comments (0)