monitoring

SNMP Disk Space Monitoring: Free-Space Alerts How-To

Use hrStorageTable to compute free space and set low-disk alerts.

Monitor with ostr.io

By the SNMP Monitoring team · Reviewed July 2026

A full disk is an outage with extra paperwork. Databases stop writing, logs wedge, package upgrades fail mid-flight—and you find out when users already know. This page is the how-to: which storage OIDs, how to pick / or C:\, how to compute free %, how to alert before 100%, and how off-box checks help when the host is too sick to care.

OID encyclopedia twin: disk sensors. Parent: server monitoring.

Why disk-space monitoring matters

Failure modes that keep paying the rent for monitoring:

  • Log flood fills /var
  • Container image residue fills /
  • Backup target fills overnight
  • Database autogrowth eats the volume
  • “Temporary” dumps nobody deleted

Bulleted truth: capacity is slow until it isn't. Polling every few minutes is fine; discovering full only at login is not.

Which OIDs report storage

hrStorageTable base 1.3.6.1.2.1.25.2.3.1:

Column OID suffix Meaning
hrStorageDescr .3 Name / mount-ish label
hrStorageAllocationUnits .4 Bytes per unit
hrStorageSize .5 Size in units
hrStorageUsed .6 Used in units

Fixed disks use type hrStorageFixedDisk. Match hrStorageDescr to the mount you care about.

Bytes = value × hrStorageAllocationUnits.
Free = (size − used) × units.
% used = used ÷ size × 100.

Identify the right volume

Walk descr, find /, /var, C:\, data mounts—not the RAM row, not a floppy ghost from 1998.

snmpwalk -v2c -c <RO_string> <host> 1.3.6.1.2.1.25.2.3.1.3
HOST-RESOURCES-MIB::hrStorageDescr.1 = STRING: Physical memory
HOST-RESOURCES-MIB::hrStorageDescr.31 = STRING: /
HOST-RESOURCES-MIB::hrStorageDescr.35 = STRING: /var
HOST-RESOURCES-MIB::hrStorageDescr.36 = STRING: /data

Indexes 31 / 35 / 36 are examples—yours will differ. Pin by descr string in the NMS when you can, not by brittle index alone.

Reading it with snmpwalk

snmpwalk -v2c -c <RO_string> <host> 1.3.6.1.2.1.25.2.3.1
HOST-RESOURCES-MIB::hrStorageDescr.31 = STRING: /
HOST-RESOURCES-MIB::hrStorageAllocationUnits.31 = INTEGER: 4096 Bytes
HOST-RESOURCES-MIB::hrStorageSize.31 = INTEGER: 26214400
HOST-RESOURCES-MIB::hrStorageUsed.31 = INTEGER: 18350080

Tooling notes: snmpwalk.

snmpwalk output highlighting hrStorageSize and hrStorageUsed for a disk

Calculating free space and % free

Numbered:

  1. Pick the index for the mount.
  2. Read size, used, units.
  3. Used % = used / size × 100.
  4. Free bytes = (size − used) × units.
  5. Free % = 100 − used %.
  6. Convert to GB: free bytes / 1024³ (or 1000³—pick one and stick to it in the UI).

Worked example (units = 4096):

  • size = 26214400 → total bytes = 26214400 × 4096
  • used = 18350080
  • used % ≈ 70%
  • free units = 7864320 → free bytes = 7864320 × 4096

Free disk space percentage calculation from SNMP storage OIDs

Setting a low-disk alert threshold

Policy beats vibes:

  • % free thresholds (e.g. warn <15%, crit <5%) for multi-size fleets
  • Absolute GB free on huge data volumes where 5% is still terabytes—or where 5% is still too small
  • Duration — ignore a 2-minute spike from a temp extract
  • Separate volumes: / vs data vs backup target

Alert routing: alerts.

RAID / array & SMART context

