4 ms·
Counterpoint: https://dave.cheney.net/2015/11/05/lets-talk-about-logging https://dave.cheney.net/2015/11/05/lets-talk-about-logging tl;dr: Only Info and Debug
by sagichmal 8y ago
Counterpoint: https://dave.cheney.net/2015/11/05/lets-talk-about-logging https://dave.cheney.net/2015/11/05/lets-talk-about-logging
tl;dr: Only Info and Debug levels carry their weight.
- helper 8y agoWe use 3 log levels: - 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).
- maxxxxx 8y ago"- 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)." I always turn on the highest log level unless there is a very strong performance reason against doing so. I have been able to resolve a lot of issues over the years because I had good logging when something went wrong. I don't really see alerts as logging. They are an integral part of the application's behavior.
- nicolaslem 8y agoThe author argues that the error level should not exist because according to him, an error can either be handled or bubble up and logging an error is in a way handling it. If an error is handled, it is not an error anymore. 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.
- sagichmal 8y agoAny exception that bubbles all the way up to a request-scoped catch block indicates a bug in your handler logic. It should probably crash your program, or at least be reported as a structured event to your exception tracking system. In either case, logger.Info is sufficient to record this event in the application logs.
- nicolaslem 8y agoWhy should exception tracking and logging be two separated things? They perform the same job, an exception tracking system is just another way to present log records. The real problem is that people still associate logs with lines of text in a file, whereas most logging frameworks create full objects containing a ton of information[0]. Once you stop considering logs as text, exception tracking and logging really become the same thing. [0] https://docs.python.org/3/library/logging.html#logrecord-attributes https://docs.python.org/3/library/logging.html#logrecord-att...
- Rapzid 8y agoExactly. As a subset of monitoring, it can probably be thought of as eventing; like all monitoring. What's a metric? A measurement event. Etc. Perhaps a name change is in order; Event Tracing for Windows anyone? Eventing.. Event Tracing. IDK.
- sagichmal 8y agoConceptually they are very similar, in the same way that metric data and log data are also very similar. But we don't have good technological solutions to support muxing all streams of observability data together and dealing with them efficiently, either in transport or in storage/query. Good program architecture in 2018 demands some degree of compromise. In my experience it's best to separate console logging (as in this article) from structured logging, from metrics, from distributed tracing, from exception tracking.
- philwelch 8y agoThis works at a very, very small scale where you are reading your logs by hand. At this point, you don't even need log levels. 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.
- sagichmal 8y agoIf you're parsing your logs with a machine for triage like you describe, you should be doing structured logging, not string logging.