3 ms·

I don't know who downvoted you, though I still disagree. If I was writing an embedded system, or a system with soft-to-hard realtime requirements, or one where

I don't know who downvoted you, though I still disagree. 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.

sagichmal 11y ago
> 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.
- jacques_chester 11y ago
  Did you come up with particular tactics? Any insights on platform bottlenecks?
ktRolster 11y ago
> 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. I've worked on embedded systems, and logging is still extremely important, if not more important because of the difficulty of seeing what's going on (it's hard to reproduce events that only happen in a truck while you're inside your office). 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.

sagichmal 11y ago

> 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.

jacques_chester 11y ago
Did you come up with particular tactics? Any insights on platform bottlenecks?

ktRolster 11y ago

> 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. I've worked on embedded systems, and logging is still extremely important, if not more important because of the difficulty of seeing what's going on (it's hard to reproduce events that only happen in a truck while you're inside your office). 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.