[arp242]

I have rarely found logs useful to debug or track down any production issue. Errors on the other hand are almost always useful. I never understood why some people focus so strongly on logs, which tend to always just get ignored, and errors never get noticed.

Maybe one reason is that in many organisations I've seen a lot of "noise" in the error logs, logging things as errors that really aren't errors, which hugely reduces the usefulness. It requires a bit of discipline to keep the error logs clean, but honestly, it's not that hard.

[strken]

Looking at the article, I'm not convinced logs and errors are different enough to change the taxonomy. I agree that a stack trace linked to source code is a useful tool, but don't understand why e.g. a warning can't have a stack trace too, or why your logging system is the wrong place to put this tool.

I've found logs of successes, rather than errors, to be useful for understanding attacks or gnarly performance issues. Seeing that you have a lot of long-running requests for a particular user or tenancy when you're running out of database connections is an example that springs to mind.

[vanschelven]

I had a section "Why" in one of the drafts but scrapped it because I thought it was maybe a bit too harsh. But the gist of it is (IMHO):

* For vendors logging is _awesome_. There's basically no upper limit, you can log all kinds of things, and you can bill them by usage. And because of the scale it's hard to do locally, which is also good news for vendors.

* On the developer-side, there's always the "let's not think about it too much right now, let's just collect a bunch of info" argument for logging. Which is great if you don't want to think (more kindly: if you're facing deadlines)

I'm sure there's good cases for logging (I read logs occasionally too) but it wouldn't be my _first_ thing to heavily invest in (hence the article)