SNMP Memory (RAM) Monitoring

SNMP memory monitoring answers a question every operator asks eventually: how much RAM is this box actually using, right now, without me logging in to check? The reading lives in a standard MIB, so any Net-SNMP agent can serve it and any poller can read it. This guide covers what physical memory means in SNMP terms, the exact hrStorage OIDs that report it, how to query them by hand, sensible thresholds, and why the safest place to watch memory from is somewhere other than the server itself.

What is Memory (RAM) and why monitor it

RAM is the fast, volatile working space where the operating system and every running program keep the data they're actively using. It's finite, and it fills up. When it does, the kernel starts making unpleasant choices: pushing pages out to swap, dropping caches, and — in the worst case on Linux — invoking the out-of-memory killer to shoot a process in the head so the rest of the system survives.

That's why monitoring RAM matters operationally. A slow memory leak in an application won't show up in CPU graphs or request logs; it just quietly eats free memory over hours or days until something breaks. Watch memory usage over time and the leak draws itself as a steady upward ramp long before the crash.

The symptoms of memory pressure are recognizable once you've seen them. Response times get erratic as the system spends cycles reclaiming pages. Swap usage climbs. The kernel log fills with OOM messages. Processes restart for no reason the application team can explain. Every one of those is downstream of a number you could have been graphing.

One nuance separates good memory monitoring from noisy memory monitoring, and it's worth getting straight up front. On Linux, "used" memory as the kernel counts it includes buffers and page cache — data the system is holding onto opportunistically because the RAM would otherwise sit idle. That cache is instantly reclaimable the moment a program needs the space. So a Linux box happily running at what looks like 90% "used" may have vast reclaimable headroom, while a genuinely memory-starved box shows the same 90% but with cache already squeezed to nothing. The number alone doesn't distinguish them; the trend, and the company it keeps (swap, load), does.

Here's the practical payoff of doing memory monitoring over SNMP specifically: it costs you almost nothing to stand up. The agent already knows how much physical memory exists and how much is in use — it publishes both through the Host Resources MIB. You just have to ask.

The OID: 1.3.6.1.2.1.25.2.3.1.x (hrStorage, RAM index)

To monitor RAM over SNMP you read the hrStorage table in the Host Resources MIB (RFC 2790). This is the clever part: physical memory isn't a special scalar — it's a row in the same table that lists your disks and swap. Each storage area gets an index, and you read three columns for that index.

The value type is worth internalizing. hrStorageSize and hrStorageUsed are counts of allocation units, not bytes. To get real bytes you multiply by hrStorageAllocationUnits (1.3.6.1.2.1.25.2.3.1.4). So used memory in bytes = hrStorageUsed × hrStorageAllocationUnits, and percent used = hrStorageUsed ÷ hrStorageSize × 100. The description column is how you find the right row: walk hrStorageDescr first, spot the entry labelled "Physical Memory" (or "Real Memory" on some agents), note its index, then read the size and used columns at that index. The memory usage OID is really this trio working together, keyed by the index you discover.

How to query it

Any Net-SNMP client reads this in seconds. These examples assume an agent running SNMPv2c with a read-only community string; if that isn't configured yet, the snmpd.conf guide walks through it.

1. Find the memory row by walking the description column:

   snmpwalk -v2c -c public 10.0.0.5 1.3.6.1.2.1.25.2.3.1.3
   

   Sample output — note the index on the "Physical Memory" line:

   HOST-RESOURCES-MIB::hrStorageDescr.1 = STRING: Physical Memory
   HOST-RESOURCES-MIB::hrStorageDescr.3 = STRING: Swap Space
   HOST-RESOURCES-MIB::hrStorageDescr.6 = STRING: /
   

2. Read the size and used counts for that index (here, .1):

   snmpget -v2c -c public 10.0.0.5 1.3.6.1.2.1.25.2.3.1.5.1 1.3.6.1.2.1.25.2.3.1.6.1
   

   HOST-RESOURCES-MIB::hrStorageSize.1 = INTEGER: 4096000
   HOST-RESOURCES-MIB::hrStorageUsed.1 = INTEGER: 2867200
   

3. Force numeric output if the MIB isn't installed locally:

   snmpwalk -v2c -c public -On 10.0.0.5 1.3.6.1.2.1.25.2.3.1
   

Multiply the counts by the allocation units to land on bytes, or just divide used by size for the percentage. Most polling tools fold that arithmetic in for you.

A couple of field notes. The index for physical memory isn't guaranteed to be .1 on every system — agents number the storage rows in their own order, so always discover the index from hrStorageDescr rather than hard-coding it, or you'll end up graphing a filesystem and calling it RAM. And if a walk of the storage table comes back empty, the OIDs almost certainly aren't in the agent's allowlisted view; the fix lives in your OID allowlist, not in the command.

Normal vs alarming values & thresholds

There's no universal "bad" number — a caching server is supposed to use most of its RAM — but a few bands hold up when you monitor RAM over SNMP:

• Under ~70% used, sustained — comfortable headroom on a general-purpose host.
• 70–85% sustained — worth a warning-level trigger; fine briefly, watch the trend.
• 85–95% sustained — high; on Linux, cross-check whether swap is climbing too, which signals real pressure rather than benign caching.
• Above 95% with rising swap — critical. The OOM killer territory. Alert and page.
• A steady upward ramp over hours — the classic memory-leak signature, regardless of the absolute level. Alert on the slope, not just the ceiling.

One caveat that saves false alarms: Linux uses spare RAM for file cache, so "used" can look alarmingly high while the system is perfectly healthy. Pairing the memory reading with swap monitoring tells the real story — memory that's full and swapping is the combination that hurts.

Alerting on this metric externally

Polling hrStorageUsed tells you memory is tight this second. What actually prevents an outage is being told the moment it's been tight too long — and that's exactly where on-host alerting has a blind spot. When a server exhausts memory, the OOM killer may take out the very agent that was supposed to warn you, or thrashing may starve it of the CPU it needs to send a message. The alert dies with the thing it was watching.

Polling from outside sidesteps that. It's the idea behind double durability: an independent watcher keeps reading 1.3.6.1.2.1.25.2.3.1.6 on its own schedule, on its own hardware, so a memory-starved or fully crashed host still trips an alert. SNMP is a pull protocol, so the external side just asks — the sick server doesn't have to be well enough to answer for itself.