SNMP free space ≠ healthy array. A volume can show free space while a disk is failed in the RAID pack. Pair capacity with RAID monitoring and RAID sensors when the platform exposes them. SMART often needs other tools; don't pretend hrStorage knows reallocated sectors.

Full OID reference

Leaf-level tables, types, more examples: disk OIDs. This page stays on procedure and alerts.

Get external low-disk alerts before it fills

When the box is thrashing, local pollers in the same blast radius may be late. External SNMPv2c monitoring can still read storage descr / size / used if the agent answers. ostr.io polls those storage fields among its supported metrics—use a tight allowlist and dual cadence for durability. Setup: ostr.io endpoint, model: external monitoring.

One product CTA; the math above works with any manager that can do arithmetic.

Rollout checklist

  1. Inventory mounts worth paging on
  2. Map each to hrStorageDescr
  3. Poll size/used/units
  4. Alert free % (and absolute where needed)
  5. Test by filling a lab volume safely
  6. Add external check for crowns jewels

Failure modes

  • Watching RAM row by mistake
  • Forgetting × units → GB wrong by orders of magnitude
  • Alert on total disk when only /var fills
  • No alert on inode exhaustion (SNMP may not show inodes—know the gap)

Glossary: glossary. Catalog: sensors/all.

Prioritizing which mounts to page on

Not every filesystem deserves a 2 a.m. call:

  • Always: /, OS volume, database data, queue/spool that blocks traffic
  • Usually: /var, log volume, container runtime disk
  • Sometimes: backup targets (alert early; full backup disk is a next-day problem if designed well)
  • Rarely: read-only media, tiny EFI partitions that never grow

Write the list into the template names (disk_root, disk_data) so on-call knows what broke without decoding indexes.

Growth alerts vs cliff alerts

% free cliffs catch “we're almost dead.” Trend alerts (“fills in <72h at current rate”) need more NMS smarts but save weekends. Even a dumb weekly review of the top ten fullest volumes beats discovering 99% in production. SNMP gives the samples; your process turns them into capacity planning.

Inodes and other gaps

hrStorage is about space units, not inode counts. A volume can show free bytes and still refuse creates when inodes are exhausted. Know that hole; cover it with OS checks or node_exporter-style metrics if you've been burned before. Honesty about gaps beats fake completeness.

Example alert text that helps

Bad: “Disk warning on host.”
Better: “/var on log-02 free 4.2% (12 GB) for 20m — hrStorage index 35.”

Include mount, host, free %, free GB, duration. On-call shouldn't open three tools to learn which volume. Your NMS macros can pull descr + computed free if you store the index mapping cleanly.

After a resize (LVM, cloud volume grow), re-walk size—stale max values make free % look miraculously healthy while the OS already grew. SNMP only knows what the agent reports now.

Frequently asked questions

What OID is disk usage in SNMP?

hrStorageUsed at 1.3.6.1.2.1.25.2.3.1.6 for the chosen index (with size .5 and units .4). See sensors/disk.

How do I get a free-disk-space alert?

Compute free % or free GB from size/used/units, alert when free drops below threshold for multiple polls. Wire notifications in your NMS (alerts).

How do I convert hrStorage values to GB?

Multiply size or free units by hrStorageAllocationUnits to get bytes, then divide by 1024³ (or 10^9—be consistent).

Which storage row is my disk?

Match hrStorageDescr to the mount path (and prefer fixed-disk type). Don't assume index numbers.

Key takeaways

  • Disk via hrStorageTable 1.3.6.1.2.1.25.2.3.1.
  • Free = (size − used) × units; pick row by descr.
  • Alert on sustained low free %, per volume.
  • Capacity ≠ RAID health—pair sensors.
  • Reference: sensors/disk; external option: ostr.io.

Monitor it from outside the network

SNMP only tells you a box is healthy while something is still asking. ostr.io polls your endpoints externally and fires email + SMS alerts the moment a reading crosses your line — or the agent goes silent.