SNMP Disk Space Monitoring

A full disk is one of those failures that arrives quietly and then breaks everything at once. Databases refuse writes, logs stop rotating, sessions can't be saved, and the box that was fine at midnight is throwing 500s by dawn. SNMP disk space monitoring is the cheapest insurance against that, and this page is the practical one: how to monitor disk usage over SNMP, the exact OID that reports space consumed, how to turn raw allocation units into gigabytes, and how to wire up a low disk space alert that reaches you before the volume actually fills. No agent to install, no scripts on the host — just the SNMP daemon your server almost certainly already runs.

What is Disk Space and why monitor it

Disk space usage is simply how much of a storage area is occupied versus how much it can hold. On a Linux or Windows server that "storage area" isn't only the root filesystem — it's every mounted volume, and under the Host Resources MIB it also includes RAM and swap, because they're modelled the same way. For this page we care about the filesystems: /, /var, /home, a data mount, whatever your machine exposes.

Why watch it so closely? Because running out of space doesn't degrade gracefully the way a busy CPU does. A processor at 95% is slow; a filesystem at 100% is broken. The symptoms are ugly and varied. PostgreSQL and MySQL will halt writes to protect integrity. Application logs that can't append will crash the process that owns them. Package updates fail halfway. Temp files vanish and builds break. And the classic trap: /var/log quietly balloons from a runaway debug setting until the partition it lives on is wedged, even though the main data volume looks perfectly healthy.

That's the operational case for monitoring disk usage over SNMP. You don't want to discover a low-space condition from an angry user — you want a low disk space alert while there's still room to intervene, delete, or grow the volume. Watching each mount continuously, on a fixed cadence, is how you convert a 3 a.m. outage into a boring afternoon cleanup.

The OID: 1.3.6.1.2.1.25.2.3.1.6

The value that reports space consumed is 1.3.6.1.2.1.25.2.3.1.6, named hrStorageUsed in the Host Resources MIB (RFC 2790). Like the rest of the hrStorage table it's a column, not a scalar: the agent returns one row per storage area, each keyed by an hrStorageIndex. The number it hands back is not bytes. It's the amount used expressed in allocation units — the filesystem's block size.

To get a real byte figure you multiply by the block size, which lives one column over in hrStorageAllocationUnits (1.3.6.1.2.1.25.2.3.1.4):

bytes used = hrStorageUsed × hrStorageAllocationUnits

And the number most people actually want — percent full — comes from dividing used by total size, hrStorageSize (1.3.6.1.2.1.25.2.3.1.5), which is covered on the storage capacity page:

% used = hrStorageUsed ÷ hrStorageSize × 100

Because both columns share the same allocation unit, the percentage math works directly on the raw values — the units cancel out, so you don't even need to convert to bytes first.

How to query it

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

1. Walk the used-space column across every storage area:

   snmpwalk -v2c -c public 10.0.0.5 1.3.6.1.2.1.25.2.3.1.6
   

   Sample output — one line per mount, in allocation units:

   HOST-RESOURCES-MIB::hrStorageUsed.1 = INTEGER: 210544
   HOST-RESOURCES-MIB::hrStorageUsed.31 = INTEGER: 8123769
   HOST-RESOURCES-MIB::hrStorageUsed.36 = INTEGER: 442015
   

2. Read one filesystem once you know its index (say / is index 31):

   snmpget -v2c -c public 10.0.0.5 1.3.6.1.2.1.25.2.3.1.6.31
   

3. Pull the block size so you can convert to bytes:

   snmpget -v2c -c public 10.0.0.5 1.3.6.1.2.1.25.2.3.1.4.31
   

Here's the step people skip: the numeric index on its own is meaningless. Index 31 is only "the root filesystem" because the matching hrStorageDescr row says so. Walk the names first — see storage inventory — and pin each index to a mount point before you build any threshold on it, because those indices can shift between reboots.

If a walk comes back empty, the OID almost certainly isn't published in the agent's view; add it to your OID allowlist. A request that hangs instead is a different fault — wrong community, wrong port, or a firewall — not the OID.

Normal vs alarming values & thresholds

Raw used-space alone tells you nothing; 8 million allocation units is fine on a big volume and catastrophic on a small one. Always judge hrStorageUsed as a percentage of hrStorageSize. These bands hold up well across most servers:

• 0–70% used — healthy. Normal working range with comfortable headroom for growth and temp files.
• 70–85% used — watch it. A good spot for a warning-level trigger, especially on volumes that grow steadily like /var or a database mount.
• 85–95% used — act now. Response times can suffer on nearly-full filesystems, and you're one big log or upload away from trouble. This is your primary low disk space alert threshold.
• 95–100% used — critical. Writes are about to fail or already are. Page someone.

Two habits keep a low disk space alert trustworthy rather than noisy. First, alert per volume, not per machine — a full /boot and a full data disk are wildly different emergencies, and an averaged, host-wide "disk" number hides the one that's about to break. Second, watch the rate of change alongside the level. A volume that jumps from 60% to 90% in an hour deserves attention even before it trips the absolute line, because the trend is what tells you how long you've got. For a deeper playbook, see the low disk space alerts guide.

Alerting on this metric externally

A local cron job that emails you when disk usage crosses a line has a fatal weakness: it lives on the disk it's watching. Fill the volume that holds its logs, its temp files, or its mail spool, and the very thing meant to warn you can't run. The failure mode and the alarm share fate.

Polling from outside the server removes that dependency entirely. This is the idea behind double durability: an independent watcher keeps reading hrStorageUsed from beyond your network, so a nearly-full — or already crashed — machine still trips an alert. SNMP is a pull protocol, so the external side simply polls 1.3.6.1.2.1.25.2.3.1.6 on its own schedule and tests the threshold on its own hardware. The sick server doesn't have to lift a finger.

That's exactly what ostr.io Monitoring does. Monitor snmp disk space monitoring from outside your network with ostr.io — it polls the storage OIDs independently and fires real-time email and SMS alerts the moment a volume crosses your limit, so a filling disk reaches you even when the box is too stressed to send its own warning.