--- type: Topic Hub title: "SNMP Storage & Disk Monitoring — Capacity, Usage & Inventory" description: "Track disk space, filesystem capacity and storage inventory over SNMP with the Host Resources hrStorage table, real OIDs and external low-space alerting." resource: "https://snmp-monitoring.com/sensors/storage/" tags: [sensors, snmp] timestamp: 2026-07-13T00:00:00Z --- # SNMP Storage & Disk Monitoring — Capacity, Usage & Inventory 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](/sensors/storage/disk-space-usage.md) — the everyday one: percent-used and free space per filesystem, with thresholds that page before write failures. - [SNMP Storage Capacity](/sensors/storage/storage-capacity.md) — reading `hrStorageSize` and `hrStorageAllocationUnits` correctly to report true total capacity in bytes. - [SNMP Storage Inventory](/sensors/storage/storage-inventory-names.md) — walking `hrStorageDescr` and `hrStorageType` to enumerate exactly which volumes, RAM, and swap a host exposes. - [SNMP HDD & SSD Monitoring](/sensors/storage/hdd-ssd.md) — 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 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](https://snmp-monitoring.com/img/sensors/storage-monitoring.webp) ## 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](/sensors/custom-oid.md). The [HDD & SSD page](/sensors/storage/hdd-ssd.md) covers that split in detail. Keep the two questions separate: "is it filling up?" is `hrStorage`; "is it dying?" is somewhere else. ## FAQ **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](/sensors/storage/disk-space-usage.md), [capacity](/sensors/storage/storage-capacity.md), [inventory](/sensors/storage/storage-inventory-names.md), or [HDD & SSD](/sensors/storage/hdd-ssd.md), then poll from outside with [ostr.io Monitoring](https://ostr.io/service/monitoring) so a volume creeping toward 100% pages you well before the writes start failing. The full menu lives in the [sensor & OID catalog](/sensors/index.md).