3 ms·

> ... I disagree with two things: the assumption of incompetence on the part of geophile to not make logging conditional in some way ... I assumed nothing of t

> ... I disagree with two things: the assumption of incompetence on the part of geophile to not make logging conditional in some way ... I assumed nothing of the sort. What I did was identify an anti-pattern and describe an alternative which experience has shown to be a better approach. "Incompetence" is your word, not mine. > ... and adding the label of "anti-pattern" to something that's evidently got so much nuance to it. I fail to see the nuance you apparently can see. >> the non-trivial cost implications of voluminous log output > If log output is conditional at compile time there are no non-trivial cost implications, and even at runtime the costs are often trivial. Cloud deployment requires transmission of log entries to one or more log aggregators in order to be known. By definition, this involves network I/O. Network communication is orders of magnitude slower than local I/O. Useless logging of "function entry/exit, with param values" increases pressure on network I/O. Unless logging is allowed to be lossy, which it never is, transmission must be completed when log buffers are near full capacity. Provisioning production systems having excessive logging can often require more resources than those which do not excessively log. Thus disproving: > ... even at runtime the costs are often trivial. When considering the implication of voluminous log output in a production environment.

strken 1y ago
As I said, conditional. As in, you add logging to your code but you either remove it at compile time or you check your config at run time. By definition, work you don't do is not done.
- TeMPOraL 1y ago
  Conditionals aren't free either, and conditionals - especially compile-time - on logging code are considered by some a bugprone anti-pattern as well. The code that computes data for and assembles your log message may end up executing logic that affects the system elsewhere. If you put that code under conditional, your program will behave differently depending on the logging configuration; if you put it outside, you end up wasting potentially substantial amount of work building log messages that never get used.
  - strken 1y ago
    This is getting a bit far into the weeds, but I've found that debug output which is disabled by default in all environments is quite safe. I agree that it would be a problem to leave it turned on in development, testing, or staging environments.
geophile 1y ago
You are very attached to this "voluminous" point. What do you mean by it? As I said, responding to another comment of yours, a distributed system I worked on produced a few GB a day. The logs were rotated daily. They were never transmitted anywhere, during normal operation. When things go wrong, sure, we look at them, and generate even more logging. But that was rare. I cannot stress enough how much of a non-issue log volume was in practice. So I ask you to quantify: What counts (to you) as voluminous, as in daily log file sizes, and how many times they are sent over the network?
- AdieuToLogic 1y ago
  > You are very attached to this "voluminous" point. What do you mean by it? I mean "a lot" or more specifically; "a whole lot." Here is an exercise which illustrates this. For the purposes here, assume ASCII characters are used for log entries to make the math a bit easier. Suppose the following: Each log statement is 100 characters. Each service invocation emits 50 log statements. Average transactions per second during high usage is 200tps. High usage is on average 2 hours per day. 100 x 50 x 200 x 60 x 60 x 2 = 7_200_000_000 = 7.2GB / day > So I ask you to quantify: What counts (to you) as voluminous, as in daily log file sizes, and how many times they are sent over the network? The quantification is above and regarding log entries being sent over a network - in many production systems, log entries are unconditionally sent to a log aggregator and never stored in a local file system.
  - geophile 1y ago
    7.2G/day doesn't sound terrible. And I'd reduce it by a factor of 25, since in normal operation (i.e., not looking into a problem) I would have either 2 log statements per call (entry, exit), or none at all. It might be more than 2, if I needed detailed logging. But in normal usage, even in the scenario you describe your argument about log volume is not convincing.
geophile 1y ago
BTW, your username is a bit too on-the-nose, given the way you are arguing, using "anti-pattern" as a way to end all discussion.
- AdieuToLogic 1y ago
  > BTW, your username is a bit too on-the-nose ... Resorting to an ad hominem and non sequiturs are we? Really? C'mon, you are better than that.

strken 1y ago

As I said, conditional. As in, you add logging to your code but you either remove it at compile time or you check your config at run time. By definition, work you don't do is not done.

TeMPOraL 1y ago
Conditionals aren't free either, and conditionals - especially compile-time - on logging code are considered by some a bugprone anti-pattern as well. The code that computes data for and assembles your log message may end up executing logic that affects the system elsewhere. If you put that code under conditional, your program will behave differently depending on the logging configuration; if you put it outside, you end up wasting potentially substantial amount of work building log messages that never get used.
- strken 1y ago
  This is getting a bit far into the weeds, but I've found that debug output which is disabled by default in all environments is quite safe. I agree that it would be a problem to leave it turned on in development, testing, or staging environments.

geophile 1y ago

You are very attached to this "voluminous" point. What do you mean by it? As I said, responding to another comment of yours, a distributed system I worked on produced a few GB a day. The logs were rotated daily. They were never transmitted anywhere, during normal operation. When things go wrong, sure, we look at them, and generate even more logging. But that was rare. I cannot stress enough how much of a non-issue log volume was in practice. So I ask you to quantify: What counts (to you) as voluminous, as in daily log file sizes, and how many times they are sent over the network?

AdieuToLogic 1y ago
> You are very attached to this "voluminous" point. What do you mean by it? I mean "a lot" or more specifically; "a whole lot." Here is an exercise which illustrates this. For the purposes here, assume ASCII characters are used for log entries to make the math a bit easier. Suppose the following: Each log statement is 100 characters. Each service invocation emits 50 log statements. Average transactions per second during high usage is 200tps. High usage is on average 2 hours per day. 100 x 50 x 200 x 60 x 60 x 2 = 7_200_000_000 = 7.2GB / day > So I ask you to quantify: What counts (to you) as voluminous, as in daily log file sizes, and how many times they are sent over the network? The quantification is above and regarding log entries being sent over a network - in many production systems, log entries are unconditionally sent to a log aggregator and never stored in a local file system.
- geophile 1y ago
  7.2G/day doesn't sound terrible. And I'd reduce it by a factor of 25, since in normal operation (i.e., not looking into a problem) I would have either 2 log statements per call (entry, exit), or none at all. It might be more than 2, if I needed detailed logging. But in normal usage, even in the scenario you describe your argument about log volume is not convincing.

geophile 1y ago

BTW, your username is a bit too on-the-nose, given the way you are arguing, using "anti-pattern" as a way to end all discussion.

AdieuToLogic 1y ago
> BTW, your username is a bit too on-the-nose ... Resorting to an ad hominem and non sequiturs are we? Really? C'mon, you are better than that.