By the SNMP Monitoring team · Reviewed July 2026
Hardware rarely dies without warning — it gets hot, a fan slows, a PSU browns out, a RAID member drops. The warning is there; you just have to be reading the sensors. SNMP exposes the physical side of a box: temperatures, fan RPM, voltages, power draw, and array health, sometimes from a standard MIB and often from the vendor's own. This page covers the pattern that works across gear — the ENTITY-SENSOR-MIB — where the standard runs out and vendor MIBs take over, and how to walk a sensor from the shell before you trust a single dashboard tile.
Parent: monitoring.
What hardware SNMP can read
Physical sensors show up as SNMP objects you can poll like anything else. The usual suspects:
- Temperature — inlet, CPU, board sensors in degrees celsius
- Fan speed — RPM per fan; a stalled fan precedes a thermal event
- Voltage — rail voltages (voltsDC/voltsAC), out-of-spec = trouble
- Power — supply status and draw in watts/amperes
- RAID / storage — logical and physical disk state, rebuilds
Each has a dedicated how-to: temperature, fan speed, power supply, RAID, and voltage. The trick with all of them is that how you read the value is standardized long before which leaf holds it.
The ENTITY-SENSOR-MIB
The standard answer is the ENTITY-SENSOR-MIB (RFC 3433), rooted at 1.3.6.1.2.1.99. It defines a generic sensor table where every physical sensor is described by four objects rather than a bespoke OID per reading:
entPhySensorType(…99.1.1.1.1) — what the sensor measures: celsius, rpm, voltsAC, voltsDC, amperes, watts, percentRH, and so onentPhySensorScale(.2) — the SI multiplier (milli, units, kilo…)entPhySensorPrecision(.3) — how many decimal places the raw value carriesentPhySensorValue(.4) — the reading itself, as an integer
The point is that a manager doesn't need to know the make of the box. It reads the type, applies the scale and precision, and turns entPhySensorValue into a real number with real units. A value of 41 typed celsius with unit scale and zero precision is simply 41 °C. That generality is why ENTITY-SENSOR is the right first stop for hardware.
Standard vs vendor sensors
The catch: not every device populates ENTITY-SENSOR, and the ones that do often expose more through their own enterprise MIB. HP iLO, Dell iDRAC, and Supermicro all publish richer sensor trees under the enterprise arc 1.3.6.1.4.1.
| Source | OID space | Coverage |
|---|---|---|
| ENTITY-SENSOR-MIB | 1.3.6.1.2.1.99 |
Generic, typed sensors — portable across vendors |
| HP iLO / Dell iDRAC / Supermicro | 1.3.6.1.4.1.<vendor> |
Richer, board-specific detail and status codes |
| Base entity model | 1.3.6.1.2.1.47 |
Inventory — where each sensor physically sits |
Practical advice: generic temperature and fan leaf indexes are device-dependent — don't copy an OID off a forum and assume it's your sensor. Learn the ENTITY-SENSOR pattern, then check the vendor page for the exact tree. See devices for platform-specific MIB notes.
Reading a sensor with snmpwalk
Walk the sensor table root and read what the box actually exposes:
snmpwalk -v2c -c <RO_string> <host> 1.3.6.1.2.1.99
ENTITY-SENSOR-MIB::entPhySensorType.10 = INTEGER: celsius(8)
ENTITY-SENSOR-MIB::entPhySensorScale.10 = INTEGER: units(9)
ENTITY-SENSOR-MIB::entPhySensorPrecision.10 = INTEGER: 0
ENTITY-SENSOR-MIB::entPhySensorValue.10 = INTEGER: 41
ENTITY-SENSOR-MIB::entPhySensorType.11 = INTEGER: rpm(10)
ENTITY-SENSOR-MIB::entPhySensorValue.11 = INTEGER: 4800
Index .10 is a temperature sensor reading 41 °C; .11 is a fan at 4800 RPM. If the walk comes back empty, the device may not implement ENTITY-SENSOR at all — jump to its enterprise MIB. An empty branch is a "wrong MIB" signal, not "the hardware is fine."
To map a reading back to where it physically lives, cross-reference the same index against the ENTITY-MIB inventory at 1.3.6.1.2.1.47 — that's how you learn whether sensor .10 is the CPU, the inlet, or a PSU, rather than graphing an anonymous number. Do that mapping once at template time and label the sensors properly; nobody wants to reverse-engineer "temp sensor .10" at 3 a.m. when the alert fires.
Hardware metrics overview
Where to go deep on each signal:
- Temperature — thresholds and thermal trends
- Fan speed — RPM floors and stall detection
- Power supply — redundancy and PSU status
- RAID — array and member-disk health
- Voltage — rail voltages in and out of spec
Reference twins with the object tables live at temperature sensors, power sensors, and RAID sensors.
SNMP vs IPMI/Redfish for hardware
SNMP isn't the only way to read hardware. IPMI (and its successor Redfish) talk to the baseboard management controller directly, often reaching sensors even when the host OS is down. SNMP wins on fleet consistency — one protocol across servers, switches, PDUs, and appliances — while IPMI/Redfish win on depth for a single server's board. Many shops run both: SNMP for the estate-wide view, BMC for lights-out detail. The trade-off is laid out in SNMP vs IPMI.
Frequently asked questions
Can SNMP monitor hardware temperature?
Yes. The ENTITY-SENSOR-MIB (1.3.6.1.2.1.99) reports temperature sensors typed as celsius, and most server and network gear also exposes temperature through a vendor enterprise MIB under 1.3.6.1.4.1. Walk the sensor table and read entPhySensorValue against its type and scale.
What MIB has hardware sensors?
The standard one is the ENTITY-SENSOR-MIB (RFC 3433) at 1.3.6.1.2.1.99, which types every sensor (celsius, rpm, volts, watts, percentRH…) generically. Vendors add richer trees under their enterprise arc — HP iLO, Dell iDRAC, Supermicro and others.
Should I use SNMP or IPMI for hardware?
Use SNMP when you want one protocol across a mixed fleet and the host is up. Use IPMI/Redfish when you need deep, board-level detail on a single server or out-of-band access with the OS down. They complement each other — see SNMP vs IPMI.
Does SNMP read fan speed?
Yes. Fans appear in the ENTITY-SENSOR-MIB typed as rpm, and vendor MIBs expose them too. A fan whose RPM drops toward zero is an early warning of an imminent thermal problem, so it's worth alerting on a floor, not just a failure state.
Key takeaways
- SNMP exposes temperature, fan RPM, voltage, power and RAID health.
- The ENTITY-SENSOR-MIB (
1.3.6.1.2.1.99, RFC 3433) types sensors generically — read value with its type, scale and precision. - Vendors add richer detail under the enterprise arc
1.3.6.1.4.1; exact leaves are device-specific. - Walk
1.3.6.1.2.1.99first; an empty branch means check the vendor MIB. - SNMP for fleet breadth, IPMI/Redfish for board depth — compare them.
- Pair the primary poller with an external check so a dead host still pages you.