SNMP System Load Monitoring
The SNMP load average is the single number that best summarizes whether a Unix or Linux server is keeping up with what's being asked of it. It's the metric behind the top-left corner of top and uptime, and SNMP exposes it cleanly so you can graph it, trend it, and alert on it without ever logging in. This guide covers what load average really measures, the exact vendor OID that returns it, how to read the one-, five-, and fifteen-minute figures, how it differs from CPU percentage, and why reading it from outside the machine is what turns a chart into an early-warning system.
What is System Load and why monitor it
Load average is the average number of processes that are either running or waiting to run over a rolling window. Unix reports three figures — averaged over the last 1, 5, and 15 minutes — and the interplay between them tells a story a single snapshot can't. A load of 4.00 on a four-core machine means, roughly, that the CPUs are fully committed with nothing queued behind them; the same 4.00 on a single-core box means processes are stacked four deep, waiting their turn.
That's the first rule of reading it: load is only meaningful relative to core count. Divide the figure by the number of cores. Below 1.0 per core, there's headroom. Around 1.0 per core, the machine is fully utilized. Well above 1.0 per core and sustained, work is backing up faster than the server can clear it.
Why monitor system load specifically? Because it captures pressure that pure CPU percentage misses. On Linux, load also counts processes blocked in uninterruptible I/O wait — so a server drowning in slow disk or a stuck NFS mount shows a high load average even while the CPUs look idle. That divergence is diagnostic gold. High load with low CPU points straight at I/O; high load with high CPU points at compute. The symptom users feel is the same either way: sluggish response, timeouts, requests queuing. The load average sees it coming.
The OID: 1.3.6.1.4.1.2021.10.1.3 (UCD/net-snmp, vendor-private)
The load average OID is 1.3.6.1.4.1.2021.10.1.3, named laLoad, and it lives in the UCD-SNMP-MIB. This one is important to flag: 1.3.6.1.4.1.2021 is the Net-SNMP (former UCD-Davis) enterprise branch — a vendor MIB, not an IETF standard. There's no RFC for it. It's ubiquitous because Net-SNMP is ubiquitous, but a switch or appliance that doesn't run Net-SNMP won't necessarily publish it.
laLoad is a small table with three rows, one per averaging window:
| OID | Object | Window | Value |
|---|---|---|---|
1.3.6.1.4.1.2021.10.1.3.1 | laLoad.1 | 1-minute | Load average as a string |
1.3.6.1.4.1.2021.10.1.3.2 | laLoad.2 | 5-minute | Load average as a string |
1.3.6.1.4.1.2021.10.1.3.3 | laLoad.3 | 15-minute | Load average as a string |
So the base OID 1.3.6.1.4.1.2021.10.1.3 is the column, and the final digit selects the window: .1 for the 1-minute figure, .2 for 5-minute, .3 for the 15-minute average. The value comes back as a display string like "0.42" rather than a scaled integer, which is convenient to read but means your poller parses it as a float.
Don't confuse laLoad with CPU utilization. They answer different questions — see the note below and the CPU monitoring page for the percentage metric at hrProcessorLoad.
How to query it
Any Net-SNMP client reads this instantly. These examples assume an SNMPv2c agent with a read-only community; if that's not configured, the snmpd.conf guide covers it.
- Walk all three load averages at once:
snmpwalk -v2c -c public 10.0.0.5 1.3.6.1.4.1.2021.10.1.3UCD-SNMP-MIB::laLoad.1 = STRING: 0.42 UCD-SNMP-MIB::laLoad.2 = STRING: 0.55 UCD-SNMP-MIB::laLoad.3 = STRING: 0.60 - Read just the 15-minute figure — the least twitchy one for alerting:
snmpget -v2c -c public 10.0.0.5 1.3.6.1.4.1.2021.10.1.3.3UCD-SNMP-MIB::laLoad.3 = STRING: 0.60 - Force numeric output if the UCD-SNMP-MIB isn't installed locally:
snmpwalk -v2c -c public -On 10.0.0.5 1.3.6.1.4.1.2021.10.1.3
Pull all three windows and you can tell direction at a glance: if the 1-minute figure sits well above the 15-minute, load is rising; if it's below, the spike is passing.
Normal vs alarming values & thresholds
Every threshold below is per core — always normalize by dividing the raw load by your core count before comparing:
- Under 0.7 × cores, sustained — healthy. Plenty of headroom.
- 0.7–1.0 × cores — busy but coping; a reasonable warning band.
- Around 1.0 × cores, sustained — fully committed. No spare capacity; new work starts queuing.
- Above 1.5–2.0 × cores, sustained — overloaded. Latency is almost certainly degrading; treat as high priority.
- Brief spikes on the 1-minute figure — usually harmless (a cron job, a deploy). Alert on the 5- or 15-minute window instead so momentary blips don't page you.
Two habits keep these alerts honest. Alert on the longer windows for anything that pages a human — the 1-minute figure is too noisy on its own. And cross-reference: high load with idle CPU means I/O wait, not compute starvation, so pair this with CPU and disk metrics before drawing conclusions.
Alerting on this metric externally
Polling laLoad tells you the run queue is deep right now. What averts an incident is being told the moment it's been deep too long — and a heavily loaded server is precisely the machine least able to send that message. When load is high because the CPUs are pegged or the box is stuck in I/O wait, a local alerting agent competes for the same starved resources. It may never get scheduled to fire.
Watching from outside removes the dependency entirely. That's the reasoning behind double durability: an independent poller keeps reading 1.3.6.1.4.1.2021.10.1.3 on its own hardware and schedule, so an overloaded — or crashed — server still trips its threshold. SNMP is a pull protocol, so the external checker just asks; the struggling host doesn't have to spare cycles to report on itself.
