Suggestions for using telegraf without influxdb

[stevenscg]

I'm new to telegraf and this role, but the role looks great!

Do you have any suggestions for using this role with alternate output plugins (librato, datadog, etc) and without influxdb?

It looks like telegraf.conf.j2 could be modified to make the [[outputs.influxdb]] section optional and add a new section [[outputs.{{ plugin.name }}]] similar to the inputs one.

Also in the same file, I see a section header service PLUGINS. What, if anything, was intended to go in there?

Finally, do telegraf administrators typically use /etc/telegraf/telegraf.d/ or not?

[rossmcdonald]

Unfortunately I'm not very familiar with the other available outputs, so there is definitely room for improvement there. Right now the role is very geared towards using InfluxDB as the output, but the input logic could pretty much be copied to the output logic for the same effect (declarative, through yaml). If you end up making any changes, I'd be happy to review a PR if you want to merge them back upstream.

Regarding:

Also in the same file, I see a section header service PLUGINS. What, if anything, was intended to go in there?

That is leftover from an older version and can be disregarded. I'll remove it from the template shortly.

Finally, do telegraf administrators typically use /etc/telegraf/telegraf.d/ or not?

I know some users do, especially if they are on shared servers (each team can manage their own .d config). I personally prefer to keep everything in one file, unless there's a compelling reason not to.

[stevenscg]

I did some customization of the role for my usage and can put it up for you to look at.

Basically, I moved the influx stuff to a template file that is rendered into telegraf.d and made it optional. The "data-driven" outputs templating works great, so I created a similar version of that for inputs plugins. I tried using template files for statsd, datadog, and librato, but ended up ditching those in favor of the data-driven approach.