Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Five Levels of Logging

aib42.net

Post reply on HN
Print view View original

11–20 of 61 posts

Re: The Five Levels of Logging

#11

Post by testplzignore »

Info: What is the program up to. Occasional messages that indicate it is alive and doing what is expected.

Warn: Problems that you know about and wish would not happen, but do anyways. A service call has failed, unexpected input that violates the contract of the method, etc. You may be handling these conditions gracefully and/or returning an error to the caller, but still want to know when they happen. Usually you should have a ticket open in your bug tracker for these.

Error: Problems that you do not know about. When an error is logged, a developer should look at it. Some kind of action should be taken immediately. Put the fire out if it is an emergency. If not an emergency, create a ticket in your bug tracker, then change the level to warn.

I keep warn and info separate so that I can easily grep/filter on one. I often want to just see info messages to know what the status of things are.

Re: The Five Levels of Logging

#13

Post by maxxxxx »

helper wrote: post #4
sagichmal wrote: post #3

Counterpoint: https://dave.cheney.net/2015/11/05/lets-talk-about-logging tl;dr: Only Info and Debug levels carry their weight.

We 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…

"- 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.

Re: The Five Levels of Logging

#14

Post by yacse »

Logging is very important because it also allows you to debug/resolve issues easily on production systems. But caring about the appropriate log levels and the ability to configure them at runtime is also super important. It's just insane and ridiculous to log everything on a trace/debug level and stream it to the Expensive Innovative Big Data Machine Learning Smart Log Analytics Product. Yes, I'm looking at you Application Insights.

Re: The Five Levels of Logging

#15

Post by js8 »

I increasingly feel that there should be two separate logs, one for the user with the Error/Warning/Info information (what the user wanted to be done and how well it went) and the other for the developer with the Debug/Trace information (capture key information about what the program was doing, especially on the interface - what files it was looking for, what database calls it did etc.).

I always get complaints from users that there is too much useless stuff in the logs through which they need to go. I also think that the developer log should be structured differently, possibly to be easily read by some automation.

Re: The Five Levels of Logging

#16

Post by dionian »

trace: used for visualizing flow of program, extremely noisy and never on prod

debug: low level flow of program, inputs/outputs

info: what I want to see at runtime in prod, high level flow of program, details about operation so I know what's going on if I want to look

warn: things that may indicate errors or other unexpected situations to be aware of that may be relevant to problems elsewhere

error: something serious or unexpected that probably indicates a defect.. issue that needs to be looked into... unhandled/unexpected state

Re: The Five Levels of Logging

#17

Post by ohazi »

dionian wrote: post #16

trace: used for visualizing flow of program, extremely noisy and never on prod debug: low level flow of program, inputs/outputs info: what I want to see at runtime in prod, high level flow of program, details about operation so I know what's going on if I want to look warn: things that may indicate errors or other unexpected situations to be aware of that may be relevant to problems elsewhere error: something serious…

trace: printf debugging

Re: The Five Levels of Logging

#18

Post by jdmichal »

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-fatal errors which do not prevent the operation from completing. Example: Failing to close a file after having read from it.

ERROR: Fatal errors which prevent the operation from completing. Example: Failing to open the file or reading from it.

Re: The Five Levels of Logging

#19

Post by ath0 »

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 doing and handle this, now.

Of course, you want to track INFO and ERROR type messages because a sufficient number of them might cause someone to raise a ticket... but at scale, you probably should've built that monitoring already, and just drop INFO/ERROR down to DEBUG.

Re: The Five Levels of Logging

#20

Post by delinka »

jdmichal wrote: post #18

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?
Post reply on HN