The Five Levels of Logging
aib42.net
The Five Levels of Logging
1–10 of 61 posts
Re: The Five Levels of Logging
#2Re: The Five Levels of Logging
#3tl;dr: Only Info and Debug levels carry their weight.
Re: The Five Levels of Logging
#4Counterpoint: https://dave.cheney.net/2015/11/05/lets-talk-about-logging tl;dr: Only Info and Debug levels carry their weight.
- Debug: should not show up in normal logs but you can turn it on down to a specific log message in a running process without restarting. We use structured logging so we have the additional ability to turn on debug messages down to a specific key=value pair (or set of key=value pairs).
- Info: An interesting event occurred that someone might care about. This could be an error that we were able to handle or just some important event.
- Alert: An error case that should not happen has occurred and someone needs to look into it. In addition to logging the event, an external system should be notified (e.g. create a ticket, page someone, send an email, etc).
Re: The Five Levels of Logging
#5Counterpoint: https://dave.cheney.net/2015/11/05/lets-talk-about-logging tl;dr: Only Info and Debug levels carry their weight.
I think he is overthinking it a bit. Yes there should be very little places where an error is actually logged, yet is does not mean that it should not exist.
In web applications you very often have one instance of:
try:
return handle_request()
except Exception:
logger.exception('Something bad happened')
return 500
Sure you can argue that as the client received a 500 it is not an error anymore, but this doesn't help you notice and fix the problem.Re: The Five Levels of Logging
#6> I would like to talk about the five (or six, or four) that I find are the most crucial, the fundamental set to base your own levels (and your thinking) on.
Which are the 2 from the 6 given whose status as levels of logging is in doubt?
Re: The Five Levels of Logging
#7Counterpoint: https://dave.cheney.net/2015/11/05/lets-talk-about-logging tl;dr: Only Info and Debug levels carry their weight.
In the real world, you're not going to read your logs unless you're trying to investigate an issue. Instead, you're going to monitor your logs. And this kind of monitoring is where WARN and ERROR become helpful.
WARNs are useful because if you run into a WARN-level issue every now and again, it's no big deal, but if you run into a ton of them, that might indicate a problem that's worth fixing. A single WARN log isn't that useful, but a statistically significant number of WARN logs is a monitorable metric. Being able to detect and address issues after they're serious enough to cause elevated WARNs but before they're serious enough to cause customer impact is worthwhile.
ERRORs are useful because then you have a one-size-fits-all way of monitoring for error conditions, if for example, it's an offline job that doesn't result in a 5xx response. You should still monitor for 5xx responses, pipeline job failures, non-zero exit codes from processes, or whatever your application-level "this didn't end well" signal is. But ERROR logging is also a good metric to have if you want to have multiple log-based metrics all in one place.
Re: The Five Levels of Logging
#8Re: The Five Levels of Logging
#9Give me three levels of logging, 1, 2, and 3, and then warning, and error. Maybe allow to mix and match them, if this makes sense (the typical nomenclature makes them all mutually exclusive, which is dumb).
There are your five levels.
Re: The Five Levels of Logging
#10Everybody developer knows that they should include logging in their systems, however how and what to log is not something so well documented.
When you start working in a system (i.e. at a startup) you put the odd log here and there, without too much attention. However, as your system(s) starts growing, you have to start paying attention at your logs' structure and semantics, so that they are more useful in ELK, Sumologic and similar log searching engines.