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
Disable [[outputs.influxdb]] in default telegraf.conf #5887
Comments
Thanks for opening the issue. I don't necessarily agree with your expectation that it should be possible to configure Telegraf without modifying the default configuration file, this is not generally how config file plus directory works. For example compare with That said, I think it would be reasonable to move the default plugin configuration into the telegraf.d directory to ease merging on updates #4966. This would make it easier to remove the default configuration. If that seems reasonable to you then I will close this issue and we can follow #4966. |
I agree, that your sources.list example is similar - but though there are some differences. |
For many users getting started, it is nice to start everything with I don't think the logs are a big deal, if my math is correct it only comes out to about 2MB a day, and most systems rotate and compress the logs after that. They also nudge the user in the right direction of what needs done. It's also not currently possible to start Telegraf without an output defined, something that I think is generally a good thing since running without an output is almost always an error. I have seen some packages, shorewall comes to mind, that refuse to start until configured. This isn't something I would consider changing until 2.0, but do you think we should refuse to start until an output is configured? |
I do agree in removing the default influxdb output configuration. Every time I upgrade the telegraf package, it ends up having a config overwrite with the package manager, and I have to do it by hand to disable that all over again. I've made it a practice to just put everything under the telegraf.d folder, so configs are consistent even after the telegraf package is updated. |
Everyone who want's to follow Horrible workaround for now:
|
@beiermi Thanks you for opening this issue 👍 Don't know how long it would have taken me to realize that these authorization errors in the influx log came from a missing In my opinion there shouldn't be a default output which can't be disabled throug Since there is |
@arvenil
|
we're suffering from the same problem, as it breaks our automation on packet-upgrades as it often comes with a changed /etc/telegraf/telegraf.conf we have our custom /etc/telegraf/telegraf.d/foo.conf with everything we need, and it seems our config and the default create 2 different agents or at least targets to send logs to, as our target gets the metrics. so what i don't understand is why our config does simply not overwrite that default. so we need to comment out that line in the /etc/telegraf/telegraf.conf to get rid of this second agent/target. .... i don't understand why we have that /etc/telegraf/telegraf.d when overwriting the default does not work. so something is rather broken here... regards,ivo |
@danielnelson this is not a feature request, this is a rather annoying bug! thanx for changing tags and correctly priorizing |
I'd expect telegraf to be completely configurable without modifying /etc/telegraf/telegraf.conf provided by vendor / rpm package and only adding custom configuration files in /etc/telegraf/telegraf.d.
But the /etc/telegraf/telegraf.conf defines an influxdb output without setting any further options. This results in telegraf trying to contact http://localhost:8086/write?db=telegraf every 10s.
Adding a custom configuration file in /etc/telegraf/telegraf.d, which defines an own influxdb output url, does not change this behaviour.
To change this behaviour and prevent telegraf from useless http requests to localhost:8086, I'd propose disabling/commenting the following line in telegraf.conf:
[[outputs.influxdb]]
The text was updated successfully, but these errors were encountered: