A data centre team needs to monitor GPU server health even when a node's operating system has hung or the host driver is unresponsive, so that they can detect thermal and power faults and power-cycle the node remotely. Which monitoring path lets them collect this information independently of the host software state?
- AQuerying DCGM through its host engine on each node, which reads live GPU counters directly from the resident driver across the cluster
- BScraping the dcgm-exporter endpoint on each node so a Prometheus server pulls GPU metrics over the cluster network for dashboards and alerts
- CReading the operating system's hardware sensor interface on each host to gather temperature and power readings through standard kernel drivers
- DOut-of-band management via the baseboard management controller using a protocol such as Redfish or IPMI, which operates independently of the host CPU and OS Correct
Why A is wrong: DCGM is the right tool for rich GPU telemetry, but it runs in the host operating system and depends on the driver, so it goes blind exactly when the host has hung.
Why B is wrong: The dcgm-exporter is a standard Prometheus integration and tempting because it centralises alerting, but it is a host-resident process feeding from the driver, so it stops responding when the OS hangs.
Why C is wrong: Kernel sensor interfaces do expose temperature and power, but they live inside the very host software that has stopped responding, so they cannot deliver telemetry during an OS hang.
Why D is correct: The baseboard management controller runs on dedicated management hardware with its own network path, so a Redfish or IPMI query reaches sensor data and power controls even when the host OS and GPU driver are down, which is exactly what remote fault detection and power-cycling require.