HPE iLO temperature monitoring over SNMP

Every ProLiant measures the air going into it. Getting that number out over SNMP is straightforward once you know two things — and both of them are things HPE does differently from everyone else.

1. Turn the SNMP agent on in iLO

On some firmware the iLO SNMP agent ships disabled, so the first symptom is not a wrong reading — it is silence. In the iLO web interface the settings live under the management or SNMP section; the exact path moves between iLO 4, 5 and 6, so look for SNMP Settings rather than following a fixed menu trail. You need:

• The SNMP agent enabled.
• A read community for v2c, or an SNMPv3 user — iLO 5 and 6 support v3 with authentication and privacy; on iLO 4 it depends on the firmware revision.
• Your monitoring host able to reach the iLO on UDP 161. More often than not, a timeout turns out to be a management VLAN or firewall rule rather than iLO itself.

The same settings can be driven over the Redfish API or hponcfg if you would rather script it across a fleet than click through each server.

2. Find the ambient sensor

A ProLiant exposes a lot of temperature sensors — intake, one per CPU, memory zones, power supplies, sometimes storage cages. Only the ambient one tells you about the room. A CPU at 70 °C under load is perfectly normal and says nothing about your cooling; an intake at 32 °C says every machine in that rack is in trouble.

Walk the locale column and read the codes:

# where is each sensor?
snmpwalk -v2c -c public 10.0.0.25 1.3.6.1.4.1.232.6.2.6.8.1.3

# typical ProLiant output
...8.1.3.1.1 = INTEGER: 11    <- ambient. this is the one.
...8.1.3.1.2 = INTEGER: 6     <- cpu
...8.1.3.1.3 = INTEGER: 6     <- cpu
...8.1.3.1.4 = INTEGER: 7     <- memory
...8.1.3.1.5 = INTEGER: 10    <- power supply

The full enumeration, straight from the CPQHLTH-MIB:

On Gen8 and later the ambient sensor is usually number 1 — the one the iLO web interface labels 01-Inlet Ambient — but the numbering moves between models, and reading the locale column costs you one command.

3. Read the temperature

# the ambient sensor, chassis 1, sensor 1
snmpget -v2c -c public 10.0.0.25 1.3.6.1.4.1.232.6.2.6.8.1.4.1.1
# INTEGER: 22   ->   22 °C, no maths required

On SNMPv3, which is what you should be using if the management network is shared:

snmpget -v3 -l authPriv -u monitor \
  -a SHA -A '<auth-pass>' -x AES -X '<priv-pass>' \
  10.0.0.25 1.3.6.1.4.1.232.6.2.6.8.1.4.1.1

Unlike Dell, there is no divide-by-ten here: whole degrees, exactly as returned. HPE does define a cpqHeTemperatureHwLocation string at …8.1.8, but it is optional and only populated on complex multi-enclosure hardware — on an ordinary ProLiant it comes back empty, which is precisely why the locale code matters.

4. Check the condition before you trust the number

A sensor that has failed still answers; it just answers with something meaningless. Two guards, both cheap:

• cpqHeTemperatureCelsius returns -1 when the agent cannot determine a value. Treat that as “no reading”, never as a temperature — a graph that plots −1 °C next to real values makes every average meaningless.
• cpqHeTemperatureCondition returns 2 when the sensor is fine, 3 when it is outside its normal operating range, and 4 when the condition could permanently damage the system. Poll it alongside the value and discard anything that is not 2, or you will eventually spend an hour chasing a cooling failure that was really a dead sensor.

There is also a single system-wide summary at 1.3.6.1.4.1.232.6.2.6.3.0 (cpqHeThermalTempStatus), on the same 2 = ok scale. It is a useful coarse health check, but it tells you nothing about the room — a server can report ok while sitting in air that is slowly cooking the rack next to it.

5. Set a threshold that means something

It is tempting to read cpqHeTemperatureThreshold and alert on that number. Don't. It is the point at which HPE itself acts, and what it does depends on the sensor's threshold type:

Alerting at that line means being told at the moment the machine powers itself off. You want to know long before. Check the operating specification for your exact ProLiant generation, but as a working starting point for a mixed server room, alert on the ambient reading:

Whatever numbers you choose, add a hold window — require the reading to stay over the line for a few minutes before it pages anyone. A single odd sample at 3 a.m. is not a cooling failure, and an alert that cries wolf gets muted, which is worse than no alert at all.

Doing this across a fleet

One ProLiant is a snmpget in a cron job. Thirty of them across four racks is a different problem: you want every intake reading in one place, the hot one obvious without opening thirty graphs, and one alert for a cooling failure rather than thirty.

That is what RackMon does: the iLO profile above ships as a template, so adding a ProLiant sets up the ambient, CPU and fan metrics with the OIDs already right — including the two-part index and the fan speed column that is not the fan condition. It starts on sensor 1 because that is where the ambient probe normally is; confirm it with the locale walk above and, if your model differs, change the OID on that one device. Self-hosted in one container, free for unlimited devices.

See it with live data   Install it

Other hardware

Dell, Cisco, Juniper, APC and the vendor-neutral standard are all in the SNMP temperature OID reference, each with its own scaling and unit traps. There are step-by-step guides for Dell iDRAC — where the trap is tenths of a degree rather than a location code — and for APC cards and probes. If you are still deciding what to measure and where to put the sensors, start with the rack temperature monitoring guide.

← All vendor OIDs   Monitoring guide