31–40 of 61 posts
I'm going to weigh in on my opinionated library for logging: [woveon-logger]( https://www.npmjs.com/package/woveon-logger ) (js). Sorry if that's a no-no, but nobody seems to use my much loved library anyway. The multiple levels are nice, especially for logging errors in production and tracking general information of your software. But in development, logging is often about tracking a particular aspect in your code.…
I have always used them as follows. Deciding between DEBUG and INFO is the most difficult. INFO, WARN, and ERROR are simple decisions. DEBUG: Information which is relevant for tracing activity and data through the program. INFO: Important workflow decisions made within the normal operation of the program. Allows you to tell what path a particular operation flowed down, but not with tracing every activity. WARN: Non-f…
What about FATAL errors which prevent the entire program from continuing?
I support these 5 levels of logging, but given the discussion below I also would like to highlight a lesson from an SRE talk I once attended[citation needed] that really there are only three levels of alert: 1. DEBUG - Look at this when debugging, otherwise no one will ever see it. 2. TICKET - Open a ticket and have someone on your team look at this when it gets to the top of your queue. 3. PAGER - Drop what you're d…
Earlier quoted context omitted.
This 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,…
If you're parsing your logs with a machine for triage like you describe, you should be doing structured logging, not string logging.
as an example of DEBUG logging is very wrong. Passwords should not end up in your logs, ever.
Earlier quoted context omitted.
The 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 hav…
Any 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.
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-att...
I support these 5 levels of logging, but given the discussion below I also would like to highlight a lesson from an SRE talk I once attended[citation needed] that really there are only three levels of alert: 1. DEBUG - Look at this when debugging, otherwise no one will ever see it. 2. TICKET - Open a ticket and have someone on your team look at this when it gets to the top of your queue. 3. PAGER - Drop what you're d…
There are also messages which should not trigger a page themselves but will provide useful context when responding to one.
I'm going to weigh in on my opinionated library for logging: [woveon-logger]( https://www.npmjs.com/package/woveon-logger ) (js). Sorry if that's a no-no, but nobody seems to use my much loved library anyway. The multiple levels are nice, especially for logging errors in production and tracking general information of your software. But in development, logging is often about tracking a particular aspect in your code.…
Logging is one of the weirder cross cutting concerns, for many reasons but especially including the one you mention. We had to roll back an upgrade last month because one nonfatal (but still pretty bad) problem was generating a ridiculous amount of log entries. We had no way to turn it off or throttle it, so we rolled back. I have fantasized for years about a programming language with a small runtime that supports in…
Earlier quoted context omitted.
This 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,…
If you're parsing your logs with a machine for triage like you describe, you should be doing structured logging, not string logging.