-
Notifications
You must be signed in to change notification settings - Fork 5.6k
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
[0.11.1] Ordering of config exposed potential race in addOutput() #1090
Comments
thanks for the report, I'll dig into this |
Found the problem, I was relying on the map order to parse various portions of the config, which appears to usually be returned in-order, but sometimes (about 15% of the time) gets returned out-of-order. When out-of-order, the output configs would get loaded before the agent config, resulting in outputs that didn't have the agent config applied! thanks for the report, I'll have the fix merged soon (pr #1130) |
BTW @wrigtim @sebito91 there is also a change coming to the metric_buffer_limit config option that simplifies configuration and buffering. See the 2nd release note here: https://github.com/influxdata/telegraf/blob/master/CHANGELOG.md |
Currently running 0.11.1 with a few internal patches. I noticed our
max_buffer_limit
config was not being respected on some systems, and with some more testing noticed there seems to be a race on startup where the config isn't honored every time?I've since re-ordered our standard config to define [agent] before [outputs], which seems to reduce how easy this is to reproduce (no scientific analysis here as yet!).
Starting the agent twice in quick succession - first starts with metric_buffer_limit of 32768, and the second starts with zero...
PS: the 'created runningoutput' line was added with:
The text was updated successfully, but these errors were encountered: