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

Log level 'error' should mean that something needs to be fixed

utcc.utoronto.ca

Post reply on HN
Print view View original

291–300 of 313 posts

Re: Log level 'error' should mean that something needs to be fixed

#291

Post by TZubiri »

ekidd wrote: post #273
TZubiri wrote: post #216

Earlier quoted context omitted.

I know this is standard practice, but I personally think it's more professional to attach a gdb like debugger to a process instead of depending on coded log statements.

In my professional life, somewhere over 99% of time, the code suffering the error has either been: 1. Production code running somewhere on a cluster. 2. Released code running somewhere on a end-user's machine. 3. Released production code running somewhere on an end-user's cluster. And errors happen at weird times, like 3am on a Sunday morning on someone else's cluster. So I'd just as soon not have to wake up, figurin…

I think I get the idea, gdb is too powerful. For contexts where operator is distinct from manufacturer, the debug/logging tool needs to be weaker and not ad-hoc so it can be audited and to avoid exfiltrating user data.

Re: Log level 'error' should mean that something needs to be fixed

#292

Post by sigseg1v »

TZubiri wrote: post #215
dpark wrote: post #170

Earlier quoted context omitted.

Assuming everything is idempotent is a tall order. There are a lot of libraries that haven non-idempotent actions. There are a lot of inputs that can be problematic to log, too.

Say like opening a file? I guess in those cases standard practice is for lib to return a detailed error yeah. As far as traces, trying to solve issues that depend on external systems is indeed a tall order for your code. Isn't it beyond the scope of the thing being programmed.

From my experience working on B2B applications, I am happy that everything is generally spammed to the logs because there would simply be no other reasonable way to diagnose many problems.

It is very, very common that the code that you have written isn't even the code that executes. It gets modified by enterprise anti virus or "endpoint security". All too often do I see "File.Open" calls return true that the caller has access, but actually what's happened is AV has intercepted the call, blocked it improperly, and returns 0 bytes file that exists (even though there is actually a larger file there) instead of saying the file cannot open.

I will never, in a million years, be granted access to attach a debugger to such a client computer. In fact, they will not even initially disclose that they are using anti virus. They will just say the machine is set up per company policy and that your software doesn't work, fix it. The assumption is always that your software is to blame and they give you nearly nothing, except for the logs.

The only way I ever get this solved in a reasonable amount of time is by looking at verbose logs, determining that the scenario they have described is impossible, explaining which series of log messages is not able to occur, yet occurred on their system, and ask them to investigate further. Usually this ends up being closed with a resolution like "Checked SuperProtectPro360 logs and found it was writing infernal error logs at the same time as using the software. Adjusted the monitoring settings and problem is now resolved."

Re: Log level 'error' should mean that something needs to be fixed

#293

Post by twosdai »

I understand where the author is coming from but frankly I think this design pattern is not really correct.

Obviously this depends on teams, application context and code bases. But "knowing if action needs to be taken" can't be boiled into a simple log level for most cases.

There is a reason most alerting software like pagerduty is just a trigger interface and the logic for what constitutes the "error" is typically some data level query in something like datadog, sumologic, elastic search, or graphana, that either looks for specific string messages, error types, or a collection of metric conditions.

Cool if you want to consider that any error level log needs to be an actionable error but what quickly happens is that some error cases are auto retry able due to infrastructure conditions that the application has completely no knowledge of. And to run some sort of infrastructure query at error write time in code, eg

1. Error is thrown 2. Prior to logging guess/determine if the case can be retired through a few http calls. 3. Log either a warning or an error

Seems to be a complete waste when we could just write some sort of query in our log/metrics management platform of choice which takes into account the infrastructure conditions for us.

Re: Log level 'error' should mean that something needs to be fixed

#294

Post by kgklxksnrb »

bluGill wrote: post #269
kgklxksnrb wrote: post #255

Earlier quoted context omitted.

