prometheus-community
feat(collectors): Add Open-Hardware Monitor collector
Hi, this PR adds a collector for a running Open-Hardware Monitor service.
The idea of bringing this to windows_exporter spawned in #816 where the thermalzone collector was raising issues. Personally, I also tried to explore what could I collect using Windows WMI and CMI but to no success -- also being the first time exploring these Windows APIs (they are not pretty, in Go).
Since that didn't work out and someone had suggested a plan-B using Open-Hardware Monitor, that exposes its metrics via WMI, so that is what I went for with this PR.
It works perfectly well after a few weeks of usage, and I wanted to share it with the rest of the Prometheus community as well. Any feedback is appreciated.
Hey @zalgonoise
thanks for your PR.
I saw you try-hard invoke WMI on your own. That must be painfull. I recommend to take a look at the printer collector where the bultin capabilites of the exporter are used to invoke wmi.
Outside of the exporter, take a look at https://github.com/microsoft/wmi
Even Microsoft provide bindings for WMI.
thanks, @jkroepke 😄
You're right, I eventually ended up trying the WMI calls through powershell (also a first time for that, since I rarely use Windows) so I was trying to reproduce the same calls in Go, without the proper context of how to do it properly.
I will set this PR in draft while I check your references and update my branch, then publish it again for a new review 😄 thanks a lot for your insight!!
@zalgonoise I ask myself, it's its an good idea to introduce a collector for an program which does not get maintenance anymore: https://github.com/openhardwaremonitor/openhardwaremonitor
you know about https://github.com/nickbabcock/OhmGraphite ?
it's exporting to prometheus as well and makes use of librehardwaremonitor (ohm follow up)
Good to know that https://github.com/LibreHardwareMonitor/LibreHardwareMonitor is the successor.
If an exporter already exists, we may not have to develop a own one.