SNMP CPU OIDs: hrProcessorLoad & Load Average Reference

By the SNMP Monitoring team · Reviewed July 2026

Need the CPU OID, not a lecture? This is the cheat sheet: hrProcessorLoad, UCD load averages, and the raw ssCpu* counters people delta by hand. Paste into MIB browsers, allowlists, Grafana SNMP plugins—whatever.

If you wanted "how do I alert on this without going mad," that's the twin: monitor CPU via SNMP. Hubs: sensors, all OIDs.

hrProcessorLoad (per core)

This is the HOST-RESOURCES leaf that shows up on a lot of Linux/Unix agents when someone says "CPU OID." Not glamorous. Still the one I paste first.

A few gotchas before the tables: the "recent window" behind the percentage is agent-defined. I've seen people expect one-second resolution because the NMS polls every 30s. You don't get that from this object. Also, logical CPU count from SNMP can disagree with nproc after CPU hotplug or odd container setups—believe the walk for that sample, then go fix the platform story if N is nonsense.

Same data as an HTML table if your renderer hates Markdown grids:

No total-CPU scalar in HOST-RESOURCES. Average the rows yourself (or let the NMS do it). Anything that claims it "reads CPU" via 1.3.6.1.2.1.25.3.3.1.2 is on this column—aggregation is on them.

Empty table? Agent might not implement HOST-RESOURCES, or your SNMP view hides it. Don't assume every appliance is a Linux box with snmpd.

UCD load & CPU OIDs

Net-SNMP land: enterprise 2021 (UCD-SNMP-MIB).

Load average — laLoad

• Base: 1.3.6.1.4.1.2021.10.1.3
• Usually .1 / .2 / .3 → 1 / 5 / 15 minute load
• Not a 0–100 gauge. Same idea as uptime load averages on Unix.

Raw counters people still use

I only list these because they're all over old templates. Confirm on your agent before you tattoo them into production:

• ssCpuRawUser — 1.3.6.1.4.1.2021.11.50
• ssCpuRawSystem — 1.3.6.1.4.1.2021.11.52
• ssCpuRawIdle — 1.3.6.1.4.1.2021.11.53

They're counters. One sample is useless. Two samples + math = approximate user/system/idle split. If a leaf doesn't resolve, walk 1.3.6.1.4.1.2021.11 and read the names—don't invent digits.

Also see system load sensors.

When do I pick what?

• Want percent per core with zero math → hrProcessorLoad
• Want load average → laLoad
• Want DIY breakdown and you like pain → ssCpuRaw*

Worked snmpwalk example

Per-core load:

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

HOST-RESOURCES-MIB::hrProcessorLoad.196608 = INTEGER: 8
HOST-RESOURCES-MIB::hrProcessorLoad.196609 = INTEGER: 22
HOST-RESOURCES-MIB::hrProcessorLoad.196610 = INTEGER: 15
HOST-RESOURCES-MIB::hrProcessorLoad.196611 = INTEGER: 41

Load averages:

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

One core once you know an index:

snmpget -v2c -c <RO_string> <host> 1.3.6.1.2.1.25.3.3.1.2.196608

Allowlist the prefix you poll. Opening the entire enterprise tree "just in case" is how RO communities become free reconnaissance.

Interpreting the values

hrProcessorLoad — each row is a percent-ish integer for one CPU. Host average ≈ sum / count. Example above: (8+22+15+41)/4 = 21.5. Max row is useful when one thread sits on one vCPU. Don't expect sub-second truth; sampling windows are agent-defined.

If you're stuffing this into a time series, store both the average and the per-core series when you can afford the cardinality. Six months later someone will ask "was it one core or all of them?" and a single averaged line won't answer.

laLoad — compare to CPU count. Load near N on an N-CPU box ≈ full; above N ≈ backlog. 1-minute is twitchy; 15-minute is sleepy. Match that to how fast you want to page. String-typed load values still parse as floats in every NMS I've used—just don't treat 0.55 like "55% CPU."

ssCpuRaw* —

1. Sample at T0 and T1
2. Deltas for user / system / idle (and friends if you poll them)
3. percent_user ≈ 100 × Δuser / (Δuser + Δsystem + Δidle + …)
4. Never graph the raw counter as if it were already a percent

Wrap and reboot edge cases: if a counter goes backwards, drop the interval. Don't invent a huge negative spike on the graph.

Most "SNMP CPU is wrong" tickets are unit mistakes. Wrong OID is second place. Agent not implementing the MIB is third. Fourth—and this one is embarrassing—is polling the host's management IP while looking at a different machine's top. Yes, that happens.

Vendor CPU OIDs

Switches and routers often ignore HOST-RESOURCES for CPU. Cisco and friends put control-plane CPU under enterprise trees—5-second / 1-minute / 5-minute style objects, sometimes per module. Not hrProcessorLoad.whatever.

I've lost hours because a template said "CPU" and the device returned something that looked numeric but was a different scale or a different plane (data plane vs route processor). Walk. Label. Then alert.

Rule of thumb I actually follow:

• Generic server / Net-SNMP → start at 1.3.6.1.2.1.25.3.3.1.2
• Network OS → vendor MIB + a lab walk, then template
• Never trust a blog post's enterprise leaf without seeing it on the device
• If two OIDs both claim "CPU," graph both in staging for a day and see which one matches the pain users report

Device notes kickoff: Cisco, broader devices.

For allowlists aimed at external pollers: prefer the specific column OIDs above, not iso or the whole enterprises branch. Narrow views keep a leaked RO string from becoming a free MIB dump.

How to monitor CPU (how-to)

Reference stops here. Ops continues there:

1. Walk, confirm N cores look sane
2. Average hrProcessorLoad (maybe track max)
3. Add load average if saturation matters
4. Multi-sample thresholds, not one-poll drama

Full procedure: How to monitor CPU usage via SNMP. Nearby: server monitoring, alerts, glossary.

Frequently asked questions

What is the OID for CPU usage?

HOST-RESOURCES hosts: 1.3.6.1.2.1.25.3.3.1.2. Walk the column. Gear with only enterprise MIBs is a different hunt.

Is there a total CPU OID?

Not in HOST-RESOURCES. Average the per-core rows. Anyone selling a "total CPU OID" for this MIB is simplifying.

What OID is load average?

UCD: 1.3.6.1.4.1.2021.10.1.3, usually three instances for 1 / 5 / 15 minutes.

How do I read ssCpuRaw counters?

Two polls, subtract, divide components by total delta. Single sample = noise. If the leaf isn't there, walk the UCD branch and map names from the MIB on that host.

Key takeaways

• Per-core %: 1.3.6.1.2.1.25.3.3.1.2 (hrProcessorLoad)
• No total scalar—average rows
• Load: 1.3.6.1.4.1.2021.10.1.3 · raw ticks: …11.50 / …11.52 / …11.53 when present
• Always snmpwalk before you clone a template; vendors wander
• Procedures: CPU how-to · catalog: sensors/all