feat(agent): collect Windows storage temperatures

This commit is contained in:
courtmanr@gmail.com
2026-07-30 19:51:54 +01:00
parent 9e8b3ee6ff
commit 2e31e338bb
7 changed files with 483 additions and 16 deletions
@@ -1492,10 +1492,21 @@ the intentionally sparse public response.
GPU temperature, utilization, and VRAM readings. Linux may supplement
`lm-sensors` with that query or use it as a best-effort fallback when
`lm-sensors` is unavailable; Windows may use it as its supported direct-GPU
provider without implying support for CPU, motherboard, or storage
temperatures. The report must keep typed GPU readings in `sensors.gpu`
while mapping only direct `temperature.gpu` readings into existing
`sensors.temperatureCelsius` `gpu_nvidia_<index>` keys for compatibility.
provider without implying support for CPU or motherboard temperatures.
Windows physical-disk temperature is a separate best-effort native source:
`internal/hostagent/windows_storage_sensors.go` may issue one fixed,
non-interactive, five-second Windows Storage-module query for at most 128
physical disks and map only device-reported reliability temperatures from
`Get-StorageReliabilityCounter` into the existing `sensors.smart` physical
disk contract. Its JSON output, device identities, model labels, and
temperatures must be bounded and validated; absent cmdlets, missing
counters, malformed output, and unsupported devices omit that telemetry
without failing the host report. This path must not use ACPI thermal zones,
infer disk health, execute server-authored PowerShell, or imply support for
CPU or motherboard temperatures. The report must keep typed GPU readings in
`sensors.gpu` while mapping only direct `temperature.gpu` readings into
existing `sensors.temperatureCelsius` `gpu_nvidia_<index>` keys for
compatibility.
Authenticated server ingest may reduce those typed samples into bounded
host-level GPU utilization, VRAM pressure, and GPU temperature history on
the existing agent identity, but that monitoring projection does not change
@@ -1279,6 +1279,14 @@ the shared model conversion helpers must preserve `sensors.thermalState`
through ingest, read-state projection, and frontend conversion, while leaving
`agent.temperature` and `metric=temperature` unset unless a real Celsius value
exists.
Windows Storage-module reliability temperatures use the existing host-agent
physical-disk route rather than a provider-specific monitoring payload.
Authenticated ingest must preserve each validated `sensors.smart` device,
model, transport, capacity, temperature, and field-level
`windows-storage-reliability` provenance through the canonical host resource,
disk-temperature presentation, history, and alert boundaries. An unknown
health value remains unknown; monitoring must not convert the presence of a
temperature counter into SMART health evidence.
Host-agent GPU sensor summaries follow that same descriptive-host-telemetry
path. Monitoring must preserve typed GPU id, name, temperature, utilization,
and VRAM readings from agent reports through models, read-state projection, and