Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Interval" update in /collectd/collectd.d/ will not affect the plugins already uploaded in collectd.conf #2444

Open
sradco opened this issue Sep 25, 2017 · 8 comments

Comments

@sradco
Copy link
Contributor

commented Sep 25, 2017

  • Version of collectd: 5.7.2
  • Operating system / distribution: Centos7

When we want to update in /collectd/collectd.d/ the interval to a different value then the default, it will not affect the plugins that are loaded by default in the collectd.conf - cpu, memory, interface, disk, rrd plugins.

Expected behavior

Interval should apply to all plugins when it is set in the first file in /collectd/collectd.d/

Actual behavior

Interval will not affect the plugins that are loaded in the collectd.conf.

Steps to reproduce

  • Add a conf file to /collectd/collectd.d/ with Interval different then 10
    Like: Interval 20
  • Check the result

I believe all plugins should not be loaded in the collectd.conf
and only add to the end:
Include "/etc/collectd.d/*.conf"

@octo

This comment has been minimized.

Copy link
Member

commented Sep 25, 2017

Hi @sradco,

if you do the following:

Interval 10
LoadPlugin "foo"
Interval 20
LoadPlugin "bar"

then the foo plugin will have an interval of 10 seconds and the bar plugin will have an interval of 20 seconds. That is because the callbacks are registered as the config is loaded and the foo plugin doesn't "see" the later 20 second interval setting.

Usually the Include "/etc/collectd.d/*.conf" line is the last line in the main config file, meaning that all other settings in the main config file come before that line. I.e. setting the Interval option in a config included in this way will not have any effect on the plugins loaded directly from the main config.

My recommendation would be to set global options, such as Interval in the main config and load plugins from files included from /etc/collectd.d, but the exact layout of the configuration is up to the user / the binary distribution. For Debian, you can file a bug against the collectd/pkg-debian repository.

Hope this helps, best regards,
—octo

@sradco

This comment has been minimized.

Copy link
Contributor Author

commented Sep 26, 2017

Sorry. This issue can be closed. Its a packaging issue.

@sradco sradco closed this Sep 26, 2017
@didib

This comment has been minimized.

Copy link

commented Oct 2, 2017

@octo , I pushed a patch to opstools [1], the repo we use in oVirt. Would upstream collectd be interested in parts of it? Or do you prefer to let packages handle this themselves? Thanks, Didi

[1] https://review.rdoproject.org/r/9802

@didib

This comment has been minimized.

Copy link

commented Oct 2, 2017

I'd personally prefer upstream's conf to only have comments, and only include some/dir.d/*.conf .
However, it seems that Debian uses /etc/collectd/collectd.conf.d , while Fedora/EPEL/CentOS-Opstools uses /etc/collectd.d . So can't consolidate, at least not very easily. So not sure this makes much sense for upstream collectd. Would still like to hear what you think about this. Thanks.

@octo

This comment has been minimized.

Copy link
Member

commented Oct 4, 2017

CC: @tokkee, @mfournier

TL,DR: @didib suggests to comment out all LoadPlugin lines in the default config to make distribution's lives easier.

For more context: the reasoning, back in the day, was that a config with some commonly used plugins loaded would make it easier for users to get started. However, that was a time when collectd was much simpler and it was more common for users to build it from source. These days, I'd argue it's more important to us to cater to the needs of distributions – people building from source usually can handle themselves. Ultimately I see this as your call though.

Best regards,
—octo

@octo octo reopened this Oct 4, 2017
@octo octo added the Cleanup label Oct 4, 2017
@tokkee

This comment has been minimized.

Copy link
Member

commented Oct 22, 2017

From a Debian POV I honestly don't care about the default config because we ship our own config anyway. That said, I'd be happy to talk about unification across distributions -- I think that would make a lot of sense actually.

From an upstream POV, it's really hard to say what's the right default. Given the large number of potential use-cases, I don't think it's actually possible to still have a good default (that's a problem for distributions as well imho).

@didib

This comment has been minimized.

Copy link

commented Oct 23, 2017

I agree it's a problem for distributions too, but a somewhat different one.

For upstream, assuming that these days the main direct users are either distributors or people that know what they are doing, I think it's ok to have everything commented out, perhaps except for a single 'include someplace.d'.

For distributions, I agree it makes sense to provide some non-empty useful default config, but IMO current issue does affect everyone - optional packages and/or users should be able to affect the configuration of loaded-by-default plugins without changing the conf, so these plugins should be loaded from some file inside the include dir, so that it's possible to add files before/after that file.

Re converging distributions: I think it makes sense to have the upstream default same as Debian's ('/etc/collectd/collectd.conf.d'), because I personally find it nicer, and the others (including us - CentOS-OpsTools/oVirt) will have to decide for themselves how to adapt - either ignore upstream until our next major version (where we can more easily break stuff), or create a symlink, include both places, etc.

@jamessevener

This comment has been minimized.

Copy link

commented Feb 20, 2019

Any update on this? It'd be really handy to have a fully commented out default collectd.conf.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.