Bah. Use cases are specific yet talked about as if they're universal.<p>Let's look at error. If you're running a web server, or something like a web server, then when a request errors you don't want it to blow up the whole server. You just want to log that error. Yet you may not care about the many many other normal requests happening at the info level (and debug would be even more info underneath). Thus now error is actually useful both in terms of monitoring but also separating out from other requests that went through just fine.<p>People say exceptions should blow up the world -- that's great when you're debugging, but users don't typically want to keep reusing an app that crashes. There are more graceful ways to degrade.
I disagree with doing away with the Warning log level. It's very useful for errors that don't negatively impair the function of a program, yet should be captured.<p>For example, converting a user input to an integer. You can provide safe defaults if the value doesn't convert so it doesn't break the flow. As the developer however, if you see too many warnings with conversion errors then you may want to change the label of the form field, or provide some guidance to make it more clear to the user.
I'm kind of dissapointed that the rest of the world didn't pick logging to a circular memory buffer like varnish does. It's proven extremely useful.
You'll have a full firehose of information when you need it without sacrificing performance. You can set up async processes that pick out the bits you need and persist them to disk.<p>I suspect this isn't widely used because it relies on POSIX shared memory and support for keeping data structures in SHM isn't widely available.
I think every starting Go coder snorts in disgust and writes their own logging lib. Then as they get wiser and more experienced in the "Go way" they take another look at the std lib and start to realise the inherent wisdom of the log package. Finally they throw away their over-featured logging lib and refactor everything back to the vanilla log. It's like a zen progression of understanding or something
In terms of part of the solution, ETW[1] is pretty fantastic. It's blindingly fast, strongly typed and rich tooling exists for it (e.g. you can correlate events with performance counters, possibly saving yourself a profiling session). It's not a turn-key logging solution, it's simply a great place to queue your messages to.<p>We don't [yet] use it as part of our logging framework, but recently I used it in a pretty interesting way. We had to make some changes to how we interact with SQL to handle transient faults on the cloud (specifically SQLAzure). Big risky change. In order to guarantee that we didn't mess anything up I sent events to ETW from our data access layer. A separate process would then listen for those ETW events and resolve the stack trace outside of the primary process (something that ETW will do for you). Each stack frame was then sent to a primary server. This allowed us to do <i>very</i> fast code coverage analysis on QA environments for additional guarantees beyond unit tests.<p>Without ETW this would have taken me a week instead of day - it's some really exciting tech. I'd love to see something analogous to ETW in Linux; it has made me realize that textual logging is, frankly, unacceptable.<p>[1]: <a href="https://msdn.microsoft.com/en-us/library/ms751538.aspx" rel="nofollow">https://msdn.microsoft.com/en-us/library/ms751538.aspx</a>
<i>"I believe that an overwhelming proportion of items logged at error level are simple done that way because they are related to an error."</i><p>I think that is a desirable property. When something broke, there's a good chance that those comparatively few lines tell me what and why, and if I'm really lucky give me enough info to reproduce the problem without diving into the more verbose logs (which might not even be generated/captured, if performance concerns preclude).
"Nobody reads warnings, because by definition nothing went wrong."<p>That's a rather bold assertion to make - I look at warnings in logs and approve of their inclusion. Sometimes you want a request to work even when some parts of it aren't quite as expected and in that case the right thing to do is log warnings that something is generating requests that are a bit off and it might be worth investigating <i>that</i> application to find out what is going on:<p>"be liberal in what you accept from others"<p>But log as warnings when you are being liberal... :-)
IMO unstructured is more or less useless in production, most logs cannot be easily parsed, and it influences you to omit useful information. Plus who wants to write dozens of parsing formats :D
I think in this age, the problem of people is not that they log with too many levels: it's that they still `printf` log. I'm always surprised how so few are familiar with structured logging. I'm trying to spread the word:<p>Use Structured Logging!<p><a href="https://docs.google.com/presentation/d/1SnjZpcfJq9r6OpgsjsX9ExCFTQgpXsSjD--Y3PPDiAQ/edit?usp=sharing" rel="nofollow">https://docs.google.com/presentation/d/1SnjZpcfJq9r6OpgsjsX9...</a>
If your log level is at INFO it doesn't matter if you log errors, warnings or fatal: They'll be printed the same way as info, and they give you somewhere to start grepping.