hwmon: disambiguate colliding chip labels

[mwimpelberg28]

Summary

Fixes #3637.

Multiple hwmon nodes can be registered under a single parent device — for example, asus-nb-wmi on recent ASUS laptops registers one hwmon for fan control and another for WMI sensors. Both device symlinks resolve to the same /sys/devices/platform/asus-nb-wmi, so hwmonName produces the same platform_asus_nb_wmi chip label for both, and any sensor file that exists in both nodes (e.g. pwm1_enable) trips:

collected metric "node_hwmon_pwm_enable" { ... chip="platform_asus_nb_wmi" ... } was collected before with the same name and label values

Approach

Update now does two passes:

• Pass 1: enumerate /sys/class/hwmon/*, compute the device-derived base chip name for each, and count collisions.
• Pass 2: when a base name is shared, suffix the chip label with the chip's name file content if it disambiguates, otherwise with the hwmonX basename (always unique within a boot). The include/exclude filter is also moved here so user regexes match the label that is actually emitted in the metric.

Entries that already produce a unique chip label are unaffected — no surprise suffixes for users not hitting the collision.

This is closer in spirit to the discussion in #333 (the same class of bug for dual-socket coretemp boxes), but contained: the fix only kicks in when an actual collision is detected.

Test plan

New collector/hwmon_linux_test.go:

• TestHwmonDuplicateChipNamesAreDisambiguated — reproduces the Metric node_hwmon_pwm_enable was collected before with the same name and label values #3637 ASUS WMI scenario (two hwmon dirs sharing one platform device, both exposing pwm1_enable) and asserts both Gather succeeds and the chip labels are distinct.
• TestHwmonUniqueChipNamesAreUnchanged — guards against unintended label drift for users not hitting the collision.
• TestHwmonDuplicateChipNamesWithSameNameFile — exercises the hwmonX-basename fallback when the name file content also collides.
• Full collector test suite still passes (go test ./collector/), including the existing fixture-driven e2e checks.
• go vet ./... clean.

[mwimpelberg28]

@SuperQ would you have a moment to take a look? Happy to address any feedback.

[SuperQ]

This should add to the test fixtures so that it's tested in the end-to-end test.

[mwimpelberg28]

This should add to the test fixtures so that it's tested in the end-to-end test.

This should be fixed. @SuperQ can you please review?

[champtar]

Just opened issue #3673 and found this PR

Why not just always have chip and chip_name labels ?

[mwimpelberg28]

Why not just always have chip and chip_name labels?

Thanks for the pointer to #3673 — this PR actually does fix that case. In your mt7996 example all three hwmon* nodes resolve to the same device (ieee80211/phy0), so they collide on the chip label today. With this PR the collision is detected and each one gets a unique chip (suffixed with the distinct name content, e.g. ieee80211_phy0_mt7996_phy0_0/_1/_2), so the was collected before with the same name and label values error goes away.

I'd lean away from always emitting chip_name as a label on every metric for two reasons:

1. It's a breaking change for everyone. Adding chip_name to every hwmon series changes the label set on all existing time series, which breaks existing queries, recording rules, and dashboards even for users who never hit a collision. This PR is deliberately conservative — labels only change for nodes that actually collide.
2. It wouldn't fully solve it anyway. Two hwmon nodes under the same parent can also share identical name content (covered here by TestHwmonDuplicateChipNamesWithSameNameFile), so chip+chip_name still isn't guaranteed unique — you'd need the hwmonX fallback regardless.

The node_hwmon_chip_names info-metric is also the idiomatic Prometheus join pattern (like node_uname_info) for attaching human-readable names without bloating every series, so I'd prefer to keep it.

Happy to add an e2e fixture mirroring the mt7996 layout if it'd help demonstrate the #3673 fix concretely.

[nicolastakashi]

@mwimpelberg28 overall LGTM, can you just fix DCO?

[mwimpelberg28]

@nicolastakashi thanks! DCO is fixed now — added the missing Signed-off-by to the two commits that were lacking it. The check is passing. 🟢

[mwimpelberg28]

@SuperQ could you please have a look?

[SuperQ]

Thanks!