1
0
mirror of https://github.com/prometheus/node_exporter.git synced 2026-10-23 08:09:06 +03:00
Files
Sai Pisey 2354590e19 fix(collector): keep collecting temperatures without CPU power status (#3767)
* fix(collector): keep collecting temperatures without CPU power status

Apple Silicon does not implement IOPMCopyCPUPowerStatus, so
fetchCPUPowerStatus returns kIOReturnNotFound there. Update returned that
error straight away, which aborted the collector before updateTemperatures
ran, so no temperature metrics were collected at all. The error was also
not ErrNoData, so it was logged at error level on every scrape.

On an M5 Pro, Update emitted 0 metrics and failed, while updateTemperatures
on its own returned 52 temperature metrics.

Treat kIOReturnNotFound as a system that does not report CPU power status:
skip the three CPU power metrics, log at debug level and carry on to the
temperature sensors. Any other non-success return code is still returned as
an error. Systems that do report CPU power status are unaffected.

This does not make the CPU power metrics available on Apple Silicon, since
the underlying API provides no data. It only stops their absence from
suppressing the temperature metrics.

Adds a regression test covering the case.

Signed-off-by: SaiPisey2 <piseysai0202@gmail.com>

* fix(collector): disambiguate colliding thermal sensor names

Collecting temperatures on Apple Silicon surfaced a second problem that
was previously unreachable, because Update returned before
updateTemperatures ever ran.

A sensor is labelled with its IOHID "Product" property, which is not
unique. On an M5 Pro, 52 temperature-reporting services carry only 17
distinct product names, so the registry rejects the colliding samples and
logs an error on every scrape.

The collisions are of two kinds. Six "gas gauge battery" services are
distinct sensors that merely share a name; they have distinct
LocationIDs. The "PMU tdie*" services come in threes that share both the
name and the LocationID, and report readings that differ by a few tenths
of a degree, so they are separate sensing elements rather than the same
one listed repeatedly. Dropping either kind loses readings.

Following the approach taken for hwmon in #3646, read all sensors first,
then qualify a name shared by several services with its location, falling
back to the service registry ID when the location does not separate them
either. Registry IDs are unique per service, which the OS guarantees and
which held for every service observed here. Names that do not collide are
left untouched.

The endpoint now reports all 52 readings with unique label sets and no
gather errors, where before the change 35 of them were rejected.

Also update collector/fixtures/e2e-output-darwin.txt for
node_scrape_collector_success{collector="thermal"}, which is now 1
because the collector no longer fails.

resolveSensorNames is kept free of cgo so that the labelling rules are
covered by table-driven tests, which matters because the CI runner
reports no thermal sensors at all.

Signed-off-by: SaiPisey2 <piseysai0202@gmail.com>

* test(collector): satisfy the stricter linters in the thermal test

Drop a no-op drain of an already closed channel and build the metric key
with a strings.Builder.

Signed-off-by: SaiPisey2 <piseysai0202@gmail.com>

---------

Signed-off-by: SaiPisey2 <piseysai0202@gmail.com>
2026-10-21 21:32:57 +02:00
..
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-03-13 15:02:59 +01:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-07-12 23:06:31 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2017-01-05 06:18:34 +01:00
2017-01-05 06:18:34 +01:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2022-07-27 20:59:39 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-08-05 13:10:30 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2024-09-11 10:51:28 +02:00
2026-10-07 10:29:59 +02:00
2023-03-07 15:18:38 +01:00
2023-03-07 15:18:38 +01:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-10-20 10:39:09 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2025-10-22 14:55:47 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-07-12 23:06:31 +02:00
2026-07-12 23:06:31 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00
2026-10-07 10:29:59 +02:00