With --native-ipmi, the BMC watchdog collector takes the initial and present countdown values from the Get Watchdog Timer response and publishes them as they are on metrics named *_seconds. The response holds those two values in 100ms units (IPMI v2.0 section 27.7, bytes 4-5 and 6-7), so both metrics come out 10 times too large. The pre-timeout interval in byte 2 really is in seconds, and it is fine.
Same BMC, same moment:
ipmi_bmc_watchdog_current_countdown_seconds (--native-ipmi) : 521
ipmitool ... mc watchdog get : Present Countdown: 51.5 sec
initial_countdown_seconds shows 600 on a BMC where the configured timeout is 60 seconds.
master still does this, at collector_bmc_watchdog_native.go lines 133-134:
ch <- prometheus.MustNewConstMetric(bmcWatchdogNativeInitialCountdownDesc, prometheus.GaugeValue, float64(res.InitialCountdown))
ch <- prometheus.MustNewConstMetric(bmcWatchdogNativeCurrentCountdownDesc, prometheus.GaugeValue, float64(res.PresentCountdown))
go-ipmi decodes the bytes correctly, and its field names even record the difference: PreTimeoutIntervalSec has the Sec suffix, InitialCountdown and PresentCountdown do not. Its own Format() prints the raw counts with a sec suffix though, which is probably where this came from. Upgrading the dependency will not help, because v0.9.0 still has the unconverted fields and the same formatter. I will report that part to go-ipmi separately.
The values are wrong but plausible, which is what makes it worth fixing. An alert on ipmi_bmc_watchdog_current_countdown_seconds < 30 never fires, because a healthy 50 second countdown reads as 500.
Environment: ipmi_exporter 1.10.1, rechecked against master; go-ipmi v0.8.3, as pinned in go.mod; Supermicro X9SRL-F, BMC firmware 3.64, IPMI 2.0 over LAN (RMCP+), scraped remotely with an account at USER privilege. The units come from the spec, so this is not specific to one vendor.
I have a fix ready with a table test over a synthetic response, and can send it as a PR.
With
--native-ipmi, the BMC watchdog collector takes the initial and present countdown values from the Get Watchdog Timer response and publishes them as they are on metrics named*_seconds. The response holds those two values in 100ms units (IPMI v2.0 section 27.7, bytes 4-5 and 6-7), so both metrics come out 10 times too large. The pre-timeout interval in byte 2 really is in seconds, and it is fine.Same BMC, same moment:
initial_countdown_secondsshows 600 on a BMC where the configured timeout is 60 seconds.masterstill does this, atcollector_bmc_watchdog_native.golines 133-134:go-ipmi decodes the bytes correctly, and its field names even record the difference:
PreTimeoutIntervalSechas theSecsuffix,InitialCountdownandPresentCountdowndo not. Its ownFormat()prints the raw counts with asecsuffix though, which is probably where this came from. Upgrading the dependency will not help, because v0.9.0 still has the unconverted fields and the same formatter. I will report that part to go-ipmi separately.The values are wrong but plausible, which is what makes it worth fixing. An alert on
ipmi_bmc_watchdog_current_countdown_seconds < 30never fires, because a healthy 50 second countdown reads as 500.Environment: ipmi_exporter 1.10.1, rechecked against
master; go-ipmi v0.8.3, as pinned ingo.mod; Supermicro X9SRL-F, BMC firmware 3.64, IPMI 2.0 over LAN (RMCP+), scraped remotely with an account at USER privilege. The units come from the spec, so this is not specific to one vendor.I have a fix ready with a table test over a synthetic response, and can send it as a PR.