SNMP Storage & Disk Monitoring — Capacity, Usage & Inventory

Q: Why does my disk size come back as a huge, wrong-looking number?

Because hrStorageSize and hrStorageUsed are in allocation units, not bytes. Multiply each by hrStorageAllocationUnits (1.3.6.1.2.1.25.2.3.1.4) to get bytes. For a simple percent-used, though, hrStorageUsed / hrStorageSize works directly with no conversion.

Q: Can SNMP tell me if a disk is about to fail?

Not through hrStorage — that only reports capacity and usage. SMART health lives in a RAID/vendor MIB or must be exposed via a Net-SNMP extend script and read as a custom OID. See the HDD & SSD page for the approach.

A full disk is one of the most common and most preventable outages there is. Logs pile up, a backup runs long, a temp file balloons, and suddenly the database can't write and the box is wedged — with plenty of warning that nobody was watching. Storage monitoring over SNMP fixes that, and the good news is it's standards-track and portable: nearly everything you need lives in one table, hrStorage, in the Host Resources MIB (RFC 2790). This category routes you to each storage metric and explains how that one table exposes filesystems, RAM, and swap as uniform rows.

One table for all storage

The elegant part of the Host Resources model is that hrStorageTable (1.3.6.1.2.1.25.2.3.1) treats every storage area — mounted filesystems, physical RAM, virtual memory, swap — as a row of the same shape. Each row carries a type, a human description, an allocation-unit size, a total size, and an amount used. That's why disk space, memory, and swap all read the same way over SNMP; they're just different rows of one table distinguished by hrStorageType.

Two columns do the real work and one is a trap. hrStorageSize (.5) is the total and hrStorageUsed (.6) is the amount consumed — but both are measured in allocation units, not bytes. To get real capacity you multiply by hrStorageAllocationUnits (.4), the block size for that row. Skip that multiplication and a 4 TB volume with a 4096-byte block size reads as roughly a billion, which looks like a bug until you remember the units. Percentage used, thankfully, needs no conversion: hrStorageUsed / hrStorageSize is unit-independent.

The storage metric pages

Each page below covers one angle of storage monitoring with real OIDs, query commands, and the allocation-unit math worked through:

SNMP Disk Space Monitoring — the everyday one: percent-used and free space per filesystem, with thresholds that page before write failures.
SNMP Storage Capacity — reading hrStorageSize and hrStorageAllocationUnits correctly to report true total capacity in bytes.
SNMP Storage Inventory — walking hrStorageDescr and hrStorageType to enumerate exactly which volumes, RAM, and swap a host exposes.
SNMP HDD & SSD Monitoring — the physical-device angle, including where SMART-style health lives (hint: not in hrStorage) and when you need a vendor MIB.

Key hrStorage OIDs

Every column below is indexed by hrStorageIndex, so a single walk lines them all up per storage area.

Object	OID	What it gives you
`hrStorageDescr`	`1.3.6.1.2.1.25.2.3.1.3`	Description — mount point, "Physical memory", "Swap space"
`hrStorageAllocationUnits`	`1.3.6.1.2.1.25.2.3.1.4`	Block size in bytes (the multiplier)
`hrStorageSize`	`1.3.6.1.2.1.25.2.3.1.5`	Total size in allocation units
`hrStorageUsed`	`1.3.6.1.2.1.25.2.3.1.6`	Used size in allocation units

Walk the whole table with snmpwalk -v2c -c public <host> 1.3.6.1.2.1.25.2.3.1, then read hrStorageDescr to find the index of the filesystem you care about before computing used / size for its percentage.

Diagram of the Host Resources hrStorage table exposing filesystems, RAM and swap as uniform rows to an external poller

A caveat on disk health

hrStorage tells you how full a volume is, not whether the underlying drive is healthy. SMART attributes — reallocated sectors, wear leveling, pending failures — are not part of the Host Resources MIB. For physical-device health you generally need a RAID controller or vendor MIB, or you expose smartctl output through Net-SNMP's extend mechanism and read it as a custom OID. The HDD & SSD page covers that split in detail. Keep the two questions separate: "is it filling up?" is hrStorage; "is it dying?" is somewhere else.

Frequently asked questions

Why does my disk size come back as a huge, wrong-looking number?

Because hrStorageSize and hrStorageUsed are in allocation units, not bytes. Multiply each by hrStorageAllocationUnits (1.3.6.1.2.1.25.2.3.1.4) to get bytes. For a simple percent-used, though, hrStorageUsed / hrStorageSize works directly with no conversion.

Are RAM and swap really in the same table as disks?

Yes. The Host Resources MIB models physical memory and swap as rows of hrStorageTable, distinguished by hrStorageType. That's why memory and swap monitoring share the same OIDs and math as filesystem monitoring.

Can SNMP tell me if a disk is about to fail?

Not through hrStorage — that only reports capacity and usage. SMART health lives in a RAID/vendor MIB or must be exposed via a Net-SNMP extend script and read as a custom OID. See the HDD & SSD page for the approach.

Does external monitoring track disk space by default?

Yes. Storage capacity and usage are part of ostr.io's default health check — it polls the hrStorage table from outside your network and alerts by email and SMS before a filesystem fills up.

Conclusion

Storage monitoring is one of the highest-value, lowest-effort things you can do with SNMP, because a full disk is both common and entirely predictable. Lean on the hrStorage table (1.3.6.1.2.1.25.2.3.1), remember to multiply by hrStorageAllocationUnits when you want real bytes, and keep "how full" separate from "how healthy." Start with disk space, capacity, inventory, or HDD & SSD, then poll from outside with ostr.io Monitoring so a volume creeping toward 100% pages you well before the writes start failing. The full menu lives in the sensor & OID catalog.