Re: Choosing a log level

My personal take is that any logging beyond errors(*) and warnings(*) is pointless.

The only purpose cutesy "informational" messages ("I opened a file", "I wrote to the file", "I closed the file"; etc.) serve, is as a program flow indicator, and as such, the only useful information they carry is the file&line number from which they are produced.

The only time logs are read is when something went wrong. Before that occurrence, informational messages are just clutter, that must be stored, and most time skipped over to find the useful information. And the program lines that produce them are program clutter and a performance drain. Extra, non-functional code that serves no good purpose, but that must be both written and maintained.

If you routinely write informational messages with enough, fine grained frequency to actually help locate where things go wrong, for 99% of the life of the program you are just producing crap that no one is interested in; but that must be written, maintained, stored and archived anyway. You've increased the size (and therefore complexity) of the program by 3 or 4 times; and are producing orders of magnitude of redundant output.

And if you are only producing sporadic broad strokes tracing, when things do go wrong it will not be enough to locate the problem. Trying to predict, when writing a program, where and what information will allow you to find future failures, would require a crystal ball; a pointless exercise.

The only meaningful option (IMO) for logging, beyond errors and warnings, is Devel::Trace style line by line tracing (though I think simple line numbers is better (all that is required) than full source text tracing); which can be turned on and off, on-demand, on a by-module basis.

(*)What constitutes an "error" and what a "warning" is another long debate.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity.

In the absence of evidence, opinion is indistinguishable from prejudice.

Comment on Re: Choosing a log level

Replies are listed 'Best First'.
Re^2: Choosing a log level by SuicideJunkie (Vicar) on Mar 30, 2017 at 15:56 UTC
I would place your examples at more of a DEBUG or higher level. Useful INFO level messages that I've seen include listing off the high level parameters being passed in, summarizing the header info on input data, and noting environmental details. That can help a lot with distinguishing between data getting mangled in your code, or being already wrong before it got to you and whom to blame for it. (Your image isn't cropped... because you told me to not crop it!) If you're logging the right things, it can also help you go back and identify issues that you had no idea were a problem actually worthy of a much more emphatic alert. For example, I had a set of INFO values that are individually all within the original sensible limits, but after a month they clustered into two groups, and the difference between those groups is a key indicator for an undesirable hardware change which now results in an ERROR & delayed FATAL. Based on the INFO level data, the should-have-been-fatal runs could be chased down and redone.	[reply]
Re^3: Choosing a log level by BrowserUk (Patriarch) on Mar 30, 2017 at 20:24 UTC
All I can add is that I do not consider the logging of a program's input parameters and other external inputs (env. vars etc.) as "cutesy informational messages"; as they are crucial to reproducing failing runs. I do consider the logging of subroutine inputs as "cutesy", as they (given access to the program's inputs) are reproducible, on demand, driven by need, at runtime when debugging. Having worked on systems that used extensive logging of every subroutine, function and method parameters, along with every detail of the programs action that the programmer thought might be useful when debugging, and having had to wade through gigabyte after gigabyte of mostly meaningless and always reproducible logs trying to work out where things went wrong, I have a strong aversion to the cutesy, guessed-it-might-be-useful kind of logging. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity. In the absence of evidence, opinion is indistinguishable from prejudice.	[reply]
Re^4: Choosing a log level by Your Mother (Archbishop) on Mar 30, 2017 at 20:43 UTC
I understand your aversion. I share it. The point of multiple log levels is to afford turning off the lesser, super-verbose logging but have the easy option to bring up more, maybe the whole enchilada, when a bug/issue eludes casual debugging. In production, I don’t send anything below FATAL and ERROR to the logs.	[reply]
Re^5: Choosing a log level by BrowserUk (Patriarch) on Mar 30, 2017 at 21:53 UTC
Re^6: Choosing a log level by Discipulus (Canon) on Mar 31, 2017 at 08:33 UTC
Some notes below your chosen depth have not been shown here
Re^4: Choosing a log level by SuicideJunkie (Vicar) on Mar 31, 2017 at 19:52 UTC
I suspect we agree on this, and the difference in in the perspective: Putting Garbage in the INFO, vs the INFO being full of Garbage. INFO would be useful if you only put useful info in. The "cutesy" things which are nominally reproducible given the program's inputs, IMO, should be strictly at DEBUG level and are only useful when you haven't done enough work on the code yet to predict the behaviour with confidence. I usually have those as simple console printing, and then outright delete them when I'm done the first draft of the code and have settled on data structures and variable names. A small few may stick around to serve as progress bars, but those strings end in \r instead of \n so they aren't spammy.	[reply]
Re^5: Choosing a log level by BrowserUk (Patriarch) on Mar 31, 2017 at 20:14 UTC


good chemistry is complicated, and a little bit messy -LW
	PerlMonks