fix(collector): keep collecting temperatures without CPU power status

[SaiPisey2]

Addresses #2906.

Apple Silicon does not implement IOPMCopyCPUPowerStatus, so fetchCPUPowerStatus gets back kIOReturnNotFound. Update returned that error straight away, which meant it never reached updateTemperatures, so no temperature metrics were collected at all. The error also isn't ErrNoData, so it was logged at error level on every scrape.

Measured on an M5 Pro (darwin/arm64) against master:

fetchCPUPowerStatus()      -> status=map[] err=no CPU power status has been recorded
Update()                   -> err=no CPU power status has been recorded ; metrics emitted=0
IsNoDataError(err)         -> false
updateTemperatures() alone -> err=<nil> ; temperature metrics available=52

52 usable temperature sensors on that machine, none of them exported, because an expected and unrelated condition aborted the collector.

Change

Treat kIOReturnNotFound as "this system does not report CPU power status" rather than a failure: skip the three CPU power metrics, log at debug level, and continue on to the temperature sensors. Any other non-success return code is still returned as an error, exactly as before, so systems that do report CPU power status are unaffected.

After the change, on the same machine, Update() returns no error and emits all 52 temperature metrics.

Scope

This does not make the CPU power metrics appear on Apple Silicon and does not resolve #2218 — the underlying API provides no data there, as @rexagod already established on #2906. It only stops their absence from suppressing the temperature metrics. I've left Closes #2906 out of the commit deliberately, since whether that issue is fully answered by this is a maintainer call.

Testing

Added collector/thermal_darwin_test.go, which fails on master:

--- FAIL: TestThermalUpdateWithoutCPUPowerStatus
    thermal_darwin_test.go:44: Update returned errNoCPUPowerStatus; a system
    without CPU power status must still collect temperatures

and passes with the change. Also verified locally:

• go build ./...
• go vet ./collector/
• gofmt -l clean on both touched files
• go test ./collector/ full package
• go build -tags notherm ./collector/

[nicolastakashi]

/workflow-approve

[nicolastakashi]

The Darwin/macOS e2e job is failing on a fixture mismatch, node_scrape_collector_success{collector="thermal"} changed from 0 to 1. Can you regenerate the golden output on a Darwin/arm64 box and push it?

./end-to-end-test.sh -u

Then commit the updated collector/fixtures/e2e-output-darwin.txt.

[SaiPisey2]

Thanks for the review. Pushed, but regenerating the fixture turned up two things worth flagging rather than just committing the output.

The fixture change itself

I did not commit a regenerated file. Running ./end-to-end-test.sh -u on real hardware produced a 469-line diff, because this machine reports actual sensors while the CI runner reports none, and the values are live temperatures. So the fixture now carries only the single line the CI diff asked for:

-node_scrape_collector_success{collector="thermal"} 0
+node_scrape_collector_success{collector="thermal"} 1

./end-to-end-test.sh -u overwrites the Linux fixture on macOS

Worth knowing before anyone else follows the same instruction. The Darwin fixture path is built with ${fixture_metrics::-4}, and a negative substring length needs bash 4.2. macOS still ships bash 3.2, where that expansion fails, fixture_metrics keeps pointing at e2e-output.txt, and the update copies Darwin output over the Linux fixture. My first run rewrote 5330 lines of collector/fixtures/e2e-output.txt before I noticed. ${fixture_metrics%.txt} is equivalent and works on both, so I've changed it.

I also added node_thermal_temperature_celsius to non_deterministic_metrics. It is per-machine in both its sensor names and its values, so without it anyone running the suite on real hardware sees the whole sensor list as a diff. It makes no difference in CI, which reports no sensors.

(Unrelated and left alone: the sed -i /pattern/d calls in that loop need an extension argument on BSD sed, so the non-deterministic stripping aborts on stock macOS. It behaves the same on master, so it is not something this PR introduces.)

A real bug the fixture regeneration exposed

This is the part I would not have caught otherwise. Once temperatures are actually collected, the collector emits duplicate label sets:

emitted=52  uniqueSensorNames=17  duplicateSeries=35

and the scrape logs 35 error(s) occurred: ... was collected before with the same name and label values every time, with those samples dropped.

A sensor is identified only by its IOHID Product name, and several services report the same one. Probing the services directly, 76 temperature-capable services carry just 25 distinct Product values, and there is nothing to tell them apart: RegistryID, UniqueID, SerialNumber and Manufacturer are all unset, VendorID/ProductID/PrimaryUsage are constant across every service, and two services can share both Product and LocationID (PMU tdie2 at 1414541922 appears twice). There are also genuinely distinct sensors sharing a name — two gas gauge battery services with different LocationIDs.

Since there is no property that makes them addressable, I report the first reading per name and count the rest in a debug line. The endpoint now returns 200 with 17 unique series and no gather errors. TestThermalTemperaturesAreUnique covers it and fails without the change.

CI never sees this, since the runner has no sensors, but every Apple Silicon machine would have.

Verified locally: go build ./..., go vet ./collector/, gofmt clean, go test ./collector/ including 20 repeats of the thermal tests, and a -tags notherm build.

Happy to split the two end-to-end-test.sh changes into their own PR if you would rather keep this one to the collector.

[nicolastakashi]

Thanks for the fixes. Let's split the end-to-end-test.sh changes into a separate PR.

On the duplicate sensors: dropping readings loses data. #3646 hit the same colliding-label problem for hwmon and fixed it by disambiguating the label instead (suffix it, falling back to something always unique when the first suffix still collides). Take a look there for the approach.