SNMP Server Monitoring: CPU, RAM, Disk & Uptime

By the SNMP Monitoring team · Reviewed July 2026

Servers already speak management protocols if you turn the agent on. SNMP server monitoring is the lightweight path: HOST-RESOURCES (and friends) for CPU, memory, disks, uptime, sessions, processes—plus optional external polls when the local NMS shares fate with the rack.

Parent hub: SNMP monitoring. Device notes: Linux, Windows.

Why monitor servers over SNMP

Pros that hold up in production:

• Built-in / package agent — snmpd or Windows SNMP; no heavy proprietary agent required for basics
• Standard OIDs — portable templates across many Linux builds
• Agentless managers — external pollers only need UDP 161 + community/v3
• Low overhead compared with scraping everything via SSH every minute
• Works offline from the app stack — OS metrics still move when the app is wedged

Limits: app latency, logs, and deep process profiling need other tools. SNMP owns infra vitals.

Key server metrics

Load averages (UCD): 1.3.6.1.4.1.2021.10.1.3 — see system load.

Enabling SNMP on a server

Numbered baseline:

1. Install/enable the agent (snmpd or Windows feature).
2. Configure RO credentials—never leave public on a real network.
3. Restrict sources; prefer an OID view/allowlist.
4. Open UDP 161 from pollers only.
5. Test with snmpget/snmpwalk from the real poller IP.

OS guides: Ubuntu/Debian, Windows Server, snmpd.conf, hub setup.

Reading server metrics with snmpwalk

HOST-RESOURCES storage table (disks, RAM rows, etc.):

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

HOST-RESOURCES-MIB::hrStorageDescr.1 = STRING: Physical memory
HOST-RESOURCES-MIB::hrStorageAllocationUnits.1 = INTEGER: 1024 Bytes
HOST-RESOURCES-MIB::hrStorageSize.1 = INTEGER: 16333648
HOST-RESOURCES-MIB::hrStorageUsed.1 = INTEGER: 8921040
HOST-RESOURCES-MIB::hrStorageDescr.31 = STRING: /
HOST-RESOURCES-MIB::hrStorageSize.31 = INTEGER: 102626168
HOST-RESOURCES-MIB::hrStorageUsed.31 = INTEGER: 45100220

Columns under base 1.3.6.1.2.1.25.2.3.1: descr .3, units .4, size .5, used .6. Bytes = value × units.

CPU column:

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

HOST-RESOURCES-MIB::hrProcessorLoad.196608 = INTEGER: 18
HOST-RESOURCES-MIB::hrProcessorLoad.196609 = INTEGER: 22

Where to find each OID

How-tos stay procedural. Full leaf tables:

• sensors/all
• CPU OIDs · memory · disk
• Twins linked from each server child page

Don't dump entire OID encyclopedias into every how-to—that's what sensors/ is for.

Monitoring servers externally

On-prem pollers miss site-wide death. External SNMPv2c checks read the same class of metrics—uptime, sessions, processes, load, CPU, disk/RAM/swap, interfaces—from outside. ostr.io is built for that pattern with allowlist + dual cadence (double durability). Details: external monitoring, setup ostr.io.

One CTA: use external polling as a second opinion, not as an excuse to leave public on the internet.

Baseline template that doesn't embarrass you

Ship a small pack first:

• sysDescr / sysName (inventory sanity)
• hrSystemUptime
• average hrProcessorLoad (or per-core + average)
• RAM row % used
• / (and data mount) free %
• optional load average
• optional process count / user sessions if you care about sprawl

Then grow. A template with forty broken OIDs teaches the team to ignore red.

Linux vs Windows notes

Linux + net-snmp is the happy path for HOST-RESOURCES. Windows SNMP service can expose useful objects but the shape and enable path differ—use Windows setup and verify with walks, not assumptions copied from a Linux pack. Hypervisors and appliances may skip host resources entirely; don't force this hub's template onto a switch.

Correlation beats single metrics

CPU high + load high + disk busy tells a story. CPU high alone might be a compile job. Disk full + rising sessions might be log spam from stuck clients. Build dashboards that sit related children together; page on combinations when you can. Child guides stay deep; this hub stays the map.

Sessions: ssh-sessions. Processes: processes. Uptime: uptime.

Validation ritual after every agent change

When you touch snmpd.conf, kernel, or major package sets:

1. Walk system + storage + processor columns from the poller.
2. Confirm NMS last-value timestamps move.
3. Fire a test alert in staging.
4. Diff the allowlist if you use one.

Ten minutes here saves a silent weekend. Same ritual after cloning VM templates—cloned communities and identical engine IDs are how security and v3 both get weird.

Storage math reminder used on RAM and disk children: under 1.3.6.1.2.1.25.2.3.1, bytes = value × units (.4), with size .5 and used .6. Get that wrong once and every % graph lies forever.

Process count OID 1.3.6.1.2.1.25.1.6.0 and sessions 1.3.6.1.2.1.25.1.5.0 are cheap heartbeats for “is the OS still sane?” when you don't want full process tables every minute. Use them as companions, not as the only health signal.

If HOST-RESOURCES is half-empty on a host, fix the agent modules before rewriting every template—empty walks are configuration, not destiny. Distro packages sometimes ship minimal views until you open them.

Related reading loop: CPU how-to (already written) → RAM → disk → alerts. Keep that order when training new hires—it matches how outages usually cascade.

Frequently asked questions

How do I monitor a server with SNMP?

Enable a hardened agent, verify with snmpwalk on HOST-RESOURCES OIDs, point your NMS at CPU/RAM/disk/uptime, set multi-sample alerts. Follow the child guides under this hub.

What OID is server uptime?

Host uptime: 1.3.6.1.2.1.25.1.1.0. (sysUpTime 1.3.6.1.2.1.1.3.0 is agent/SNMP engine uptime—related but not identical.)

Can SNMP monitor CPU and RAM?

Yes—hrProcessorLoad for CPU; hrStorageTable (and/or UCD memory) for RAM. See CPU and RAM.

Is SNMP good for Linux servers?

Yes. net-snmp snmpd is standard fare. Pair with app metrics tools for request latency.

Key takeaways

• Server SNMP ≈ HOST-RESOURCES + optional UCD load.
• Key OIDs: CPU …25.3.3.1.2, storage …25.2.3.1, uptime …25.1.1.0.
• Enable → lock down → walk → alert.
• OID detail in sensors; procedures in children.
• Optional external durability via ostr.io. Glossary: glossary.