Centralized Configuration

I’d like to modify Telegraf to load a configuration from a REST service, and could use some advice.

  • Would it make more sense to:
    • Write an input plugin that checked for updates, downloaded new config files, and sent a SIGHUP to reload the configuration (relatively simple, but not what an input plugin is meant for) or
    • Modify the core service, similar to the reload modification (more complex, but more appropriate to the architecture)
  • Is there any interest in this feature? Should I open a pull request and submit it back to the community?
  • Is anyone else already working on something similar and interested in collaborating?

We are planning to add support for config plugins, but the code is currently only in the early prototype stage.

Any HTTP config plugin would need to be general purpose enough that it could be useful for many people, but not excessively difficult to configure. You could open an issue on github to work on designing this, though we can’t get too far until the configuration plugin is further along.

Similar to your first proposal, you could use the exec plugin to run your custom code, or the code could be completely independent of Telegraf, similar to how confd works.

1 Like

Thanks for the feedback! I’ll work with an exec plugin for now and keep watch for updates on config plugins in the future.

Following up from my comment on the issue you linked, @daniel, I was wondering if there’s anything I/we can do to help with the config plugins concept.

I have since realized that this file could basically become a config plugin along the lines of the REST service access you originally mentioned, @cruscio.

The best thing is helping with the items in the contributing list, especially the first 4 items.