Redundant server power supply status monitoring should report more than whether two modules are visible. A useful monitoring design separates individual PSU condition from the server’s aggregate redundancy state, then maps each state transition to an alert, an operator action, and evidence for recovery. The exact sensor names, SNMP objects, IPMI records, Redfish resources, and vendor-console labels remain platform-specific. The engineering task is to normalize those different interfaces without implying that one universal command or OID applies to every server.
The practical outcome is an alarm-to-action matrix. It should tell an operator whether a PSU is present, receiving input, delivering output, reporting a health fault, and participating in the configured redundancy policy. It should also identify when management data is stale or contradictory. “Two PSUs present” is an inventory observation; “redundancy restored” is an operational conclusion that requires stronger evidence.
Quick answer: monitor module state and protection state separately
Collect telemetry for each PSU and for the server-level power policy through the platform’s supported management interfaces. Normalize module presence, input availability, output or health status, redundancy availability, and data freshness into explicit states such as healthy protected, degraded but running, unprotected or uncertain, failed, restored pending, and unknown. Use polling to establish current state and event notifications to shorten detection time, but reconcile both rather than accepting either source blindly. Escalate a lost PSU according to its service consequence, and do not clear the incident as recovered until the host reports a complete supported configuration with current, consistent telemetry.
The monitoring result is a service state, not a green LED
A server may continue operating after one PSU loses its input or output. That continuity can be useful, but it does not mean the original resilience promise remains available. Conversely, a front-panel LED may look normal while the management controller reports a warning, a missing input, a failed fan, or an inactive redundancy policy. Monitoring therefore needs two levels of identity.
- Module state: what each PSU is doing individually, including presence, input condition, output contribution or readiness, health indication, temperature or fan warning when exposed, and communication freshness.
- Aggregate state: what the server can currently claim about power continuity, including whether the configured policy is active, whether the remaining capacity is adequate, and whether a supported failure boundary is still covered.
These levels produce more useful operational language. A module can be absent while the server is still running in a degraded state. A module can be present but not accepted by the host. Both modules can report healthy while the aggregate redundancy policy is unavailable because of a shared distribution or management condition. The dashboard should preserve those distinctions instead of compressing them into “PSU OK” or “PSU failed.”
| Normalized state | Meaning | Typical operator response |
|---|---|---|
| Healthy protected | Required modules, inputs, health signals, policy state, and telemetry freshness agree. | Continue normal operation and retain the baseline. |
| Degraded but running | A module or source is unavailable, but the platform reports continued operation under a reduced protection state. | Open a service incident, assess urgency, and protect remaining capacity. |
| Unprotected or uncertain | The server is powered, but active redundancy or surviving-capacity evidence is missing or contradictory. | Escalate as a resilience risk even if no immediate shutdown is reported. |
| Failed | The affected PSU or power path is not providing its required function, or the host reports a power-impacting fault. | Follow the platform’s fault procedure and preserve event evidence. |
| Restored pending | A replacement or recovered input is visible, but the complete supported operating state is not yet confirmed. | Keep the incident open while recognition, health, policy, and freshness settle. |
| Unknown | Telemetry is stale, unavailable, inconsistent, or not authoritative for the question being asked. | Escalate the monitoring-data problem separately from a confirmed PSU failure. |
The word “protected” should be used only when the platform’s documented operating mode and the deployed load assumptions support it. A pair of installed modules does not by itself prove 1+1 operation, independent upstream feeds, or adequate surviving output. Powernexu’s discussion of what two server PSUs actually protect provides the architectural context; the monitoring layer should expose the resulting state rather than recreate that architecture analysis in every alarm.
Build a telemetry inventory around platform authority
Before writing alert rules, list where each required fact comes from and how much authority it has. A server may expose data through a baseboard management controller, a web console, IPMI, Redfish, SNMP, a vendor management suite, or a combination of these. Those interfaces are not interchangeable merely because they appear to describe the same PSU.
| Required observation | What to record | Why the distinction matters |
|---|---|---|
| Module identity and presence | Bay or slot identity, model information when exposed, present or absent state, and last update time. | Prevents an absent module, an unrecognized replacement, and a communication failure from sharing one alarm. |
| Input condition | Input available, lost, abnormal, or not reported, including the relevant source or inlet identity when the platform exposes it. | Separates a converter fault from a rack-feed or cord event without claiming more scope than the sensor supports. |
| Output and health | Output-ready or contributing state, fault or warning state, and any platform-defined thermal or fan indication. | A PSU can be physically present but unable to deliver its intended function. |
| Aggregate redundancy | Active policy, available or degraded status, and any host-level power-budget indication. | This is the closest signal to the server’s service consequence, but it remains platform-specific. |
| Management freshness | Polling time, event time, controller reachability, sequence information, and age of the last valid value. | A missing update is not evidence that the hardware itself failed. |
For every field, record the platform, firmware baseline, interface, object or sensor identifier, expected value vocabulary, and interpretation owner. Do not publish a guessed universal OID or assume that a label such as “power supply 2” has the same meaning across server families. Cisco’s documented SNMP examples show that power-supply failure and redundant-supply state changes can be monitored where the supported platform exposes the applicable mechanisms, but the implementation still belongs to the equipment documentation. Use the Cisco SNMP power-supply monitoring guidance as an authoritative example of that platform-dependent approach, not as a universal server PSU map.
Turn events into an alarm-to-action matrix
An event notification is a fast indication that something changed; it is not necessarily the final state. Polling supplies a current observation but may miss a short transition or arrive after an operator has already responded. A robust rule uses both paths: accept an event as a reason to investigate immediately, then reconcile it with a fresh platform-authoritative poll and the aggregate status.
| Observed transition | Normalized interpretation | Alert and action |
|---|---|---|
| One PSU changes from present/healthy to absent or faulted while the host remains online. | Degraded but running, subject to the aggregate policy and capacity state. | Raise a service-impacting warning or incident; identify the affected bay and preserve the last healthy record. |
| One PSU loses input while module health remains otherwise normal. | Source or inlet condition is degraded; module failure is not yet proven. | Alert the power-path owner and correlate with rack or upstream observations. |
| Aggregate redundancy changes to unavailable or degraded. | Protection is not currently established, even if both modules are visible. | Raise severity according to workload and surviving-capacity risk; do not label the condition healthy. |
| Management interface stops updating while local hardware indicators remain unchanged. | Unknown management state. | Open a telemetry fault and avoid automatically declaring either failure or recovery. |
| Repeated module or redundancy transitions occur in a short operating interval. | Intermittent, unstable, or oscillating condition. | Correlate timestamps, input events, load changes, and controller logs before replacing hardware. |
| Replacement becomes visible and module health returns to normal. | Restored pending. | Keep the incident open until aggregate policy, module identity, input condition, and data freshness agree. |
Severity should follow consequence rather than the name of the sensor. A single lost PSU may be a high-priority maintenance event when the surviving path has limited margin or when the workload cannot tolerate another loss. The same module event may require faster escalation if the aggregate state is unknown, if both inputs share an uncertain upstream source, or if the platform reports that the remaining power budget is insufficient. Monitoring should not invent a capacity conclusion from a generic “redundant” label; it should ingest the host’s supported policy and the operating information available for that configuration.
Handle stale, conflicting, and out-of-order data explicitly
Treat freshness and authority as part of every status value. For each transition, retain the server and bay identity, source interface, raw vendor value, normalized state, event time, collector receipt time, latest poll time, and aggregate platform status. A missing update indicates telemetry uncertainty; it does not by itself prove hardware failure.
Define staleness from normal platform behavior and the monitoring service objective. When an event and poll disagree, preserve both, compare trustworthy timestamps, query the documented platform-authoritative source, and retain an unknown or unresolved state until consistent evidence supports escalation or clearance. A delayed trap, BMC restart, or newly detected replacement must not let stale healthy data suppress a fault—or let one missing sample create a PSU-failure alarm.
Restoration requires more than seeing the replacement
Recovery is a state transition with multiple conditions. A newly inserted or replaced module may be mechanically seated and visible to the BMC while still being unrecognized, unsuitable for the host revision, outside the expected input state, or excluded from the active redundancy policy. Likewise, clearing an alarm can remove an event record without proving that the system has returned to its original protection state.
A practical restoration rule should require evidence for all applicable conditions:
- The expected PSU population is present, and the affected bay identifies the intended module or an approved identity.
- The replacement reports normal input and output or health status through the platform-supported interface.
- The aggregate server state reports the intended redundancy policy as available, not merely that two modules are installed.
- Telemetry is current and consistent across the required management observations.
- No unresolved source, PDB, host, thermal, or communication alarm contradicts the restored state.
The exact evidence depends on the server platform. Some systems expose a clear aggregate redundancy flag; others provide separate power-budget, PSU, and fault records that operations must interpret together. If the host does not expose enough information to establish restoration, the correct normalized state is “restored pending” or “unknown,” not healthy by assumption.
This boundary also prevents monitoring from taking over fault isolation. Once the alarm establishes that the server is degraded or that telemetry is contradictory, the next diagnostic question may concern the module, bay, PDB, rack feed, or upstream source. Powernexu’s server power-supply fault-isolation framework addresses that wider boundary. The monitoring article’s job is to preserve the evidence and route the incident with an accurate scope.
Design the handoff so operations can act on history
Keep a timestamped baseline for server and bay identity, expected PSU population, configured redundancy policy, management source, and input grouping when available. Each alert should show the raw observation, normalized state, first and latest observation times, aggregate redundancy state, data age, and next action. Avoid asserting an unverified cause: “Bay 2 input unavailable; server online; redundancy degraded; correlate the assigned rack source” is more useful than “PSU 2 failed.”
After recovery, retain the transition sequence, replacement identity, final aggregate state, and unresolved limits. Rebaseline after firmware, PSU, PDB, feed-assignment, or workload changes. Monitoring is complete when module health, aggregate protection, freshness, and restoration evidence remain separate—and a cleared alert cannot be mistaken for proof that redundancy returned.
