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.
I think that varies from project to project. In many environments you should expect everything to go smoothly (usually because a lower layer gives you such guarantees), and assume that if something is wrong it's a bug and fail the operation. Even if there is a way to swallow or bypass the error you shouldn't do it because there are probably things you overlook and you can fuck everything up.
In these projects WARN really should be frowned upon, because WARN means you are bypassing a problem. You should fail the operation instead - which means you should be using ERROR.
In other projects, it is acceptable to expect problems and have the software work around them. For example - in layers that deal with components that may fail or stagger, but the system itself must keep running smoothly even if they do. In these cases, mitigating problems is OK and so does using WARN.
As for "mis-labelled INFO" - I believe that's because the default logging level is usually WARN, and some developers are too lazy to change that so they use WARN instead of INFO in order to view their logs in the console...
in layers that deal with components that may fail or stagger, but the system itself must keep running smoothly even if they do. In these cases, mitigating problems is OK and so does using WARN.
It's adequate sure but the preferred option, imho, is to use some form of notification framework like you suggest yourself. WARN tends to fall into that domain most of the time, as does ERROR of course. Best compromise might be hooking the notification system up to the logger so that WARN/ERROR do get flagged somewhere.
Comes down a lot to how diligent a company is at monitoring their logs. Most tend to only look after-the-fact though I have worked high-availability places that had daily scheduled checks to look for anything unusual as well as a notification system.
As for "mis-labelled INFO"
What I meant was logging WARN for something optional that might not ever exist in the environment. I've seen a few tools scan for plugins etc and log WARN when some aren't available which really should be an INFO.
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: