-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sampling core doesn't seem to have any effect #1032
Comments
Hey there! Yes, your configuration of the Zap sampler is slightly incorrect. If you do the following,
Zap will log the first N messages in The code above sets M to 1: log every message, so it effectively disables sampling.
Unfortunately, the sampler does not yet support setting M to zero. |
The Zap sampling logger accepts three configuration parameters: interval, first, and thereafter. After we see `first` log with the same message in `interval`, the sampler kicks in. Following that, we let through every `thereafter`-th log. So for example, NewSamplerWithOptions(core, time.Second, 100, 50) This will allow 100 logs with the same message in a second, and following that, every 50th message with that message. In #1032, the user wanted the sampler to reject *all* duplicate messages once the limit was reached, but our sampler panics if `thereafter = 0`. This change adds support for setting `thereafter` to 0, dropping all messages in that interval once the limit is reached. It also adds further explanation to the documentation to address the misuse in #1032. Resolves #1032
The Zap sampling logger accepts three configuration parameters: interval, first, and thereafter. After we see `first` log with the same message in `interval`, the sampler kicks in. Following that, we let through every `thereafter`-th log. So for example, NewSamplerWithOptions(core, time.Second, 100, 50) This will allow 100 logs with the same message in a second, and following that, every 50th message with that message. In #1032, the user wanted the sampler to reject *all* duplicate messages once the limit was reached, but our sampler panics if `thereafter = 0`. This change adds support for setting `thereafter` to 0, dropping all messages in that interval once the limit is reached. It also adds further explanation to the documentation to address the misuse in #1032. Resolves #1032
@mholt We've added support for a zero value of M. It will let you do the following to log at most 2 messages per 5 second interval.
We won't release this until January, though.
|
Ohh, thank you -- I was wondering what N and M were referring to, as I couldn't find them in the method signature. And I tiotally misunderstood M, I realize now it's part of a ratio. Really appreciate the update too, that'll be useful going forward. Thanks again! |
I'm trying to limit the excessive output of some very active logs, the same two messages repeating (same logger) thousands of times per second.
I figured that wrapping my custom core in a
NewSamplerWithOptions()
would do the trick:I thought I could expect about 2 log messages per 5 seconds with this configuration, but I'm still seeing a firehose of thousands of the same logs every second, completely obliterating the performance of the app (writing the logs to the outputs is slowing it down).
Am I using it wrong? 😅
The text was updated successfully, but these errors were encountered: