Triage a health warning

A box shows Warning. Here’s the ladder from “something’s wrong” to “DIMM B4 is throwing correctable errors,” in three tool calls.

1. Which subsystem?

“What’s the health breakdown on r740-lab?”

idrac_health returns per-subsystem status — system, processors, memory, storage per controller, chassis, and the iDRAC itself. If one subsystem’s Redfish resource is broken, the report degrades to partial rather than failing outright (the error appears under errors).

2. What happened?

“Show me the last 50 hardware events on r740-lab.”

The SEL (idrac_sel) is the hardware event log: ECC errors, PSU failures, thermal trips, intrusion. Entries are newest-first with severity. This almost always names the component behind the Warning.

For the audit trail instead — who changed what, config jobs, firmware updates — use idrac_lclog (the Lifecycle log). It’s the noisier of the two.

3. Which exact part?

“Show me the memory inventory on r740-lab with health per DIMM.”

idrac_inventory carries per-component health: each DIMM slot, each drive (with wear percentage for SSDs), each PSU. Cross-reference the SEL entry with the component and you have a part to replace and a slot to find it in.

4. Find it in the rack

“Blink the locator LED on r740-lab.”

Then take the service tag from idrac_info to Dell support — it’s the SKU field in Redfish, and it’s what warranty lookups want.

Fleet-wide sweeps

The health_check MCP prompt packages this whole ladder across every registered iDRAC into a one-screen table: reachability, power, temperature, draw, and SEL status per box. Sensors note: inlet temperature is the number facility people care about; consumed watts vs. idle tells you whether a box is actually working.

After the fix

Once the component is replaced and healthy, consider clearing the SEL (idrac_sel_clear) so future alerts stand out — but capture idrac_sel output first. The clear itself is recorded in the Lifecycle log, so the action stays auditable.