SNMP Voltage Monitoring

Voltage is the quietest sensor on the whole box and one of the most telling. When a supply rail starts sagging or a battery-backed line drifts out of tolerance, nothing crashes right away — but the odds of a random reboot, a corrupted write, or a dead component climb sharply. SNMP voltage monitoring lets you watch those rails and input feeds remotely and catch the drift before it turns into an outage. Here's the caveat to state plainly: voltage isn't a metric your server publishes by default. There's no universal OID for it, so to monitor voltage over SNMP you'll be working with a vendor MIB or a custom OID — and that's what this page is about.

What is Voltage monitoring

Voltage monitoring means polling the electrical sensors on your hardware and, often, on the power equipment feeding it. Inside a server that usually means the motherboard's supply rails — the 3.3 V, 5 V, and 12 V lines, the CPU core voltage (VCore), memory and chipset voltages, plus a CMOS battery reading. Outside the server, PDUs and UPS units report input and output voltage for the whole rack or circuit.

Why watch it? Because every one of those rails has a tolerance band, and living outside that band is where trouble breeds. A 12 V line that sags under load hints at a struggling power supply or an overloaded circuit. A rail riding high stresses everything downstream of it. Ripple and instability — a value that won't sit still — can trigger the kind of intermittent, un-reproducible faults that eat days of debugging. On the input side, a dropping mains voltage is an early brownout signal, and a UPS reporting low battery voltage tells you how much runtime you actually have left when the grid blinks.

So the reading isn't just a number to confirm the lights are on. It's a health signal for the power chain. Monitor voltage over SNMP and you get a remote, continuous view of whether the electrical foundation under your workloads is steady — or slowly wandering somewhere it shouldn't be.

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

The MIBs everyone reaches for first — the Host Resources MIB (RFC 2790) under 1.3.6.1.2.1.25.*, MIB-II for interfaces — describe a device as a logical machine: processors, memory, storage, running software. Electrical characteristics like rail voltage are physical, analog properties of the hardware. They fall entirely outside what those standards set out to model, so walking the host-resources tree tells you nothing about volts.

The standards body did define a proper home for readings like this: the Entity Sensor MIB (RFC 3433). Its generic column entPhySensorValue at 1.3.6.1.2.1.99.1.1.1.4 can carry a voltage, with entPhySensorType distinguishing voltsDC from voltsAC. On gear that implements RFC 3433, that's the clean, portable place to poll. But implementation is patchy — a great many servers, PDUs, and UPS units never populate the entity-sensor tree and surface their electrical data through a vendor enterprise MIB instead.

Which puts voltage firmly among the advanced sensors: not gathered by default, absent from a generic scan, and tied to whatever object your particular hardware chose to use. No monitoring tool reads it for you automatically. You identify the exact object, allow it, and poll it on purpose. That's more deliberate than reading built-in metrics — but voltage is exactly the sort of slow, silent drift that rewards the effort of watching it.

Finding the right vendor OID

Everything hinges on matching your hardware to its voltage object. The vendor's MIB is the source of truth — open the file in a MIB browser or with snmptranslate, and the voltage sensors are usually named clearly (rail labels, "input voltage," and so on). No MIB handy? Discovery by walking works, though voltage takes a little care, because agents frequently report the value scaled (millivolts, or a value you divide by ten or a hundred).

A sensible discovery routine:

• Standard tree first. snmpwalk -v2c -c public <host> 1.3.6.1.2.1.99.1.1.1 — where RFC 3433 is present, voltages appear with entPhySensorType = voltsDC or voltsAC.
• Then the vendor enterprise subtree under 1.3.6.1.4.1.<vendor-number>, hunting for values that map onto known rails once you apply the scale.
• Always resolve the scale. entPhySensorScale and entPhySensorPrecision (or the vendor's equivalents) tell you whether "3300" means 3.3 V. Getting this wrong makes every alert meaningless.

These are genuine, vendor-published MIBs — but the exact numeric OID and per-rail index depend on the model, so read them as pointers and confirm against the MIB shipped for your device. Don't paste a number you haven't verified.

If the object won't reveal itself, don't invent one — a wrong OID charts a confident lie. The custom OID guide covers discovery in more detail.

Setting it up as a custom OID

Once the object is confirmed, setup is quick. The recurring gotchas are the agent not exposing the branch and a strict allowlist hiding it — plus, for voltage specifically, the scaling factor.

1. Confirm by hand. snmpget -v2c -c public <host> <your-voltage-OID> should return a value that maps to a known rail once scaled. A timeout is a reachability or community-string problem, not the OID.
2. Expose it in the agent. Adjust your snmpd.conf so the daemon serves the branch; on Linux, enable the lm-sensors extension for LM-SENSORS-MIB voltage objects to appear.
3. Allow the OID. Add a view ... included line for the exact object in your OID allowlist — a locked-down allowlist will hide the sensor until you name it.
4. Register it as a custom OID. With custom OID monitoring, add the object, label each rail, and set volts as the display unit.
5. Bake in the scale. Apply the divisor or entPhySensorScale factor in the poller so the chart reads 3.3 V rather than 3300. Check one rail against a known-good value before trusting the rest.

This is advanced configuration, sitting beside the other physical readings you'd wire the same way. The neighbours are listed in the sensor & OID catalog and the flat all sensors index.

Alerting

Voltage alerting is a tolerance-band problem, and the bands belong to the hardware — not to a number you'd guess. Each rail has a spec with acceptable upper and lower limits, and many vendor MIBs publish those thresholds, sometimes with a companion status object that flips to warning or critical on its own. Read them and alert off them. A round figure you invent will either cry wolf or miss the real event.

Some patterns deserve their own attention:

• A rail trending toward the edge of tolerance — early sign of a degrading power supply, worth a warning before it breaches.
• Ripple or instability — a value that jitters instead of holding steady often precedes intermittent, hard-to-repeat faults.
• Input/mains voltage sagging — a brownout signal; pair it with power-supply status to see the whole picture.

And this is where external polling earns its place. A power problem is precisely the scenario in which the on-box agent can't be trusted to warn you — if the rail collapses, so does the thing meant to send the alert. Polling from outside removes that dependency. It's the idea behind double durability: an independent watcher keeps reading your voltage OID even as the hardware falters. ostr.io Monitoring polls the object from outside your network and fires real-time email and SMS alerts the moment a rail leaves tolerance, so an electrical fault reaches you even when the affected box can't send anything at all.