The InfluxDB output plugin for Telegraf has a retention_policy property.
Retention policy to write to. Empty string writes to the default rp.
retention_policy = “”
It is not clear how this should be configured. Looking at the InfluxDB docs it appears that one can only create a retention policy in association with a DB. e.g. retention policies can only exist as an attribute of a data base.
If I wanted Telegraf to create a DB with a 45d retention policy, how would I fill out the retention_policy property in the telegraf.conf file?
Alternatively, is there some way within the influxdb configuration to override the default for “auotogen” to be some value less than forever?
@Michael_Ottati If you leave it blank it will write to the DEFAULT retention policy for the database you have configured. To change the autogen database to have a 45d retention period in InfluxDB you would use an ALTER RETENTION POLICY statement.
You can also create databases with and specify the retention policy details:
CREATE DATABASE foo WITH DURATION 45d NAME autogen
Do either of those help?
Thank you but no, that does not answer my question. My question specifically is how to fill out the retention_policy property within the telegraf.conf file so that when Telegraf creates the DB, that retention policy is used.
On first startup of the service Telegraf will create a DB with name specified in the database property. What I want to do is allow Telegraf to create a new DB on first startup as well as specify the retention policy that is associated with it.
I am aware of the alter retention policy statement you alluded to, my current work around for this is to add this line after the telegraf service has been installed and started.
influx -execute ‘alter retention policy “autogen” on “telegraf” duration 45d shard duration 1d’
That is not horrible but it seems unnecessary if the retention_policy property within a configuration file could accomplish the same thing.
@Michael_Ottati That would seem to be logical. This seems like an issue. Do you mind opening one over on telegraf? Your workaround is what I would suggest. We need better support for defining those ‘schema’ type things more declaratively on DB startup.
Okay I’m probably late to the party here but I’ve worked this out.
With a bit of rewiring, I’ve set up a kubernetes job (k8s 1.9.0) that will prime the influx database with:
-
Database to use
-
2 Retention policies
apiVersion: batch/v1
kind: Job
metadata:
name: influx-db-setup
spec:
template:
spec:
containers:
- name: database-creator
image: myrepo/influxdb-primer:1.0.0
imagePullPolicy: Always
command: [“sh”, “-c”, “/tmp/createdbs.sh”]
initContainers:
- name: init-influx-database
image: busybox
command: [‘sh’, ‘-c’, ‘until nslookup influxdb-service; do echo waiting for influxdb-service; sleep 2; done;’]
restartPolicy: Never
(init containers in k8s are supported pre-1.9.0 but is formatted a different way)
My createdbs.sh script is:
#!/usr/bin/env bash
influx -host influxdb-service -import -path=/tmp/databases.txt
And databases.txt:
# DDL
CREATE DATABASE java_services
CREATE RETENTION POLICY oneday ON java_services DURATION 1d REPLICATION 1
CREATE RETENTION POLICY oneweek ON java_services DURATION 7d REPLICATION 1
I can then configure telegraf with the name of the pre-defined database “java_services” and retention policy “oneweek”:
[[outputs.influxdb]]
urls = ["http://influxdb-service:8086"]
database = "java_services" # required
retention_policy = "oneweek"
write_consistency = "any"
This then creates 3 views in chronograf:
- java_services.autogen
- java_service.oneday
- java_services.oneweek
My assumption from here is that you would create a Continuous Query to roll up data to the other retention policy(?)
