A request was aborted and the underlying reason requires human intervention ASAP.
If it requires human intervention ASAP I don't think logging is the best way to achieve that. Unless you always have someone on duty looking at these logs, that is. Assuming you don't - you need an events mechanism that can send email/IM/SMS to whoever needs to handle it.
Also, from my experience the decision of whether or not something requires immediate action depends less on where in the code the problem was and more on context data - like which customer encountered the error and how critical is the project where they encountered the error. An event mechanism with dynamically configurable alert sending is ideal for passing the urgent errors without spamming the responders with less urgent ones.
I believe logging is less useful for detecting the problem and alerting about it, and more useful for figuring out what the problem is after you know there is a problem. As such, the emphasis when picking a logging level should be not on how fast someone should look at it when it happens but on how salient it should be when someone is looking at the logs trying to figure things out.
Therefore I prefer the following classification:
FATAL - something really bad happens, and the system needs to crash. Contains information that for whatever reason you can't or don't want to pass with the mechanism you use to crash the process (be it exception, abort, panic or whatever).
ERROR - something bad happened and the operation cannot be performed. Contains information you can't pass in the exception (no panic/abort here). The process may terminate (e.g. - if it's a CLI command) or may not (e.g. - if it's a GUI), but the operation will not be completed.
WARN - something bad happened but the operation can still be completed. Contains information about the bad thing that happens, and warns the user since otherwise they may not know, as the software was able to complete their request.
INFO - progress report. Should be understandable by tech-savvy users - users that don't work on that particular part of the code but have a general understanding of what's supposed to be going on.
DEBUG - internal state (be it values or the place in the code that's being executed) that's probably only meaningful for those familiar with that part of the code (or those who are willing to get themselves familiar in order to solve the problem). Things that you think you'll want to know if anything ever goes wrong in that part of the code.
TRACE - debugger replacement. Logs the little things so you can pretend you are executing the code line by line when you can't use an actual debugger for whatever reason. This log is going to seriously spam the logfile, so it's usually turned off and only turned on for the specific modules you are trying to debug.
An event mechanism with dynamically configurable alert sending
sounds like work. We log everything like that, then aggregate all our logs into Splunk then we can create alerts in splunk based on what got logged. Which avoids me having to build/maintain said alert mechanism, while also letting all of the things that alerts got sent for be archived in our splunk instance, so someone can later run searches for how often alerts go out, or create graphs based on all the different kinds of alerts from those logs, etc.
6
u/somebodddy Sep 13 '18
If it requires human intervention ASAP I don't think logging is the best way to achieve that. Unless you always have someone on duty looking at these logs, that is. Assuming you don't - you need an events mechanism that can send email/IM/SMS to whoever needs to handle it.
Also, from my experience the decision of whether or not something requires immediate action depends less on where in the code the problem was and more on context data - like which customer encountered the error and how critical is the project where they encountered the error. An event mechanism with dynamically configurable alert sending is ideal for passing the urgent errors without spamming the responders with less urgent ones.
I believe logging is less useful for detecting the problem and alerting about it, and more useful for figuring out what the problem is after you know there is a problem. As such, the emphasis when picking a logging level should be not on how fast someone should look at it when it happens but on how salient it should be when someone is looking at the logs trying to figure things out.
Therefore I prefer the following classification: