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 be resilient against such issues. For such issues,
I'm not sure if there's a lot of value in supporting advanced customizations.
If the scope of the requirement is beyond resiliency and if there's a
legitimate use case where throttling when exceeding a rate of 10
occurrences/sec vs 5/sec matters for each given type of log message, then I
guess that's a different problem altogether.
Nevertheless, sounds like a good topic to discuss during the summit?
On Monday, October 19, 2020, 08:23:12 AM PDT, Alan Carroll
<solidwallofc...@verizonmedia.com.invalid> wrote:
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. If you don't know that, you might want to think more carefully
about what you're logging.
On Mon, Oct 19, 2020 at 9:09 AM Sudheer Vinukonda
<sudheervinuko...@yahoo.com.invalid> wrote:
> 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
> <solidwallofc...@verizonmedia.com.invalid> wrote:
> >
> > 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.
>
>
