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

21–30 of 61 posts

Re: The Five Levels of Logging

#21

Post by delinka »

hota_mazi wrote: post #9

I've always preferred levels of logging rather than these arbitrary names (what's the difference between trace and debug, and which one is lower level?). Give 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.

Depending on your Coding Culture, you order them based on "priority" (FATAL would have priority over all others, and therefore numbered as 1), or "importance" (FATAL would be most important, and therefore numbered 5.)

Alternatively, each is a flag in a number so that they can be combined, with FATAL being 1 or 16 depending on priority vs. importance.

I would argue that the names do indeed suffice to tell you their "level" - TRACE is the noisiest, least important, least priority level. DEBUG is next, followed by INFO, WARN, ERROR, FATAL.

Re: The Five Levels of Logging

#22

Post by jandrese »

testplzignore wrote: post #11

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

IMHO the difference between Warn and Error is that Warn is recoverable while Error is not.

Re: The Five Levels of Logging

#23

Post by ryancouto »

delinka wrote: post #20
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?

i think OP is implying that error level and fatal level should be regarded as the same

Re: The Five Levels of Logging

#24

Post by cwingrav »

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. You need something that logs to a particular aspect that you are working on, and then can turn off that aspect once you move on. In the future, you often find yourself back to debug and need to flip that aspect back on again.

Summary: Log levels of info, warn and error all have a place. Logging to aspects is valuable during development, easy to turn off for production and useful when returning to debug.

Re: The Five Levels of Logging

#25

Post by Karrot_Kream »

cwingrav wrote: post #24

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

Wouldn't this be the same as naming loggers? Many logging frameworks allow you to name a logger and just reference that. From there, you can enable or disable named loggers, and get this same "apect" that you talk about.

Re: The Five Levels of Logging

#26

Post by Jarwain »

tzs wrote: post #6

The article is a bit confusing, because the title says 5, the article gives 6 (Error, Warning, Info, Debug, Trace, and Fatal), but the article casts doubt on whether either of those is right when it says this: > 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 lev…

He orders it in terms of relevance too. Note that the last two levels he states are Trace and Fatal. He talks about how Trace may not always be enabled, or how Fatal doesn't necessarily make sense if such an error needs to be handled manually anyways.

Re: The Five Levels of Logging

#27

Post by hinkley »

jandrese wrote: post #22
testplzignore wrote: post #11

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

IMHO the difference between Warn and Error is that Warn is recoverable while Error is not.

In an enterprise setting, treating one level of logs as actionable, as GP mentions, is a very important for clarifying responsibilities.

If it takes the right pair of eyes on the logs to see a problem for what it is, the whole process slows down and doesn't scale as high. All errors and very chatty warnings should induce me to ask someone what's going on, to make sure it hasn't slipped through the cracks. And they should thank me for pointing it out. Otherwise you reinforce some bad patterns.

Re: The Five Levels of Logging

#28

Post by sagichmal »

philwelch wrote: post #7
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.

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.

Re: The Five Levels of Logging

#29

Post by sagichmal »

nicolaslem wrote: post #5
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.

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.

Re: The Five Levels of Logging

#30

Post by hinkley »

cwingrav wrote: post #24

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 instrumentation of the code, not just for debugging and profiling, but for logging as well. Logging becomes a set of conditional breakpoints stored with or at least near the code and you can tweak them individually.

Something akin to applying the 80/20 rule to Aspect Oriented Programming.

We fake this by implementing logging frameworks that try to short circuit out cheaply. But it really only pays off if you can marshal the arguments to the logger very cheaply, and you still have problems with third party code, which can't know that you've got workarounds for problems they consider to be fatal, and are therefore so noisy at the WARN or INFO log levels that you can't see your own log entries (Apache Foundation, I'm looking at you).

Post reply on HN