SNMP Storage Inventory

Every storage number SNMP gives you arrives with a bare index — .1, .31, .36 — and not one of them tells you whether you're looking at the root filesystem, a data mount, RAM, or swap. SNMP storage names are what close that gap. This page owns the inventory side of the hrStorage table: the OID that returns human-readable descriptions for each storage area, how those names map indices to real mount points, and why you should always resolve names before you build a single threshold on a usage or capacity figure. Get the storage names right and every other storage metric suddenly means something.

What is Storage Inventory and why monitor it

Storage inventory is the catalog of what a machine's storage table actually contains — the label attached to each row. Under the Host Resources MIB, one table (hrStorageTable) holds every storage area on the box: physical disks and their mounted filesystems, RAM, virtual memory, swap, sometimes a RAM disk or a removable volume. Each row has an index, a type, a size, an amount used — and a description. The description is the inventory. It's the difference between "index 31 is 82% full" and "the root filesystem is 82% full."

Why treat this as something to monitor rather than a one-time lookup? Because the mapping isn't permanent. The hrStorage indices aren't guaranteed stable across reboots, and the set of storage areas changes as mounts come and go. A volume that was index 31 last week can be index 33 today. A data mount that failed to attach simply won't appear in the inventory at all — and a threshold keyed to the old index is now silently watching the wrong thing, or nothing.

So the storage names OID is the map you re-check, not a fact you memorize. Symptoms of an inventory problem are easy to miss: an expected filesystem missing from the walk (it didn't mount), a new device that appeared unannounced, or alerts that quietly went stale because an index shifted under them. Monitoring the inventory keeps every downstream usage and capacity metric pinned to the right physical thing.

The OID: 1.3.6.1.2.1.25.2.3.1.3

The value that returns storage names is 1.3.6.1.2.1.25.2.3.1.3, named hrStorageDescr in the Host Resources MIB (RFC 2790). This is the storage names OID. Unlike the numeric usage and capacity columns, it returns text: a DisplayString describing each storage area. On Linux you'll typically see mount paths and memory labels; on Windows, drive letters and volume descriptions.

Crucially, hrStorageDescr shares its index with every other column in the hrStorageTable. That's the whole point. Row .31 of hrStorageDescr, .31 of hrStorageSize, and .31 of hrStorageUsed all describe the same storage area. So you walk hrStorageDescr to learn that index 31 is /, then read hrStorageUsed.31 and hrStorageSize.31 knowing exactly which filesystem you're measuring.

Typical values look like /, /var, /boot, Physical memory, Virtual memory, Swap space, or C:\ Label:System. The exact wording depends on the operating system and agent, but the intent is always the same: a name you can read, tied to an index you can join.

How to query it

Walking the storage names OID is the first thing to do on any new host. The examples assume an SNMPv2c agent with a read-only community; if that isn't set up, see the snmpd.conf guide.

1. Walk every storage description to build the inventory:

   snmpwalk -v2c -c public 10.0.0.5 1.3.6.1.2.1.25.2.3.1.3
   

   Sample output — the index-to-name map:

   HOST-RESOURCES-MIB::hrStorageDescr.1 = STRING: Physical memory
   HOST-RESOURCES-MIB::hrStorageDescr.3 = STRING: Virtual memory
   HOST-RESOURCES-MIB::hrStorageDescr.6 = STRING: Swap space
   HOST-RESOURCES-MIB::hrStorageDescr.31 = STRING: /
   HOST-RESOURCES-MIB::hrStorageDescr.36 = STRING: /var
   

2. Read a single storage name once you know the index:

   snmpget -v2c -c public 10.0.0.5 1.3.6.1.2.1.25.2.3.1.3.31
   

3. Join it to a usage figure for the matching index to confirm the pairing:

   snmpget -v2c -c public 10.0.0.5 1.3.6.1.2.1.25.2.3.1.6.31
   

The workflow is always: walk names, pick the index whose description matches the mount you care about, then read capacity and used space at that same index. An empty walk means the subtree isn't in the agent's view — fix it via the OID allowlist. A hang points at community, port, or firewall instead.

Normal vs alarming values & thresholds

The storage names OID returns text, so you don't threshold it against a number — you compare it against what you expect the inventory to be. Baseline the description set once, then alert on drift. Watch for:

• A missing description — an expected mount that's gone from the walk almost always failed to mount. That's the loudest signal here; a data volume that silently isn't there breaks writes without any usage alert firing.
• A new, unexpected entry — a storage area you didn't provision (a stray RAM disk, an accidentally attached device) is worth a look.
• A changed index for a known name — when /var moves from index 36 to 34 after a reboot, any threshold hard-coded to 36 is now watching the wrong area. Re-map on change.
• Renamed or relabelled volumes — a description that changed wording can indicate a filesystem was recreated or remounted differently.

The healthy state is a stable, complete inventory that matches your provisioning. Any addition, disappearance, or index shuffle is the exception worth a notification, because it means a downstream metric may now be measuring the wrong thing.

Alerting on this metric externally

Here's the failure that makes external checks matter: the storage area that disappears from the inventory might be the one your local monitoring lives on. A data mount fails, the checker that ran from it can't start, and the "missing volume" alert never fires — because the tool meant to send it went down with the mount.

Polling the storage names OID from outside the box sidesteps that entirely. This is the reasoning behind double durability: an independent watcher walks hrStorageDescr from beyond your network, compares the returned inventory against the known baseline, and flags a vanished mount even when the host is in no state to report it. SNMP is pull-based, so the external side reads 1.3.6.1.2.1.25.2.3.1.3 on its own schedule and does the comparison on its own hardware.

ostr.io Monitoring provides that as a zero-setup service — it polls your storage table independently and fires real-time email and SMS alerts when the inventory drifts from normal, so a mount that quietly dropped off still reaches you even when the server can't say so itself.