SNMP PDU OIDs: Per-Outlet Current, Power & Energy

By the SNMP Monitoring team · Reviewed July 2026

An intelligent PDU is a goldmine of power telemetry — phase current, per-outlet draw, cumulative energy, even remote outlet switching — but almost all of it lives in vendor MIBs, not a single standard table. This page is the paste-ready reference for where PDU data actually is: the APC, Raritan and ServerTech enterprise trees, plus the one standard model (IETF ENERGY-OBJECT-MIB) some PDUs implement. If you're hunting a "per-outlet power OID," the honest answer is "it depends on the brand" — and this page tells you where to look for each.

Related electrical references: power OIDs and UPS OIDs. Hubs: sensors, all OIDs.

What a PDU exposes

A rack PDU with metering typically reports, at several granularities:

• Inlet / phase current — amps per phase or per bank; the coarse "how loaded is this PDU" number.
• Per-outlet current and power — amps and watts for each individual outlet (on outlet-metered models).
• Energy — cumulative kWh, per PDU and sometimes per outlet, for billing and capacity work.
• Outlet state — on/off status, and on switched PDUs the ability to change it.
• Environmental — temperature/humidity from probes on PDUs that accept them.

The granularity you get depends on the model: an inlet-metered PDU gives you phase totals only, while an outlet-metered-and-switched unit gives you everything down to a single socket.

That granularity distinction is worth understanding before you buy or before you build a dashboard, because it decides what questions you can even ask. There are broadly three tiers of intelligent PDU. A monitored (inlet-metered) PDU reports total or per-phase load — enough to know a circuit's headroom, but not which device is drawing what. An outlet-metered PDU adds per-outlet current and power, so you can attribute consumption to individual gear and spot the one server pulling twice its neighbours. A switched PDU adds remote on/off control per outlet on top of that. The OIDs available scale with the tier: asking an inlet-metered PDU for per-outlet watts returns nothing, not because you have the wrong OID but because the hardware doesn't measure it. So the first step on any PDU is to walk its tree and see what it actually populates — the metering tier, not the brand, sets the ceiling on what you can monitor.

Vendor MIBs

Because there's no universal per-outlet standard, the objects live under each vendor's enterprise arc 1.3.6.1.4.1:

APC's rPDU2 objects under PowerNet (…318) are the ones you'll meet most in enterprise racks. The exact per-outlet leaf differs by vendor and even by MIB revision (rPDU vs rPDU2), so this reference points you at the tree rather than inventing a leaf — load the vendor MIB and walk it. Platform notes live under devices.

Standard fallback: ENERGY-OBJECT-MIB

There is a standards-track model: the IETF ENERGY-OBJECT-MIB (RFC 6933) at 1.3.6.1.2.1.229, which defines a generic energy/power object framework — an "energy object" with power, usage and (optionally) accounting. Some newer PDUs implement it, giving you a portable way to read power and energy without a vendor MIB. Coverage is inconsistent, though: many PDUs still expose far more through their own MIB than through ENERGY-OBJECT, so treat it as a useful portable baseline where present rather than a replacement for the vendor tree. Walk 1.3.6.1.2.1.229 to see whether your PDU answers it.

Worked snmpwalk example

Walk the PDU's vendor subtree (the arc and leaves shown are illustrative of the pattern — read your MIB):

snmpwalk -v2c -c <RO_string> <pdu> 1.3.6.1.4.1.318

enterprises.apc.rPDU2.outlet.metered.current.1 = INTEGER: 12
enterprises.apc.rPDU2.outlet.metered.power.1   = INTEGER: 288
enterprises.apc.rPDU2.phase.current.1          = INTEGER: 84

Read against the MIB, that's outlet 1 pulling ~1.2 A (many PDUs report tenths) and 288 W, with phase 1 at 8.4 A. Confirm the scale in the vendor MIB — like most sensors, PDUs often report current in tenths. <RO_string> is a placeholder; keep live communities out of committed scripts.

Use cases

What the telemetry is for:

1. Capacity planning — sum outlet/phase load to know how much headroom a circuit has before you add gear. Phase balancing on three-phase PDUs falls out of the same data.
2. Energy / billing — cumulative kWh per PDU or outlet feeds colocation billing and efficiency reporting.
3. Outlet control — switched PDUs let you power-cycle a hung device remotely via SNMP SetRequest.

That last one carries a warning: outlet switching is a write operation, so it needs a read-write community or SNMPv3 with write access, and a stray Set can power off the wrong outlet. Treat write access to a PDU with real care — ideally SNMPv3, tightly scoped, and never the same public/private defaults left in place.

Related

PDU data sits alongside the other electrical references: generic board-level volts/amps/watts are on power OIDs, and UPS input/output is on UPS OIDs. For deployment specifics see devices. The full index: all sensors; definitions: glossary.

Frequently asked questions

Can SNMP monitor a PDU?

Yes — intelligent/metered PDUs expose rich power telemetry over SNMP, almost all of it through vendor MIBs under 1.3.6.1.4.1 (APC PowerNet rPDU2, Raritan, ServerTech Sentry). You poll phase current, per-outlet current and power, cumulative energy, and outlet state, depending on the model's metering level.

What OID is per-outlet power?

It's vendor-specific — there's no single standard per-outlet power OID. On APC it lives in the PowerNet rPDU2 tree under 1.3.6.1.4.1.318; Raritan and ServerTech have their own. Load the vendor MIB, walk the outlet subtree, and confirm the scale (often tenths) before trusting a value.

Is there a standard PDU MIB?

Partly. The IETF ENERGY-OBJECT-MIB (RFC 6933, 1.3.6.1.2.1.229) defines a portable energy/power object model that some PDUs implement, giving standard power and energy readings. But most PDUs expose far more through their vendor MIB, so ENERGY-OBJECT is a baseline where present, not a full replacement.

Can I switch outlets via SNMP?

On switched PDUs, yes — via an SNMP SetRequest to the outlet-control object, which requires write access (a read-write community or SNMPv3 with write privileges). Because a wrong Set can cut power to the wrong device, scope write access tightly and prefer SNMPv3 over community-string writes.

Key takeaways

• PDU telemetry is mostly vendor MIBs under 1.3.6.1.4.1 — APC PowerNet rPDU2 (…318), Raritan, ServerTech.
• Granularity depends on the model: inlet/phase totals vs full per-outlet current, power and energy.
• The ENERGY-OBJECT-MIB (RFC 6933, 1.3.6.1.2.1.229) is a partial standard some PDUs implement.
• Outlet switching = SetRequest — needs write access; scope it tightly, prefer SNMPv3.
• Per-outlet leaves are vendor-specific and scale is often tenths — read the MIB, don't invent.
• Related: power OIDs, UPS OIDs; catalog: sensors/all.