Parse smonctl output instead of directly using hwmon subsystem

[loulecrivain]

Hello,

Another feature idea that'd greatly simplify our deployment steps IMO.

https://github.com/tynany/cumulus_exporter directly uses smonctl output (see their sensor.go). I think we should/could do that part in Go instead of having to handle hwmon configuration files manually afterwards.

I don't know if we have a specific reason as for why we do it this way, so if anyone wants to veto or suggest something else, feel free.

[Kek5chen]

we could keep the config files still and use smonctl as a fallback / default when no file is given. i think that's actually a really good idea for people that just want to get the metrics without setting up a device specific file

[loulecrivain]

yes, but also we're building hwmon.yml files from smonctl output.

smonctl -jv output format has changed slightly between Cumulus Linux releases, but IMO nothing important from what I've seen. should be easy to make something generic enough to get what we need.

another example:
https://github.com/exoscale/collectd-cumulus/blob/master/cumulus.py

[loulecrivain]

I've checked it and the fields state, type and input are always there whatever smonctl's version is. This is the minimal we need.

[loulecrivain]

supplementary argument for this: hwmon enumeration order in /sys is not persistent. so, we're at risk of messing up (already happened on lab's SN2700 after a re-provisioning, I no longer have PSU power states)

[Kek5chen]

yes, but also we're building hwmon.yml files from smonctl output.

that's correct, but we do not know how others might want to use this application. i don't know if it makes sense to completely remove the configuration file option, since maybe hwmon data is pulled from places that aren't available in smonctl. i can imagine at least one cursed setup that that'd cover.

it generally allows for different types of usage than what's "standard" and i don't see much harm in keeping it since it's already there. i'd probably work it this way: you can opt out of the new "default" smonctl parsing behavior but also optionally supply a hwmon configuration file as standalone or even in conjunction with the parsing. that would just add onto what we already have and also would give the greatest flexibility and ease of use.

so that when you do -collectors.hwmon to just get smonctl parsing, -collectors.hwmon -collectors.hwmon.config /.../.../hwmon.yml to get smonctl and a config and something like -collectors.hwmon -collectors.hwmon.nodynamic -collectors.hwmon.config /.../.../hwmon.yml to get smonctl and a static config and -collectors.hwmon -collectors.hwmon.nodynamic being invalid since there's no paths the hwmon collector has been supplied with.

the fact that the driver paths are not persistent is a good point as well. i saw this on the leaf extender in the lab before but disregarded it as just the hwmon being incompatible with the lab.

[loulecrivain]

well then we can keep the hwmon.yml file option as initially planned, agree that it'd be useful as a last resort. Thank you for your input 😎