from Hacker News

The Five Levels of Logging

by detay on 9/13/18, 10:06 AM with 59 comments

• by js8 on 9/14/18, 6:42 PM

  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.

• by testplzignore on 9/14/18, 6:23 PM

  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.

• by exabrial on 9/15/18, 1:08 PM

  Talking about logging got me a rejection at Google. The very kind 22 year old interviewing me asked what my thoughts on commenting code was and I said most every time it's used as an excuse to show off a piece of overly clever code, so normally I discourage it in favor of logging, as they are code comments you can use in production. I realize now that was my first graybeard moment.

• by ath0 on 9/14/18, 7:11 PM

  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.

• by Dowwie on 9/14/18, 5:08 PM

  Debug: If you can read this, you are standing too close to the program.

• by tzs on 9/14/18, 6:10 PM

  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 levels of logging is in doubt?

• by xtracto on 9/14/18, 6:20 PM

  This article reminded me of a writing that an ex-colleague of mine did at a previous company: https://nerds.kueski.com/better-logging/

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

• by blaisio on 9/14/18, 10:44 PM

  I really believe only two levels are necessary most of the time: error, and info. Error is for anything that a dev should be notified about (AKA if you send an error log message, assume someone will be notified about it immediately), and info is for any other useful debugging information, like "we got a request for /foo/bar at 10 pm". I also think structured logging is absolutely essential. Log levels are really just a way to get some of the benefits of structured logging.

• by grkvlt on 9/14/18, 8:45 PM

  I was really hoping this might continue with 'six, if you work with IoT devices' or something like that, as in the Larry Miller[0] routine.[1] Never mind, I'll leave the links here anyway...

  0. https://en.wikipedia.org/wiki/Larry_Miller_(comedian)

  1. https://youtu.be/eceSHKqwUPY?t=18

• by kripke on 9/14/18, 9:16 PM

  > Connecting to server:4242 as "user":"hunter2"

  as an example of DEBUG logging is very wrong. Passwords should not end up in your logs, ever.

• by jdmichal on 9/14/18, 7:10 PM

  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.

• by dionian on 9/14/18, 6:48 PM

  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

• by sagichmal on 9/14/18, 5:30 PM

  Counterpoint: https://dave.cheney.net/2015/11/05/lets-talk-about-logging

  tl;dr: Only Info and Debug levels carry their weight.

• by hota_mazi on 9/14/18, 6:20 PM

  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.

• by dstick on 9/14/18, 6:19 PM

  Thanks for this! Was just about to start implementing a logging subsystem myself so the timing is perfect :)

• by cwingrav on 9/14/18, 7:49 PM

  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.

• by stephengillie on 9/15/18, 12:38 AM

  Netscaler logging deserves its own level of hell. You're given 15 undocumented logging levels, with the suggestion not to leave it running longer than necessary, and that level 11 should be enough for anybody.

• by nwmcsween on 9/14/18, 6:27 PM

  The issue with logging levels is they only convey basic information through the levels and the rest through the actual message which results in the mess that is log processing.

• by yacse on 9/14/18, 6:41 PM

  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.