SNMP Server Resource Monitoring — CPU, RAM, Load & Uptime
Server resources are the vital signs of a host: how hard the CPU is working, how much memory and swap are left, what the load average looks like, how many processes are running, and how long the box has been up. This is the category SNMP was practically made for — nearly all of it is standards-track, available on any Net-SNMP install out of the box, and portable across almost any Linux server. This page routes you to each resource metric and points out the one place the standards stop and the vendor branch takes over.
Two MIBs cover almost everything
Most of what you'll poll here lives under the Host Resources MIB (RFC 2790) at 1.3.6.1.2.1.25 — CPU load, storage-backed memory and swap, running processes, and uptime all cluster there. The one notable exception is the system load average, the classic 1/5/15-minute figure, which the Host Resources MIB simply doesn't define. For that you drop into the UCD-SNMP-MIB (the Net-SNMP vendor branch) at 1.3.6.1.4.1.2021, where laLoad (1.3.6.1.4.1.2021.10.1.3) exposes it directly. Memory has a similar dual life: you can read it as hrStorage rows or through the UCD memory group (1.3.6.1.4.1.2021.4), which gives cleaner free/total/cached figures. Knowing which tree a metric lives in is half the battle.
The server-resource metric pages
Each page below covers one vital sign with real OIDs, query commands, and threshold guidance:
- SNMP CPU Monitoring — per-core utilization from
hrProcessorLoad(1.3.6.1.2.1.25.3.3.1.2), and why an average hides a pegged core. - SNMP System Load Monitoring — the 1/5/15-minute load average via
laLoad, and how to read it relative to core count. - SNMP Memory (RAM) Monitoring — real free memory versus buffers and cache, read from the UCD
memorygroup orhrStorage. - SNMP Swap Monitoring — swap usage as an early sign of memory pressure, and why steady swapping hurts latency.
- SNMP Process Monitoring — the running-software table
hrSWRun, process counts, and watching that a critical daemon is alive. - SNMP Uptime & Reboot Detection —
hrSystemUptimeandsysUpTime, and how a counter that resets to near-zero reveals an unplanned reboot.
Key server-resource OIDs
| Metric | OID | MIB / standard |
|---|---|---|
| CPU load (per core) | 1.3.6.1.2.1.25.3.3.1.2 | Host Resources MIB (RFC 2790) |
| System load (1-min) | 1.3.6.1.4.1.2021.10.1.3 | UCD-SNMP-MIB (enterprise 2021) |
| Real memory available | 1.3.6.1.4.1.2021.4.6.0 | UCD-SNMP-MIB (enterprise 2021) |
| Total real memory | 1.3.6.1.4.1.2021.4.5.0 | UCD-SNMP-MIB (enterprise 2021) |
| Available swap | 1.3.6.1.4.1.2021.4.4.0 | UCD-SNMP-MIB (enterprise 2021) |
| Running-process count | 1.3.6.1.2.1.25.1.6.0 | Host Resources MIB (RFC 2790) |
| System uptime | 1.3.6.1.2.1.25.1.1.0 | Host Resources MIB (RFC 2790) |
A quick note on .0 versus tables: OIDs ending in .0 (uptime, process count, the UCD memory scalars) are single values you fetch with snmpget. CPU load per core is a table column — one row per processor — so you snmpwalk 1.3.6.1.2.1.25.3.3.1.2 and get a value for each core.
A note on uptime
There are two uptime objects and they don't measure the same thing. sysUpTime (1.3.6.1.2.1.1.3.0) is how long the SNMP agent has been running; hrSystemUptime (1.3.6.1.2.1.25.1.1.0) is how long the host has been up. For reboot detection you want the host figure — when it drops from days back to seconds, the machine restarted. Both are TimeTicks in hundredths of a second, and both can wrap after roughly 497 days, which the uptime & reboot page explains how to handle.