How to Monitor System Load Average via SNMP

By the SNMP Monitoring team · Reviewed July 2026

CPU % answers “how busy are the cores right now?” Load average answers “how much work is queued or stuck waiting?” They diverge under I/O wait, and if you only watch percent you will miss saturation. This how-to is load average over SNMP—UCD laLoad 1/5/15—not a redo of the CPU how-to.

Twin: system-load sensors. Parent: monitoring. Linux notes: devices/linux.

What load average measures

On Linux, classic load average is roughly the number of processes runnable or in uninterruptible sleep (often disk), averaged over 1, 5, and 15 minutes. It is not capped at 100 and it is not “percent CPU.”

• Load 4.0 on a 4-core box ≈ fully busy run queue (rule of thumb)
• Load 4.0 on 64 cores is a nap
• High load + low CPU % often means I/O wait or blocked tasks

If your NMS graphs load next to hrProcessorLoad, you can see “busy” vs “backed up.”

The UCD load OIDs

UCD-SNMP (common on net-snmp Linux agents):

Base column: 1.3.6.1.4.1.2021.10.1.3 with indexes .1 / .2 / .3. Values are often strings/floats in snmpwalk output. Integer form: laLoadInt 1.3.6.1.4.1.2021.10.1.5 (same index idea).

snmpwalk -v2c -c <RO_string> <host> 1.3.6.1.4.1.2021.10.1.3

UCD-SNMP-MIB::laLoad.1 = STRING: 0.42
UCD-SNMP-MIB::laLoad.2 = STRING: 0.55
UCD-SNMP-MIB::laLoad.3 = STRING: 0.61

Empty walk? Agent may lack UCD objects—common on non-net-snmp gear. Don’t invent enterprise load OIDs; walk or use vendor MIBs.

Interpreting load vs core count

Numbered rules of thumb:

1. Learn N = logical CPUs the OS reports (not always = hrProcessorLoad row count—verify).
2. Treat load ≈ N as “fully utilized run queue” for that window.
3. Load >> N sustained → backlog; investigate.
4. Prefer 5- or 15-minute for alerts; 1-minute is twitchy.
5. Normalize mentally: alert on load/N, not raw 2.0 everywhere.
6. Compare 1 vs 15: rising short window vs long = spike vs chronic.

Example: 8 cores, 5-minute load 12 → about 1.5× cores → worth a look. Same load on 32 cores → fine.

Load vs CPU utilization

When they diverge, check disk, NFS, and swap. CPU how-to: monitor CPU.

Setting load alerts

• Warn: 5-min load > 1.0 × cores for several polls
• Crit: 5-min load > 1.5–2.0 × cores sustained
• Use longer windows for batch hosts
• Don’t page on 1-minute alone

Design patterns: alerts. Frequency of polls: frequency.

Reference

OID encyclopedia: sensors/system-load. Glossary: glossary.

External checks

ostr.io can read system load via 1.3.6.1.4.1.2021.10.1.3 externally—allowlist UCD load if you use that path. See external. One soft product mention for off-box durability.

Ops checklist

1. Confirm UCD load OIDs exist
2. Record core count per host class
3. Graph 1/5/15 + CPU %
4. Alert on 5-min load vs cores
5. Runbook: check I/O when load≫CPU

Failure modes

• Alerting raw load without cores
• Missing UCD on the agent
• Treating load as percent
• 1-minute flapping pages

Worked night-shift

Load 5-min = 18 on 4 cores, CPU 20%: look at disk latency and NFS before killing CPUs. Load 3 on 4 cores, CPU 95%: CPU bound—scale or nice the job. Same dashboard, different fix.

Capturing core count without lying

hrProcessorLoad row count is a decent proxy for logical CPUs when HOST-RESOURCES is complete—but VMs with CPU hotplug and containers can disagree with what the app “thinks” it has. Prefer a documented cores field in the NMS host inventory for alert math (load / cores), and re-verify after resize. If you hard-code “all web VMs are 4 vCPU” you will false-page after the cloud team quietly sets 8.

String vs float parsing

laLoad often returns STRING like 1.23. Your poller must parse float, not treat it as opaque text. laLoadInt exists when you want integer scaling—confirm what your agent multiplies by before graphing. Broken parsers produce flat zero graphs and “load monitoring is useless” folklore.

When UCD is missing

Network OS and appliances usually won’t speak 2021.10. Don’t force this how-to onto switches—use vendor CPU/load enterprise OIDs after a walk, or skip load average entirely and stick to vendor busy %. This page assumes a Linux-style net-snmp agent with UCD objects.

Dashboard recipe

• Top: 5-min load and load/cores
• Middle: average CPU % from hrProcessorLoad
• Bottom: disk latency or iowait if you collect it elsewhere
• Annotation: deploy markers

On-call should see “backed up” vs “busy” in one glance. Link twin OID page in the panel description: sensors/system-load.

Training note for juniors

Have them generate load with a CPU burn and with a disk-heavy find across cold storage. Watch laLoad and hrProcessorLoad side by side. The lab does more than another paragraph of theory: they will feel why both OIDs exist. Then break NFS (lab only) and watch load climb while CPU sleeps—that’s the “why is load high but CPU idle?” FAQ in real life.

Also: document whether alerts use 5-min or 15-min load in the rule name (load5_per_core). Ambiguous “high load” tickets waste time.

Finally, after every major kernel or net-snmp upgrade, re-walk 1.3.6.1.4.1.2021.10.1.3 once—UCD objects rarely vanish, but custom builds sometimes ship minimal MIBs and your load graphs go mysteriously empty.

Frequently asked questions

What OID is load average?

laLoad under 1.3.6.1.4.1.2021.10.1.3 (.1/.2/.3 = 1/5/15 min). Optional laLoadInt …10.1.5.

Load average vs CPU usage?

Load ≈ run-queue depth over time; CPU % ≈ busy time. Not interchangeable—see table above.

What is a high load?

Relative to core count. Load ≈ cores is busy; much higher is backlog.

Why is load high but CPU idle?

Often I/O wait or uninterruptible sleep—processes waiting on disk/network storage, not burning CPU.

Key takeaways

• Load ≠ CPU %; use both.
• UCD 1.3.6.1.4.1.2021.10.1.3 1/5/15.
• Normalize by cores; alert on 5/15 min.
• Twin: sensors/system-load.
• External load: ostr.io.