Logging warnings are cowardly, you just push the decision to the log consumer to decide if the error should be acted on. Warnings are just errors that no one wants to deal with.

Warnings are for where you expect someplace else to know/log if it really is an error but it might also be normal. You might log why a file io operation failed: if the caller recovers somehow it isn't an errer, but if they can't they log an error and when investigating the warning gives the detail you need to figure it out.

Who proactively investigates warnings?

Re: Log level 'error' should mean that something needs to be fixed

#295

Post by dpark »

Retric wrote: post #244
lazyasciiart wrote: post #231

Earlier quoted context omitted.

That’s a very simple operation. Try “take these 100 user generated pdfs and translate all of them”. Oh, “cannot parse unexpected character 0x001?” Cool beans, I wish I knew more.

That’s ok, I’ll just check the log. 50MB of ‘This is my happy place.’ followed by a one liner “cannot to parse unexpected character 0x001?’ Any library can do a bad job here, that doesn’t come down to logging vs error messages.

The unspoken assumption you are making is that anyone who would disagree with your philosophy on this is incompetent.

Re: Log level 'error' should mean that something needs to be fixed

#296

Post by bluGill »

kgklxksnrb wrote: post #294
bluGill wrote: post #269

Earlier quoted context omitted.

Warnings are for where you expect someplace else to know/log if it really is an error but it might also be normal. You might log why a file io operation failed: if the caller recovers somehow it isn't an errer, but if they can't they log an error and when investigating the warning gives the detail you need to figure it out.

Who proactively investigates warnings?

statistacs are someimes run and the most common investigated (normally shut up the noise)

mostly though when you are on a known problem warnings should be a useful filter to find where in the logs the problem might have started, then you use that timestamp to find info logs in the same area

Re: Log level 'error' should mean that something needs to be fixed

#297

Post by Retric »

dpark wrote: post #295
Retric wrote: post #244

Earlier quoted context omitted.

That’s ok, I’ll just check the log. 50MB of ‘This is my happy place.’ followed by a one liner “cannot to parse unexpected character 0x001?’ Any library can do a bad job here, that doesn’t come down to logging vs error messages.

The unspoken assumption you are making is that anyone who would disagree with your philosophy on this is incompetent.

Being incorrect doesn’t imply general incompetence.

Re: Log level 'error' should mean that something needs to be fixed

#298

Post by dpark »

Retric wrote: post #297
dpark wrote: post #295

Earlier quoted context omitted.

The unspoken assumption you are making is that anyone who would disagree with your philosophy on this is incompetent.

Being incorrect doesn’t imply general incompetence.

Your statement that logging would contain zero useful information indicates an assumption of incompetence.

Re: Log level 'error' should mean that something needs to be fixed

#299

Post by fhcuvyxu »

wizzwizz4 wrote: post #289
fhcuvyxu wrote: post #174

Earlier quoted context omitted.

No, many applications need to be fault tolerant. Crashing your web stack because one route hit an error is a dumb idea. And no, calling it a warning is also dumb idea. It is an error. This article is a navel gazing expedition. They're kind of right but you can turn any warning into an error and vice versa depending on business needs that outweigh the technical categorisation.

A log entry marked "CRITICAL" does not imply crashing the web stack.

Right. Was thinking of fatal.

Re: Log level 'error' should mean that something needs to be fixed

#300

Post by Retric »

dpark wrote: post #298
Retric wrote: post #297

Earlier quoted context omitted.

Being incorrect doesn’t imply general incompetence.

Your statement that logging would contain zero useful information indicates an assumption of incompetence.

No, I’m only saying a useless error code and a useless log are both possible. Either could be useful or they could both be useless because the creator was actively malicious etc. Thus, the possibility of a useless error code doesn’t inherently mean a log would improve things.

Really the only thing we can defiantly say is when both approaches are executed well it’s harder to use log entries in your code. If something returns an error that’s tied to a specific call to a specific bit of code, where a log entry could in theory be from anything etc.

Post reply on HN