Subject: collectd: Please split each plugin config into a conffile snippet
Date: Wed, 25 Nov 2015 11:35:11 +0100
Package: collectd
Version: 5.5.0-3
Severity: wishlist
Hi!
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.
Thanks,
Guillem
Acknowledgement sent
to Sebastian Harl <[email protected]>:
Extra info received and forwarded to list.
(Wed, 25 Nov 2015 14:21:04 GMT) (full text, mbox, link).
Hi,
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.
Thanks for the feedback.
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.
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.
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
Acknowledgement sent
to Guillem Jover <[email protected]>:
Extra info received and forwarded to list. Copy sent to Sebastian Harl <[email protected]>.
(Fri, 27 Nov 2015 10:33:04 GMT) (full text, mbox, link).
Subject: Re: Bug#806199: collectd: Please split each plugin config into a
conffile snippet
Date: Fri, 27 Nov 2015 11:28:44 +0100
Hi!
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.
> 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?
Thanks,
Guillem
Acknowledgement sent
to Sebastian Harl <[email protected]>:
Extra info received and forwarded to list.
(Tue, 01 Dec 2015 08:39:06 GMT) (full text, mbox, link).
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
Acknowledgement sent
to Witold Baryluk <[email protected]>:
Extra info received and forwarded to list. Copy sent to Sebastian Harl <[email protected]>.
(Fri, 02 Mar 2018 21:45:05 GMT) (full text, mbox, link).
Subject: Re: collectd: Please split each plugin config into a conffile snippet
Date: Fri, 02 Mar 2018 22:24:45 +0100
Package: collectd
Version: 5.8.0-2
Followup-For: Bug #806199
Yes,
please split all plugins into separate files, and make all relevant
statements in these files UNCOMMENTED by default.
Enable plugins by symlinking linking them into collectd.conf.d directory.
This will make updates and local modification SO MUCH EASIER.
Regards,
Witold.
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.15.0-1-amd64 (SMP w/12 CPU cores)
Locale: LANG=pl_PL.utf8, LC_CTYPE=pl_PL.utf8 (charmap=UTF-8), LANGUAGE=pl_PL.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages collectd depends on:
ii collectd-core 5.8.0-2
ii libc6 2.26-6
ii librrd8 1.7.0-1
Versions of packages collectd recommends:
ii default-jre-headless 2:1.8-59
ii intel-cmt-cat 1.2.0-1
ii libatasmart4 0.19-4+b1
ii libcurl3-gnutls 7.58.0-2
ii libdbi1 0.9.0-5
ii libesmtp6 1.0.6-4.3
ii libganglia1 3.6.0-7+b2
ii libgcc1 1:8-20180218-1
ii libgcrypt20 1.8.1-4
ii libgdk-pixbuf2.0-0 2.36.11-1
ii libglib2.0-0 2.54.3-2
ii libgps23 3.17-5
ii libgrpc++1 1.3.2-1
pn libhiredis0.13 <none>
ii libi2c0 4.0-2
ii libip4tc0 1.6.2-1
ii libip6tc0 1.6.2-1
ii libldap-2.4-2 2.4.45+dfsg-1
ii liblua5.3-0 5.3.3-1
ii liblvm2app2.2 2.02.176-4.1
ii libmariadbclient18 1:10.1.29-6
ii libmemcached11 1.0.18-4.2
ii libmicrohttpd12 0.9.59-1
ii libmnl0 1.0.4-2
ii libmodbus5 3.0.6-2
ii libmosquitto1 1.4.15-1
ii libnotify4 0.7.7-3
ii libnspr4 2:4.18-1
ii libnss3 2:3.35-2
ii libopenipmi0 2.0.22-1.1
ii liboping0 1.10.0-1+b2
ii libowcapi-3.1-5 3.1p5-2
ii libpcap0.8 1.8.1-6
ii libperl5.26 5.26.1-5
ii libpq5 10.3-1
ii libprotobuf-c1 1.2.1-2
ii libprotobuf10 3.0.0-9.1
ii libpython2.7 2.7.14-6
pn librabbitmq4 <none>
pn librdkafka1 <none>
ii libriemann-client0 1.9.1-1+b1
ii librrd8 1.7.0-1
ii librte-acl17.11 17.11-5
ii librte-bitratestats17.11 17.11-5
ii librte-bus-pci17.11 17.11-5
ii librte-bus-vdev17.11 17.11-5
ii librte-cfgfile17.11 17.11-5
ii librte-cmdline17.11 17.11-5
ii librte-cryptodev17.11 17.11-5
ii librte-distributor17.11 17.11-5
ii librte-eal17.11 17.11-5
ii librte-efd17.11 17.11-5
ii librte-ethdev17.11 17.11-5
ii librte-eventdev17.11 17.11-5
ii librte-flow-classify17.11 17.11-5
ii librte-gro17.11 17.11-5
ii librte-gso17.11 17.11-5
ii librte-hash17.11 17.11-5
ii librte-ip-frag17.11 17.11-5
ii librte-jobstats17.11 17.11-5
ii librte-kni17.11 17.11-5
ii librte-kvargs17.11 17.11-5
ii librte-latencystats17.11 17.11-5
ii librte-lpm17.11 17.11-5
ii librte-mbuf17.11 17.11-5
ii librte-member17.11 17.11-5
ii librte-mempool-octeontx17.11 17.11-5
ii librte-mempool-ring17.11 17.11-5
ii librte-mempool-stack17.11 17.11-5
ii librte-mempool17.11 17.11-5
ii librte-meter17.11 17.11-5
ii librte-metrics17.11 17.11-5
ii librte-net17.11 17.11-5
ii librte-pci17.11 17.11-5
ii librte-pdump17.11 17.11-5
ii librte-pipeline17.11 17.11-5
ii librte-pmd-af-packet17.11 17.11-5
ii librte-pmd-ark17.11 17.11-5
ii librte-pmd-avp17.11 17.11-5
ii librte-pmd-bnxt17.11 17.11-5
ii librte-pmd-bond17.11 17.11-5
ii librte-pmd-crypto-scheduler17.11 17.11-5
ii librte-pmd-cxgbe17.11 17.11-5
ii librte-pmd-e1000-17.11 17.11-5
ii librte-pmd-ena17.11 17.11-5
ii librte-pmd-enic17.11 17.11-5
ii librte-pmd-failsafe17.11 17.11-5
ii librte-pmd-fm10k17.11 17.11-5
ii librte-pmd-i40e17.11 17.11-5
ii librte-pmd-ixgbe17.11 17.11-5
ii librte-pmd-kni17.11 17.11-5
ii librte-pmd-lio17.11 17.11-5
ii librte-pmd-nfp17.11 17.11-5
ii librte-pmd-null-crypto17.11 17.11-5
ii librte-pmd-null17.11 17.11-5
ii librte-pmd-octeontx-ssovf17.11 17.11-5
ii librte-pmd-octeontx17.11 17.11-5
ii librte-pmd-pcap17.11 17.11-5
ii librte-pmd-qede17.11 17.11-5
ii librte-pmd-ring17.11 17.11-5
ii librte-pmd-sfc-efx17.11 17.11-5
ii librte-pmd-skeleton-event17.11 17.11-5
ii librte-pmd-softnic17.11 17.11-5
ii librte-pmd-sw-event17.11 17.11-5
ii librte-pmd-tap17.11 17.11-5
ii librte-pmd-thunderx-nicvf17.11 17.11-5
ii librte-pmd-vhost17.11 17.11-5
ii librte-pmd-virtio17.11 17.11-5
ii librte-pmd-vmxnet3-uio17.11 17.11-5
ii librte-port17.11 17.11-5
ii librte-power17.11 17.11-5
ii librte-reorder17.11 17.11-5
ii librte-ring17.11 17.11-5
ii librte-sched17.11 17.11-5
ii librte-security17.11 17.11-5
ii librte-table17.11 17.11-5
ii librte-timer17.11 17.11-5
ii librte-vhost17.11 17.11-5
ii libsensors4 1:3.4.0-4
ii libsnmp30 5.7.3+dfsg-1.8
ii libstdc++6 8-20180218-1
ii libtokyotyrant3 1.1.40-4.2+b1
ii libudev1 237-4
ii libupsclient4 2.7.4-7
ii libvarnishapi1 5.2.1-1
ii libvirt0 4.0.0-2
ii libxen-4.8 4.8.2+xsa245-0+deb9u1
ii libxml2 2.9.4+dfsg1-6.1
ii libyajl2 2.1.0-2+b3
ii zlib1g 1:1.2.8.dfsg-5
collectd suggests no packages.
-- Configuration Files:
/etc/collectd/collectd.conf changed:
FQDNLookup true
LoadPlugin syslog
<Plugin syslog>
LogLevel info
</Plugin>
LoadPlugin battery
LoadPlugin cpu
LoadPlugin df
LoadPlugin disk
LoadPlugin entropy
LoadPlugin interface
LoadPlugin irq
LoadPlugin load
LoadPlugin memory
LoadPlugin processes
LoadPlugin swap
LoadPlugin users
<Plugin df>
# ignore rootfs; else, the root file-system would appear twice, causing
# one of the updates to fail and spam the log
FSType rootfs
# ignore the usual virtual / temporary file-systems
FSType sysfs
FSType proc
FSType devtmpfs
FSType devpts
FSType tmpfs
FSType fusectl
FSType cgroup
IgnoreSelected true
</Plugin>
<Plugin rrdtool>
DataDir "/var/lib/collectd/rrd"
</Plugin>
<Include "/etc/collectd/collectd.conf.d">
Filter "*.conf"
</Include>
-- no debconf information
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.