Hi, On Fri, Nov 27, 2015 at 11:28:44AM +0100, Guillem Jover wrote: > On Wed, 2015-11-25 at 15:13:23 +0100, Sebastian Harl wrote: > > On Wed, Nov 25, 2015 at 11:35:11AM +0100, Guillem Jover wrote: > > > To ease customization, it would be nice if each default plugin > > > configuration (LoadPlugin and Plugin stanzas), or at least related > > > groups of them, could be moved into their own plugin-(name|group).conf > > > under /etc/collectd/collectd.conf.d/, so that they could be modified > > > locally w/o triggering a conflict with changes on the rest of the > > > conffile on upgrades, or to be able to disable specific plugins by > > > just renaming them. > > > I considered a plugins.available.d / plugins.enabled.d approach before, > > similar to how Apache or Nginx work on Debian. My only concern is that > > it would be a long list of files some of which would only include the > > LoadPlugin line since there's no further configuration to a lot of > > plugins. This may be less convenient to what we have today, so I'm not > > sure about the best option. Hence, I'd be happy about any feedback on > > this. > > Right. I guess an option could be to start by splitting out config > fragmants for plugins that have a Plugin stanzas. That should help > with the bulk of the customizations. Having to deal with the main > config that only contains the remaining list of LoadPlugin would be > easier in comparison.
So, the overall goal here is to improve ease of use. Updating and merging the config is one aspect imho and consistency another. Having things in "one place" also plays into it imho (easy to search for stuff). I think consistency speaks against a mixed approach so I'd (lightly) tend towards splitting out *all* plugins into separate files if we go that route. What'd you think about splitting the config into one file per plugin with the LoadPlugin statement and commented Plugin blocks and then also providing a combined file as, for example, collectd.conf.sample to make it easier for people to switch back? > > I think groups are even harder to get right because I don't think > > there's much of natural grouping so any approach would be very use-case > > specific. > > With groups, I was thinking on basic grouping for very strongly related > ones such as curl*, membache[cd] or redis and write_redis, but perhaps > even then there's no point in grouping these? I think there isn't. I don't think there's a higher correlation between using those plugins in parallel than any other plugins (maybe it's even lower because you'd usually only use one from each group). Thanks for your feedback so far! Cheers, Sebastian -- Sebastian "tokkee" Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin
signature.asc
Description: Digital signature
