Optimal placement of log printing statements under specified overhead threshold(blog.acolyer.org)
blog.acolyer.org
Optimal placement of log printing statements under specified overhead threshold
https://blog.acolyer.org/2017/11/03/log20-fully-automated-optimal-placement-of-log-printing-statements-under-specified-overhead-threshold/
3 comments
> From an operations standpoint [...] many of the logging statements I'd like to see are pretty routine and let me know that something is actually running as expected.
Not to mention that these "everything OK" logs allow to track where exactly some data landed or where to look for more context. Logs are not just for reporting errors.
Not to mention that these "everything OK" logs allow to track where exactly some data landed or where to look for more context. Logs are not just for reporting errors.
Very impressive stuff. We should see more and more of this sort of assistive technology, to alleviate and improve on the manual labour of programming. This isn't a language issue, although perhaps this sort of branch annotation in production systems is the sort of thing a futuristic language runtime might offer.
With that said, I've seen developers write some woefully negligent logging statements that cost millions of dollars in production monthly due to the sheer amount of output that's generated and the extra management and storage costs necessary. When your write amplification from a 1 KB input blows up into 100MB minimum and 50% of that is whitespace or semantically useless statements like "ok" you have to start questioning the value of a log statement in that environment at all.
This is a topic that doesn't get much discussion so I'm glad to see people actually studying it.