-
Notifications
You must be signed in to change notification settings - Fork 21
Logging conventions
Stefano Rosanelli edited this page Oct 15, 2015
·
6 revisions
- http://commons.apache.org/proper/commons-logging/guide.html#Message%20Priorities/Levels
- https://docs.jboss.org/process-guide/en/html/logging.html
- http://stackoverflow.com/questions/2031163/when-to-use-log-level-warn-vs-error
- http://dev.splunk.com/view/logging-best-practices/SP-CAAADP6
Definitions, examples and actions:
- debug detailed information on the flow through the system (rest request/response) => no action
- info interesting/useful runtime events (service start/stop, configuration assumptions) => no action
- warn runtime situations undesirable or unexpected, but not necessarily "wrong", anything that can potentially cause application oddities, resumable errors (retrying an operation, use of deprecated APIs, poor use of API, missing secondary data) => analyze to find potential errors
- error runtime error fatal to the operation but not to service/application (cant open a required file, missing data) => intervention needed from developer, user or sysadmin
- fatal critical/severe error forcing a shutdown of service/application, risk of data loss/corruption (db connection error) => immediate action from sysadmin or developer
We adopt Cake convention on files, usually each level logged in a file with same name: debug level is found in debug.log files, warn in warn.log and so on...exceptions:
- debug and info could be both in debug.log
- debug and info logs for some particular actions/contexts could go in other files like auth.log, rest.log, export.log to better isolate the relative flow/events
- error and fatal could be in same error.log
- multi-line events should stay in other files like exception.log that may contain details of an error (stack trace, data arrays)
- keep multi-line events to a minimum, even better: avoid multi-line events and/or use specific log files for that purpose
- use IDs like user id or object id, tremendously helpful when debugging or gathering analytics.
- create events that humans can read and log more than just debugging events, put semantic meaning, log anything that may be interesting or useful in debugging/analytics
- identify the source such as class, function, or filename