> If I was writing an embedded system, or a system
> with soft-to-hard realtime requirements, or one
> where flat straight line performance was the only
> requirement that counted, sure, I might ditch or
> constrain logging.
In one case, a team had been trying for months to debug a problem, but when proper logging was added, the issue was easily fixed.
> in the work I do in my day job, I print out to STDOUT/STDERR and let the platform wick those lines away to a central firehose.
I think this is the correct approach, but (to the nearest approximation) ~every organization I've worked at that does this has hit saturation limits of "the platform" in extremely short order. Especially if you're doing audit-trail-style logging, in my experience, this becomes the primary bottleneck of your infrastructure very quickly.
Re:Logging vs. instrumentation
by jacques_chester on Monday February 08, 2016 @12:17PM
(#11059374)
Did you come up with particular tactics? Any insights on platform bottlenecks?
If I was writing an embedded system, or a system with soft-to-hard realtime requirements, or one where flat straight line performance was the only requirement that counted, sure, I might ditch or constrain logging.
These systems might be common by manufactured volume. But most programmers will never touch one.
You're probably thinking of I/O costs. Again, these aren't as a brutal as they used to be -- SSDs swallow bursty writes with aplomb and when those aren't enough, log-structured filesystems are good at smoothing out writes.
As for myself, in the work I do in my day job, I print out to STDOUT/STDERR and let the platform wick those lines away to a central firehose.