SNMP HDD & SSD Monitoring
There's an honest distinction at the heart of SNMP HDD monitoring that most guides gloss over: standard SNMP is very good at telling you how full a disk is, and much less good at telling you whether the drive itself is dying. Those are two different questions. This page draws the line clearly — what you can read about your HDDs and SSDs from the base standards every agent ships, what genuinely needs a vendor extension, and how to monitor SSD wear and disk health without pretending an OID exists when it doesn't. If you want honest, agentless disk monitoring, start by knowing which layer answers which question.
What is HDD & SSD and why monitor it
An HDD (a spinning hard disk) and an SSD (solid-state flash) are the physical devices your data actually lives on. Above them sit the logical filesystems the operating system mounts. SNMP sees these two layers very differently, and that difference is the whole story of this page.
Why monitor them at all? Because storage fails in two distinct ways, and each has its own warning signs. The first is capacity — the volume fills up. The second is hardware health — the drive develops bad sectors, an SSD burns through its write endurance, a disk in an array drops out, latency climbs as a mechanical drive starts to fail. Capacity problems are loud and predictable. Health problems are sneakier: an SSD can report plenty of free space right up until its flash wears out, and a failing HDD can serve reads slowly for days before it gives up entirely.
The operational payoff of watching disk health is lead time. A drive rarely dies without dropping hints — reallocated sectors, rising error counts, a RAID member flagged as degraded. Catch those early and you replace hardware on a maintenance window. Miss them and you're restoring from backup at 2 a.m. The catch, and the reason this page exists, is that base SNMP standards expose the capacity story cleanly but leave most of the deep health story to vendor-specific extensions.
The OID: no single standard OID for disk health
Here's the part that trips people up, stated plainly: there is no single standard SNMP OID for physical disk health or SMART data. The Host Resources MIB (RFC 2790) models logical storage — mounted filesystems, RAM, swap — not the physical condition of a spinning platter or a flash chip. So when you monitor HDDs and SSDs over base SNMP, what you're really reading is the storage table's capacity view of each mounted volume.
Those OIDs are real and they're the right starting point:
| Metric | OID | Object / MIB | What it tells you |
|---|---|---|---|
| Storage name | 1.3.6.1.2.1.25.2.3.1.3 | hrStorageDescr (Host Resources MIB, RFC 2790) | Which mount / device |
| Total capacity | 1.3.6.1.2.1.25.2.3.1.5 | hrStorageSize (RFC 2790) | Size in allocation units |
| Used space | 1.3.6.1.2.1.25.2.3.1.6 | hrStorageUsed (RFC 2790) | Space consumed |
| Physical sensor value | 1.3.6.1.2.1.99.1.1.1.4 | entPhySensorValue (Entity Sensor MIB, RFC 3433) | Generic physical readings, where exposed |
| SMART / wear / RAID state | vendor-specific | consult the device or controller MIB | Deep health — no standard OID |
For genuine disk health — SMART attributes, SSD wear level, RAID member status, drive temperature — you go to a vendor or entity MIB. The ENTITY-SENSOR-MIB (entPhySensorValue, 1.3.6.1.2.1.99.1.1.1.4, RFC 3433) provides a standard shape for physical sensor readings where a device chooses to expose them, but the specific SMART and array-health objects live in vendor MIBs (RAID controllers, SAN arrays, NAS firmware). If you don't know the exact OID for your hardware, don't guess it — consult that device's MIB. Inventing a SMART OID is how monitoring lies to you.
How to query it
For the capacity side of SNMP HDD monitoring, any Net-SNMP client works against an SNMPv2c agent with a read-only community. If the agent isn't configured, see the snmpd.conf guide.
- Walk the storage names to see which volumes exist:
Sample output:snmpwalk -v2c -c public 10.0.0.5 1.3.6.1.2.1.25.2.3.1.3HOST-RESOURCES-MIB::hrStorageDescr.31 = STRING: / HOST-RESOURCES-MIB::hrStorageDescr.36 = STRING: /data - Read used and total for a chosen index to judge fill level:
snmpget -v2c -c public 10.0.0.5 1.3.6.1.2.1.25.2.3.1.6.36 snmpget -v2c -c public 10.0.0.5 1.3.6.1.2.1.25.2.3.1.5.36 - Probe vendor health objects, if your controller publishes them, using its MIB's OIDs:
snmpwalk -v2c -c public 10.0.0.5 1.3.6.1.2.1.99.1.1.1.4
The first two steps are portable and will work on essentially any host. The third depends entirely on the hardware: a plain server with directly-attached disks may expose nothing under the Entity Sensor MIB, while a RAID controller or NAS often does. An empty walk on the capacity OIDs means the subtree isn't allowlisted — fix it via the OID allowlist. An empty walk on vendor OIDs usually just means that device doesn't publish them.
Normal vs alarming values & thresholds
Because base SNMP gives you capacity cleanly and health only through extensions, split your thresholds the same way:
- Capacity, per volume (portable): healthy below ~70% full; warn around 80–85%; treat 90%+ as critical. This uses
hrStorageUsedagainsthrStorageSize— the same math covered on the disk space usage page. - SSD wear (vendor-specific): where exposed, a wear-level or "percent life remaining" attribute is the one to watch. Alert well before it hits zero — SSDs degrade predictably, so treat falling endurance as a scheduled-replacement signal, not an emergency.
- HDD SMART indicators (vendor-specific): reallocated sectors, pending sectors, and rising read-error counts trending upward are the classic pre-failure tells. Any non-zero-and-growing value deserves a look.
- RAID member state (vendor-specific): a degraded array is a fix-today condition — you've lost your redundancy margin even if the volume still serves data.
The honest rule: alert on capacity everywhere, and alert on disk health wherever your hardware actually exposes it. Don't fabricate a health metric you can't read — monitor what's real, and note the gap where a device stays quiet about its own condition.
Alerting on this metric externally
A failing disk is precisely the scenario where on-host monitoring is least reliable. If the drive that's dying is the one holding your logs, your monitoring agent, or your mail spool, the local tool meant to warn you may already be crippled by the same fault it's supposed to report. The alarm and the failure share the same hardware.
Reading these OIDs from outside the box removes that coupling. This is the idea behind double durability: an independent checker keeps polling your storage OIDs from beyond the network, so a server with a degrading or full disk still trips an alert even when it's in no state to report on itself. SNMP is a pull protocol, so the external side just reads the capacity — and any exposed health — values on its own schedule, on its own hardware.
ostr.io Monitoring does exactly this as a zero-setup, agentless service from the monitoring side: it polls your disk OIDs externally and sends real-time email and SMS alerts the moment a volume fills or a watched value drifts — so a dying disk reaches you even when the box can't reach out itself.
