SNMP Temperature Monitoring

Heat is the slow killer in any rack. It doesn't crash a server the way a bad disk does — it degrades it, throttles it, and shortens its life while everything still looks green on the dashboard. SNMP temperature monitoring is how you put a number on that heat and watch it drift, whether the reading comes off a CPU die, a chassis intake, or a probe hanging in the hot aisle. Here's the honest catch, though, and it's the first thing to say plainly: temperature is not one of the metrics your server publishes out of the box. There's no universal OID for it. To monitor temperature over SNMP you almost always need a vendor MIB or a custom OID, and this page walks through exactly why, where to find the right object, and how to wire it up.

What is Temperature monitoring

Temperature monitoring means polling the thermal sensors baked into your hardware — and sometimes the room around it — and turning those readings into a time series you can chart and alert on. Modern gear is stuffed with these sensors. A single server might report a CPU package temperature, several DIMM temperatures, an inlet (ambient) reading near the front bezel, an exhaust reading at the back, and a few board-level spots the vendor thought worth watching.

Why bother? Because heat behaves predictably right up until it doesn't. When a CPU crosses its thermal limit it throttles — the clock drops, throughput sags, and latency climbs — long before anything logs an error. Push further and the board triggers a protective shutdown. Sustained warmth you never notice is arguably worse: capacitors dry out, fans wear, and mean time between failures quietly falls. Inlet temperature matters just as much as component temperature, because a climbing intake reading is often the first sign of a failing CRAC unit or a blocked airflow path in the aisle.

So the value you're chasing isn't a single "is the server hot" flag. It's a set of readings, each with its own normal range, that together tell you whether the machine is comfortable, working hard, or heading for trouble. Monitor temperature over SNMP and you get that picture remotely, on a cadence you control, without logging into a single box.

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

The Host Resources MIB (RFC 2790) is the tree that gives you CPU load, memory, storage, and uptime — the stuff at 1.3.6.1.2.1.25.*. People reasonably expect temperature to live there too. It doesn't. That MIB was scoped around logical host resources: processors as schedulable units, storage as allocation units, running software. Physical environmental readings simply weren't its job.

There's a standard home for physical sensors, mind you. The Entity Sensor MIB (RFC 3433) defines entPhySensorValue at 1.3.6.1.2.1.99.1.1.1.4 — a generic column meant to carry any physical sensor's current reading, temperature included. When a device implements it, that's the cleanest place to look. But — and this is the rub — RFC 3433 support is uneven. Plenty of servers, switches, PDUs, and environmental probes never populate it, exposing their thermal data through their own enterprise MIB instead.

The upshot is that temperature is an advanced sensor, not a default one. It won't appear in a plain walk of the standard trees, and no monitoring tool collects it automatically without being told where to look. You have to identify the specific object your hardware uses, then explicitly allow and poll it. That's more work than reading hrProcessorLoad, but it's completely doable — and the payoff is visibility into a failure mode that silent green dashboards routinely miss.

Finding the right vendor OID

There's no shortcut around it: you need to know which object your device uses. Start with the vendor's own MIB. Hardware makers publish MIB files that document their sensor OIDs; load the right one into a MIB browser or into snmptranslate, and the thermal objects usually announce themselves by name. Failing that, discovery by walking works well — poke the enterprise subtree and watch for values that track the number you'd expect a temperature to be.

A practical discovery pass looks like this:

• Try the standard first. snmpwalk -v2c -c public <host> 1.3.6.1.2.1.99.1.1.1 — if the Entity Sensor MIB is implemented, temperatures surface here, tagged by entPhySensorType (which enumerates celsius among its unit types).
• Then walk the vendor's enterprise tree under 1.3.6.1.4.1.<vendor-number> and look for reasonable Celsius values changing slowly over time.
• Cross-check the units. entPhySensorScale and entPhySensorUnitsDisplay (or the vendor equivalent) tell you whether a "42" means 42 °C or 42 tenths of a degree.

The names below are real MIBs from real vendors — but the exact numeric OID and index differ by model, so treat these as where-to-look pointers, not copy-paste values. Always confirm against the MIB shipped for your device.

Don't fabricate a number if you can't find the object — poll the wrong OID and you'll chart nonsense with total confidence. When in doubt, the custom OID guide covers discovery in more depth.

Setting it up as a custom OID

Once you've pinned down the object, wiring it up is mechanical. Because temperature isn't collected by default, the two things that trip people are (a) the agent not exposing the OID and (b) the poller not being told about it. Both are quick fixes.

1. Confirm the reading by hand. snmpget -v2c -c public <host> <your-temperature-OID> should return a plausible value. If it times out, the problem is reachability or community string, not the OID.
2. Expose it in the agent. Edit your snmpd.conf so the daemon actually serves that branch. On Linux you may also need to enable the lm-sensors extension for the LM-SENSORS-MIB objects to appear.
3. Allow the OID. Add a view ... included line for the exact object in your OID allowlist — a restrictive allowlist is good security, but it'll silently hide the sensor until you add it.
4. Register it as a custom OID in your poller. Follow custom OID monitoring to add the object, label it, and set its unit so charts read in degrees rather than raw integers.
5. Sanity-check the scale. Some agents report tenths of a degree or apply an entPhySensorScale factor. Verify one known value against a physical reading before you trust the graph.

Treat this as advanced setup. It sits alongside the other physical readings you might wire the same way — you'll find the full menu in the sensor & OID catalog and the flat all sensors index.

Alerting

Thresholds for temperature should come from the hardware, not from a gut feel. Most vendor MIBs expose their own warning and critical limits right next to the reading, and many devices also carry an operational-status object that flips to a non-normal state when a sensor trips. Read those. They're tuned to the silicon and they beat any round number you'd invent.

For ambient and inlet readings, ASHRAE's TC 9.9 guidance is the usual reference point that facilities teams lean on for target ranges — use it as a frame, then baseline each location against its own normal. A few habits keep temperature alerts trustworthy:

• Alert on sustained rise, not a single sample. A brief bump during a workload spike isn't an incident; a slow climb that won't come back down is.
• Separate inlet from component alarms. A hot intake points at the room or airflow; a hot CPU with a cool intake points at the heatsink or a dead fan.
• Watch the rate of change. A fast ramp usually means a fan or airflow failure and deserves a louder page than a gentle seasonal drift.

Here's the part on-box tooling struggles with. If a server is cooking itself toward a thermal shutdown, the agent trying to warn you is running on that same overheating, throttling box — and it may lose the race. Polling from outside sidesteps that entirely. That's the reasoning behind double durability: an independent watcher keeps reading your temperature OID even as the host degrades. ostr.io Monitoring polls your chosen temperature object from beyond your network and fires real-time email and SMS alerts the moment it crosses your limit, so a machine sliding toward thermal cutoff still reaches you.