SNMP PDU Monitoring

The power strip in your rack is not a dumb power strip. A managed PDU counts every amp it delivers, and SNMP PDU monitoring is how you get those numbers out of it without walking to the cabinet. Pull the per-outlet current, the bank load, the input voltage, and you can spot a circuit creeping toward its breaker limit days before it trips. This page covers what a PDU actually exposes, why the reading lives in a vendor MIB instead of the standard host tables, how to hunt down the right OID, and how to watch it from outside the room.

What is PDU monitoring

A PDU — power distribution unit — is the metered bar of outlets that feeds every server, switch, and appliance in a rack. The cheap ones just pass electricity through. The managed ones have a small brain and a network port, and they measure what flows through each outlet in real time: current in amps, apparent and real power in watts, voltage, sometimes power factor and per-outlet energy totals in kilowatt-hours.

Why bother watching any of that? Because power is the constraint nobody thinks about until it bites. Every rack circuit has a rated ceiling, and load has a nasty habit of drifting up as teams add hardware without recalculating the budget. Cross the breaker's threshold and the circuit drops — not one server, the whole leg. A tripped 20-amp breaker at 2 a.m. can take a dozen machines dark at once, and the servers themselves have no idea why they lost power.

Monitor pdu snmp readings and you turn that invisible risk into a graph. You see which outlets draw the most, how close a phase is to its limit, and whether a redundant feed is actually carrying its share. It's environmental telemetry in the truest sense: the health of the box's surroundings, not the box. That's exactly why it sits in the environmental sensors family alongside UPS, temperature, and airflow rather than with CPU and memory.

Why it's not in the standard host-resources MIB

Here's where PDU monitoring parts ways with the everyday metrics. When you poll a Linux server for CPU or storage, the values come from the Host Resources MIB (RFC 2790) — a standard tree every SNMP daemon serves the same way. Amps flowing through outlet 14 of a rack PDU? That data never touches the server's operating system. The PDU is its own device, with its own SNMP agent and its own IP address, and it publishes its measurements under its own vendor-specific branch of the OID tree.

So there is no universal pduOutletCurrent OID you can point at every unit and expect an answer. This is an advanced sensor, and that's the honest framing. The standard host tables stop at what the OS can see about itself. Power distribution is a separate class of hardware speaking through the enterprise subtree — 1.3.6.1.4.1.<vendor> — where each manufacturer defines its own objects.

There is one partial exception worth knowing. Some PDUs implement the ENTITY-SENSOR-MIB (RFC 3433), a standard that models any physical sensor generically. Its value object, entPhySensorValue at 1.3.6.1.2.1.99.1.1.1.4, returns a reading for each sensor the device advertises, with companion objects describing the type, scale, and precision so you know whether you're looking at amps, volts, or watts. When a PDU supports it, that's your cross-vendor shortcut. When it doesn't, you're in the vendor MIB — which is most of the time.

Finding the right vendor OID

Locating the exact OID is a two-front job: read the docs, then verify against the hardware. Start by downloading the manufacturer's MIB file — vendors publish these, and the object names tell you what each branch measures. Load it into snmptranslate or a MIB browser so the numeric OIDs resolve to readable names like an outlet-current column.

Then confirm empirically. Point a walk at the PDU and see what actually answers:

snmpwalk -v2c -c public 10.0.0.40 1.3.6.1.4.1

That sweeps the entire enterprise subtree and dumps every object the unit exposes. Grep the output for the amps and watts you recognise, note the OID, and you've found your column. The table below lists the vendor MIB families you're most likely to meet — treat the last column as the rule, since the precise numeric OID always comes from that vendor's own MIB.

Don't trust an OID you copied off a forum. Walk the device, watch the number change when you plug something in, and only then wire it into a poller.

Setting it up as a custom OID

Once you know the OID, the mechanics are the same as any other non-standard metric — you treat it as a custom sensor. The general workflow lives on the monitor any custom OID page; here's the PDU-flavoured version.

1. Confirm the PDU's SNMP agent is on. Enable SNMPv2c (or v3) in the unit's web UI, set a read-only community string, and note the port.
2. Discover the outlet or bank OID with the snmpwalk sweep above, and verify the value tracks real load.
3. Add that OID to the allowlist. If you poll through a host or proxy that filters OIDs, include the exact object in its view — the OID allowlist guide shows the view ... included line, and the full snmpd.conf reference covers the surrounding config.
4. Poll it on a schedule and store the history so you can see load trends, not just this second's snapshot.
5. Set a threshold below the breaker rating and alert on it.

Because the PDU is a separate device with its own agent, you're pointing your poller straight at the PDU's IP — no server-side daemon change required unless a middle box is filtering the OID.

Alerting

Signals worth alerting on:

• Total load creeping toward the circuit's rated capacity.
• One phase or outlet bank drawing far more than the others — a load imbalance.
• An outlet group losing power unexpectedly.
• Input voltage sagging outside the vendor's tolerance band.

Thresholds for power are refreshingly concrete: you're defending a breaker rating. A common rule of thumb is to warn at roughly 80% of a circuit's rated amperage and treat sustained readings above that as urgent, because continuous load should stay below the breaker's continuous-duty ceiling. Alert on load that holds high, not on the brief inrush when a server powers on.

But an alert only helps if it can reach you, and this is where on-site tooling has a blind spot. If the monitoring lives in the same rack — or the same building — as the PDU, a power event can silence the messenger and the message together. Watching the PDU from outside the network sidesteps that. It's the double durability principle: an independent, external checker keeps polling even when the site is in trouble. ostr.io Monitoring polls your SNMP endpoints from outside your infrastructure and fires real-time email and SMS alerts the moment a reading crosses your limit — so a circuit approaching its breaker reaches you before it flips.