How to monitor server rack temperature over SNMP
Overheating is the quiet killer of server rooms: it shortens hardware life, throttles performance, and the first sign is often a failure, not a warning. This guide covers what to measure, where to put sensors, what thresholds are safe, and how polling and alerting should actually behave — so you know a rack is heating up long before anything trips.
1. What to actually measure
“Room temperature” from one wall sensor is nearly useless — air stratifies and a single hot rack can cook while the room reads fine. Measure at the equipment, per rack:
- Intake (cold aisle) temperature — the air your gear is breathing. This is the number ASHRAE guidance is written against.
- Exhaust (hot aisle) temperature — how hot the air leaves. A widening intake-to-exhaust delta can signal airflow problems or a failing fan.
- Per-device sensors — most servers, switches and PDUs expose inlet/CPU/board temperatures over SNMP. Poll them; they’re free data.
- Top / middle / bottom of the rack — heat rises, so the top U’s run hottest. One sensor mid-rack hides the worst spot.
2. Safe thresholds (a sane starting point)
ASHRAE’s widely-used “recommended” envelope for data-center intake air is roughly 18–27 °C (64–80 °F), with an “allowable” range that goes higher for short periods. For a mixed SMB/edge room, sensible alert bands are:
| Intake temperature | Status | Action |
|---|---|---|
| ≤ 27 °C / 80 °F | Nominal | None |
| 27–32 °C / 80–90 °F | Warning | Investigate airflow / cooling |
| ≥ 32 °C / 90 °F | Critical | Act now — cooling likely failing |
Treat these as a starting point, not gospel — check your hardware vendors’ own inlet limits and your local ASHRAE class. The point is to alert on intake, at the rack, with a margin before hardware limits.
3. Why SNMP
SNMP (Simple Network Management Protocol) is the lingua franca of infrastructure telemetry. Almost everything in a rack — servers’ BMC/iDRAC/iLO, managed switches, UPSs, PDUs and dedicated temperature/humidity probes — can expose readings over SNMP. Two versions matter:
- SNMP v2c — simple, community-string based, unencrypted. Fine on a trusted management VLAN.
- SNMP v3 — adds authentication and encryption (authPriv). Prefer it anywhere the management network isn’t fully isolated.
You read a device’s temperature by polling its OID (object identifier). Vendors publish these in MIBs; a sensor probe might expose intake temperature at an OID you poll every 15–60 seconds.
The OIDs you actually need
Most guides stop at “poll the vendor’s OID” without telling you which one. Here are the real ones.
Start with the standard, not the vendor. RFC 3433 defines a vendor-neutral sensor table, and a surprising amount of modern gear implements it. If it answers, you can use one OID across your whole estate instead of a different one per brand:
# every sensor value the device exposes
snmpwalk -v2c -c public 10.0.0.10 1.3.6.1.2.1.99.1.1.1.4
# the human-readable names, so you know which index is the inlet
snmpwalk -v2c -c public 10.0.0.10 1.3.6.1.2.1.47.1.1.1.1.2
On SNMP v3 the same walk becomes:
snmpwalk -v3 -l authPriv -u monitor -a SHA -A '<auth-pass>' -x AES -X '<priv-pass>' 10.0.0.10 1.3.6.1.2.1.99.1.1.1.4
Match the index from the second walk (something like “Inlet Temp” or “Ambient Zone”) to the index in the first, and you have your inlet reading.
Common vendor OIDs
| Device | OID | Notes |
|---|---|---|
| Any device implementing the standard | 1.3.6.1.2.1.99.1.1.1.4ENTITY-SENSOR-MIB · entPhySensorValue | The one to try first. Read entPhySensorType (…99.1.1.1.1) to confirm the unit is celsius(8), and entPhySensorScale / entPhySensorPrecision to scale the raw integer correctly. |
| Cisco switches & routers | 1.3.6.1.4.1.9.9.13.1.3.1.3CISCO-ENVMON-MIB · ciscoEnvMonTemperatureStatusValue | Whole degrees celsius. Newer IOS-XE also answers on the ENTITY-SENSOR-MIB above — prefer that if it responds. |
| Juniper | 1.3.6.1.4.1.2636.3.1.13.1.7JUNIPER-MIB · jnxOperatingTemp | Celsius, indexed per operating component (routing engine, FPC, chassis). |
| Dell servers (iDRAC) | 1.3.6.1.4.1.674.10892.5.4.700.20.1.6IDRAC-MIB · temperatureProbeReading | Returns tenths of a degree — divide by 10. Index 1 is normally the inlet probe, which is the one you want. |
| HPE servers (iLO) | 1.3.6.1.4.1.232.6.2.6.8.1.4CPQHLTH-MIB · cpqHeTemperatureCelsius | Celsius. Pair with cpqHeTemperatureLocale to find which entry is the ambient/inlet sensor. |
| APC / Schneider NMC probes | 1.3.6.1.4.1.318.1.1.10.2.3.2.1.4PowerNet-MIB · iemStatusProbeCurrentTemp | Integer, and the unit follows the card’s configured scale — check whether the NMC is set to °C or °F before you trust it. |
Verify before you trust any of these. OIDs shift between models and firmware revisions, and the two things that most often go wrong are scaling (a value of 275 meaning 27.5 °C) and units (a card quietly reporting °F). Walk the OID on your own hardware, compare it against what the device’s own web UI shows, and only then wire it into alerting. A threshold built on a mis-scaled reading is worse than no monitoring at all, because you will trust it.
If you would rather not maintain this mapping by hand, that is precisely what RackMon ships: per-vendor OID profiles, inlet and device temperature tracked separately, and a per-U heatmap so the hot node is obvious without reading a chart. There is a live read-only demo with real data. If you are weighing it against the usual suspects, the comparison with Zabbix, PRTG, LibreNMS and Checkmk is the honest version, and the FAQ covers licensing and what the free Community edition includes.
4. Setting up monitoring
- Put your management interfaces on a dedicated VLAN and allow your monitor to reach them on UDP/161.
- Enable SNMP on each device (v3 with authPriv where you can) and note the temperature OIDs.
- Add a few temperature/humidity probes per rack (intake + exhaust) if your gear doesn’t already expose good inlet sensors.
- Poll on a sensible interval — 15–60s is plenty for thermals; you’re watching a slow-moving physical quantity.
- Store history so you can see trends, not just the current number — the week-long climb matters as much as the spike.
5. Alerting that you’ll actually trust
Bad alerting trains people to ignore alerts. Good rack-thermal alerting should:
- Use hold windows — don’t fire on a single stray reading; require the condition to persist (e.g. 2–3 minutes).
- Deduplicate and correlate — ten devices in one rack going hot is one incident, not ten pages.
- Never fake a recovery — a missed poll or a maintenance window is “no data”, not “all clear”.
- Escalate — email first, then chat (Slack/Teams/Telegram) or a webhook if unacknowledged.
6. Reporting
If you host for clients (colocation, MSP), turn the data into something they’ll accept: availability and SLA-compliance figures, per-device downtime, and a read-only public status page so tenants can self-serve instead of emailing you.
The fast path
You can build all of the above with a general-purpose monitoring stack — or you can run a tool that’s already shaped around this exact job. RackMon is a self-hosted monitor that does rack thermals + SNMP v2c/v3 out of the box: a live per-U heatmap of every rack, honest alerting (hold windows, dedup, no fake “recovered”), SLA/uptime PDF reports and a public status page — in a single container, in about ten minutes. The Community edition is free forever.