My concern at this point is the lack of configurability of the throttle
time. The underlying implementation supports it but by wrapping it directly
in the logging call, only the default value can be used.
Hmm..do you mean system wide value? We can still have the wrap around frequency
configurable, but unless we want it customized per log line (I’m not sure if
this is really needed?), a system wide config may still be possible to
configure, no?
> On Oct 19, 2020, at 7:04 AM, Alan Carroll
> wro
I strongly suspect we might want it per logging message. At a minimum I
don't think all messages should be throttled in this way, which is also an
answer to Leif' question "how do I know which one to use"? Use the one that
throttles if you want throttling, use the other if you don't want
throttling
Hmm, may be I'm not understanding the intent of the proposed throttling and
the problem we are trying to solve well.
My understanding was that a flood of certain (any) kind of log can result in
significant disk i/o and impact the system throughput and stability and the
proposed throttling is to
I'm addressing the question of "why not do this for all messages?". I think
Neue Brie's approach for specific messages is fine. If, however, the
general logging calls were replaced with it, then you have the
customization problem.
On Mon, Oct 19, 2020 at 10:41 AM Sudheer Vinukonda
wrote:
> Hmm,
Right, but I'm wondering what sort of customization is really needed or what
the use cases are where you'd need different rates of throttling for different
log messages, unless the intent is not protecting the system from flood of
logging (which is basically the same for any kind of log).
The primary case is a zero throttle, that is no throttling. It also seems
plausible to me that different production settings will yield different
levels of "noise" that the ops will want to tune for those local conditions.
On Mon, Oct 19, 2020 at 11:51 AM Sudheer Vinukonda
wrote:
> Right, but I
