voxpupuli
Allow the getval task to work with customized hostnames
Pull Request (PR) description
The default hostname used by collectd is system dependent as retuned by gethostname(3) (On FreeBSD it's the FQDN, while on Linux it's the non-FQDN). The python method socket.gethostname() always return a non-FQDN, and the user has the ability to tune the hostname as he wish in the collectd configuration (hostname parameter).
This change allow to use a customized hostname by using an optional argument "hostname". When not provided, the non-FQDN and the FQDN are tried in turn to fetch the requested metric value.
This Pull Request (PR) fixes the following issues
n/a
Rather than passing the hostname which will be different for every host can something be done with a fact name. Pass a factname and then that be used.
Trouble is I can't remember much how this stuff works.
Ah yes, didn't thing that passing the hostname does not scale beyond 1 node… Maybe we can just use hostname, and fallback to fqdn (so no custom values). We can also look for a setting in /etc/collectd/collectd.conf before falling back but some systems will use e.g. /usr/local/etc/collectd/collectd.conf…
Not ideal… What do you think ?
Parsing collectd.conf seems a bit yuck.
We use:
FQDNLookup true
Sending a fact name of choice as a parameter then the user can specify if they want networking.fqdn or networking.hostname
I never realised you do a getval without the hostname.
collectdctl getval ai-catalog-diff/gauge-return_code
works perfectly well, that's the solution.
I never realised you do a getval without the hostname.
Interesting, I do not see this behavior and was thinking about contributing it maybe… A patch might be already available somewhere. On what system do you experience this?
rpm -q collectd collectd-5.8.1-1.el7.cern8.x86_64
Don't think we have any patches in this area.
We do have:
FQDNLookup true
I wonder if your $(hostname) is not equaul to $(hostname -f) ?