Skip to content

Comments

Prefer device path based names over exported names#334

Merged
brian-brazil merged 2 commits intoprometheus:masterfrom
rtreffer:fix-hwmon-naming
Oct 28, 2016
Merged

Prefer device path based names over exported names#334
brian-brazil merged 2 commits intoprometheus:masterfrom
rtreffer:fix-hwmon-naming

Conversation

@rtreffer
Copy link
Contributor

For some sensors (like coretemp) it is possible that multiple
instances exist, thus base the name on the device path and not on
the exported name.

@brian-brazil @SuperQ this will fix #333

For some sensors (like coretemp) it is possible that multiple
instances exist, thus base the name on the device path and not on
the exported name.
@brian-brazil
Copy link
Contributor

The end-to-end test needs updating.

@grobie
Copy link
Member

grobie commented Oct 28, 2016

Can we get a test for this please. At least update the end-to-end tests and include fixtures with two sensors.

@rtreffer
Copy link
Contributor Author

Arghs, yes, tested the wrong binary. Test with 2 coretemp sensors sounds like a good idea, will update.

Explicitly have 2 coretemp instances with a symlink for the device
such that the hwmon collector must pick that name (or fail)
@rtreffer
Copy link
Contributor Author

I had to shuffle the hwmonX names a bit, coretemp.0/coretemp.1 will usually end up as hwmonX and hwmon(X+1).
But we now have 2 nearly identical coretemp folders that get sorted out in the end-to-end test.

@brian-brazil brian-brazil merged commit abe8e29 into prometheus:master Oct 28, 2016
@brian-brazil
Copy link
Contributor

Thanks!

mcdan pushed a commit to mcdan/node_exporter that referenced this pull request Nov 15, 2016
* Prefer device path based names over exported names

For some sensors (like coretemp) it is possible that multiple
instances exist, thus base the name on the device path and not on
the exported name.

* Update end-to-end test for dual socket machines

Explicitly have 2 coretemp instances with a symlink for the device
such that the hwmon collector must pick that name (or fail)
horazont added a commit to cloudandheat/node_exporter that referenced this pull request Nov 28, 2016
The chip label generation has been changed in prometheus#334 to prefer the
unique device path (e.g. the location on the PCI bus) due to prometheus#333.

Here, a new label, chipName, is introduced which, again, carries
the human-readable sensor name (e.g. coretemp). It is used in
addition to the existing labels.

This allows to mitigate the downsides of the solution to prometheus#333
(namely that the device path may not be stable across kernels and
reboots) for cases where it does not matter that multiple devices
may have the same human-readable name (e.g. aggregation or where
at most one device of a type is present).
horazont added a commit to cloudandheat/node_exporter that referenced this pull request Dec 1, 2016
The chip label generation has been changed in prometheus#334 to prefer the
unique device path (e.g. the location on the PCI bus) due to prometheus#333.

Here, a new annotation metric ``node_hwmon_chip_names`` is
introduced which allows to link the unique chip sysfs path to a
human-readable chip name which may not be unique among chip sysfs
paths (for example, dual-slot systems have multiple
chipType="coretemp" sensors).

This allows to mitigate the downsides of the solution to prometheus#333
(namely that the device path may not be stable across kernels and
reboots) for cases where it does not matter that multiple devices
may have the same human-readable name (e.g. aggregation or where
at most one device with a common chip name is present).

For cases where no human-readable name can be derived, the
annotation metric is not emitted.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

hwmon duplicate core temps

4 participants