--- type: Topic Hub title: "SNMP Server Resource Monitoring — CPU, RAM, Load & Uptime" description: "Poll CPU, memory, swap, system load, processes and uptime over SNMP with Host Resources and UCD-SNMP OIDs, plus external reboot and outage alerting." resource: "https://snmp-monitoring.com/sensors/server-resources/" tags: [sensors, snmp] timestamp: 2026-07-13T00:00:00Z --- # 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](/sensors/server-resources/cpu-utilization.md) — 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](/sensors/server-resources/system-load.md) — the 1/5/15-minute load average via `laLoad`, and how to read it relative to core count. - [SNMP Memory (RAM) Monitoring](/sensors/server-resources/ram-memory.md) — real free memory versus buffers and cache, read from the UCD `memory` group or `hrStorage`. - [SNMP Swap Monitoring](/sensors/server-resources/swap.md) — swap usage as an early sign of memory pressure, and why steady swapping hurts latency. - [SNMP Process Monitoring](/sensors/server-resources/processes.md) — the running-software table `hrSWRun`, process counts, and watching that a critical daemon is alive. - [SNMP Uptime & Reboot Detection](/sensors/server-resources/uptime-reboot.md) — `hrSystemUptime` and `sysUpTime`, 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. ![Diagram of Host Resources and UCD-SNMP OIDs for CPU, memory, load and uptime feeding an external poller](https://snmp-monitoring.com/img/sensors/server-resources.webp) ## 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](/sensors/server-resources/uptime-reboot.md) explains how to handle. ## FAQ **Why isn't the load average in the Host Resources MIB?** It just isn't defined there. The 1/5/15-minute load average lives in the UCD-SNMP-MIB (the Net-SNMP vendor branch) as `laLoad` under `1.3.6.1.4.1.2021.10.1.3`. CPU utilization per core, by contrast, is standards-track at `hrProcessorLoad`. **Should I read memory from hrStorage or the UCD memory group?** Either works. `hrStorage` models RAM and swap as storage rows; the UCD `memory` group (`1.3.6.1.4.1.2021.4`) gives dedicated free/total/cached/buffered scalars that are easier to interpret. Most people prefer the UCD group for real free-memory figures. **How do I detect an unplanned reboot over SNMP?** Poll `hrSystemUptime` (`1.3.6.1.2.1.25.1.1.0`) and watch for the value dropping back toward zero between polls. A host that was up for days and now reports seconds has rebooted. Use the host uptime, not the agent's `sysUpTime`. **Does external monitoring collect these by default?** Yes. CPU, load, storage-backed memory and swap, process status, and uptime are all part of ostr.io's default health check, polled from outside your network with email and SMS alerts. ## Conclusion Server resource monitoring is SNMP's home turf: CPU, memory, swap, load, processes, and uptime are all a single poll away, mostly standards-track and portable. Remember the one seam — load average lives in the UCD-SNMP branch (`1.3.6.1.4.1.2021`) while the rest sits in the Host Resources MIB (`1.3.6.1.2.1.25`) — and remember to poll host uptime, not agent uptime, for reboot detection. Start with [CPU](/sensors/server-resources/cpu-utilization.md), [load](/sensors/server-resources/system-load.md), [memory](/sensors/server-resources/ram-memory.md), [swap](/sensors/server-resources/swap.md), [processes](/sensors/server-resources/processes.md), or [uptime](/sensors/server-resources/uptime-reboot.md), then poll from outside with [ostr.io Monitoring](https://ostr.io/service/monitoring) so a box that reboots or wedges still reaches you — the essence of [double durability](/monitoring/double-durability.md). The full menu lives in the [sensor & OID catalog](/sensors/index.md).