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>