-
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
Clarify intended usage of retention_policy property in telegraf.conf file. #2696
Comments
It seems that there are two pieces to this: a documentation improvement and feature request for setting telegraf to be able to setup the retention policy. Can you suggest a rewording of the There has been some talk about allowing configuration of connection commands, so maybe we could have RP changes be part of that. #2496 |
I can't knowledgeably suggest a rewording because I don't understand what this property does. If the intent of this property is to act as a selector amongst a collection of existing policies, then it would be good to note that requirement in the description. As currently documented, it is ambiguous. I interpreted the comment as a possibility to specify a custom retention policy. |
Hello, I read your solution about it. Recently I meet a problem. |
@Febeoro There was a good example of how to do this posted to the community site recently: |
Bug report
The intended usage, and legal values for the retention_policy property in the telegraf.conf are not sufficiently documented to understand their usage.
There is a longer thread on the Forum here: How to override retention policy in telegraf.conf?
At minimum, please provide some additional documentation describing the intended usage of this property.
My hope, when I saw this property was that I could use it to set the retention policy of the DB that Telegraf would create for me when the service was started up.
Relevant telegraf.conf:
System info:
Telegraf v1.2.0 (git: release-1.2 b2c1d98)
Use case:
WIthout this feature working we have to do an extra post RPM install step of:
In our specific use case an alternative work around would be if the influx.conf allowed specification of the autogen default to be something different than forever. If that were possible, we would simply make the change within the InflluxDB configuration and call it a day.
The text was updated successfully, but these errors were encountered: