SNMP Storage Capacity

Before you can say a disk is "80% full," something has to tell you what 100% actually is. That number is the total capacity of the volume, and SNMP disk capacity monitoring is how you read it straight off a running server without logging in. This page owns that one value: what total storage size means, the exact capacity OID that returns it, how the raw figure maps to real gigabytes, and why tracking capacity over time — not just today's snapshot — quietly tells you when a volume has been resized, remounted, or is about to be outgrown. It leans entirely on the SNMP daemon your server already runs.

What is Storage Capacity and why monitor it

Storage capacity is the total size of a storage area — the denominator behind every "percent used" figure you'll ever chart. Under the Host Resources MIB the same model covers every filesystem on the box, plus physical and virtual memory, because they're all just storage areas with a size and an amount consumed. On this page we're interested in the total: how big is /, how big is the data mount, how many blocks does swap have.

Why monitor a number that seems static? Because it isn't as static as people assume, and the surprises are the interesting part. A capacity reading that changes on its own is a signal: a volume was grown by a cloud auto-resize, a filesystem was recreated smaller than intended, an LVM extend didn't take, or a mount you expected simply isn't there — which shows up as a capacity you can't read at all. Each of those is worth catching early.

There's a second, subtler reason. Capacity is the baseline your alerts depend on. If you're firing a low-space warning at "85% of storage size snmp reports," and that size silently drops after a reconfiguration, your thresholds now mean something different than they did yesterday. Watching total capacity keeps the percentage math honest. Symptoms of a capacity problem are rarely loud — a mount that reads as zero size, a volume that never grows despite an expansion order, a plan that assumed 2 TB where the box only has 500 GB. Monitoring it turns those quiet mismatches into something you actually notice.

The OID: 1.3.6.1.2.1.25.2.3.1.5

The value that reports total size is 1.3.6.1.2.1.25.2.3.1.5, named hrStorageSize in the Host Resources MIB (RFC 2790). It's the capacity OID that anchors the whole storage table. Like its siblings it's a column, not a scalar — the agent returns one row per storage area, each keyed by an hrStorageIndex.

The units trip everyone up once. hrStorageSize is not bytes; it's the total number of allocation units (the block size) in that storage area. To get a real byte figure you multiply by hrStorageAllocationUnits (1.3.6.1.2.1.25.2.3.1.4):

total bytes = hrStorageSize × hrStorageAllocationUnits

So a volume with hrStorageSize = 26214400 and an allocation unit of 4096 bytes is 26214400 × 4096 = 107,374,182,400 bytes, or about 100 GB. Pair hrStorageSize with hrStorageUsed (1.3.6.1.2.1.25.2.3.1.6, covered on the disk space usage page) and you have both halves of every percent-full calculation.

How to query it

Any Net-SNMP client will read the capacity OID immediately. The examples assume an SNMPv2c agent with a read-only community; if that isn't configured yet, the snmpd.conf guide covers it.

1. Walk the size column for every storage area:

   snmpwalk -v2c -c public 10.0.0.5 1.3.6.1.2.1.25.2.3.1.5
   

   Sample output — total size per area, in allocation units:

   HOST-RESOURCES-MIB::hrStorageSize.1 = INTEGER: 4041028
   HOST-RESOURCES-MIB::hrStorageSize.31 = INTEGER: 26214400
   HOST-RESOURCES-MIB::hrStorageSize.36 = INTEGER: 5242880
   

2. Read one volume's capacity by index (here / at index 31):

   snmpget -v2c -c public 10.0.0.5 1.3.6.1.2.1.25.2.3.1.5.31
   

3. Fetch the allocation unit for the same index to convert to bytes:

   snmpget -v2c -c public 10.0.0.5 1.3.6.1.2.1.25.2.3.1.4.31
   

The index is just a handle, not a label. Index 31 means "root" only because the matching hrStorageDescr row says so, so resolve names first via storage inventory before trusting any index. An empty walk usually means the subtree isn't in the agent's view — add it through your OID allowlist. A hang instead points at community, port, or firewall.

Normal vs alarming values & thresholds

Capacity isn't a metric you threshold the way you do usage — a "healthy" size is just the size you provisioned. What you alert on is change and mismatch. Useful signals to watch:

• Capacity dropped unexpectedly — a volume whose hrStorageSize shrank between polls almost always means a reconfiguration, a remount, or a filesystem recreated wrong. Alert on any decrease you didn't schedule.
• Capacity reads as zero or vanishes — a mount that reports zero size, or disappears from the walk entirely, usually means it failed to mount. That's an outage waiting to be noticed.
• Capacity smaller than planned — after a provisioning or resize job, confirm the new storage size snmp value matches what you ordered. A missed LVM extend is silent otherwise.
• Approaching a fixed ceiling — when total size can't grow (bare-metal disk, fixed instance store), rising usage against a flat capacity is your real runway. Track the gap.

The practical move: baseline each volume's expected capacity, then alert on deviation. A steady, expected size is the boring result you want — it's the unexpected jump or drop that earns a notification.

Alerting on this metric externally

A capacity check that runs on the server it's measuring shares the server's fate. If a mount fails and the volume that holds your monitoring scripts is the one that vanished, the local checker can't tell you its own capacity just went to zero. The blind spot is built in.

Reading the capacity OID from outside the box removes that dependency. This is the point of double durability: an independent watcher keeps polling hrStorageSize from beyond your network, so a remount failure or a crashed host still surfaces as an alert rather than silence. SNMP is pull-based, so the external side simply reads 1.3.6.1.2.1.25.2.3.1.5 on its own schedule and compares it against the baseline on its own hardware.

ostr.io Monitoring is the zero-setup way to do exactly that. It polls your storage OIDs independently and sends real-time email and SMS alerts when a value drifts from normal — so a capacity that suddenly reads wrong reaches you even when the server itself has gone quiet.