Skip to content
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

Closed
mottati opened this issue Apr 21, 2017 · 4 comments
Closed
Labels
docs Issues related to Telegraf documentation and configuration descriptions
Milestone

Comments

@mottati
Copy link

mottati commented Apr 21, 2017

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:

// Retention policy to write to. Empty string writes to the default rp.
retention_policy = ""

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:

influx -execute 'alter retention policy "autogen" on "telegraf" duration 45d shard duration 1d'

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.

@danielnelson
Copy link
Contributor

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 retention_policy documentation?

There has been some talk about allowing configuration of connection commands, so maybe we could have RP changes be part of that. #2496

@mottati
Copy link
Author

mottati commented Apr 22, 2017

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.

@danielnelson danielnelson added the docs Issues related to Telegraf documentation and configuration descriptions label Apr 27, 2017
@danielnelson danielnelson added this to the 1.3.0 milestone Apr 27, 2017
vlamug pushed a commit to vlamug/telegraf that referenced this issue May 30, 2017
vlamug pushed a commit to vlamug/telegraf that referenced this issue May 30, 2017
jeichorn pushed a commit to jeichorn/telegraf that referenced this issue Jul 24, 2017
jeichorn pushed a commit to jeichorn/telegraf that referenced this issue Jul 24, 2017
@Febeoro
Copy link

Febeoro commented Dec 26, 2017

Hello, I read your solution about it. Recently I meet a problem.
Now I use telegraf to recieve line protocol data and insert data into influxDB. However ,I don't find any solution to solve that different measurements use different retention policies. What can I do to achieve IT?

@danielnelson
Copy link
Contributor

@Febeoro There was a good example of how to do this posted to the community site recently:

https://community.influxdata.com/t/converting-collecd-binary-stream-to-json-with-telegraf-or-collecd-forwarding/1067/9?u=daniel

maxunt pushed a commit that referenced this issue Jun 26, 2018
maxunt pushed a commit that referenced this issue Jun 26, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs Issues related to Telegraf documentation and configuration descriptions
Projects
None yet
Development

No branches or pull requests

3 participants