---
type: Article
title: "SNMP HDD & SSD Monitoring"
description: "Standard SNMP tells you how full a disk is, not whether the drive is dying. Which layer answers which question, and where SSD health needs a vendor MIB."
resource: "https://snmp-monitoring.com/sensors/storage/hdd-ssd/"
tags: [sensors, snmp]
timestamp: 2026-07-13T00:00:00Z
---

# 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.

![Diagram of external SNMP HDD monitoring: an outside poller reading hrStorage capacity and vendor health OIDs from a server's SNMP agent over UDP](https://snmp-monitoring.com/img/sensors/hdd-ssd-snmp-poll.webp)

## 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](/setup/snmpd-conf.md).

1. **Walk the storage names** to see which volumes exist:
   ```bash
   snmpwalk -v2c -c public 10.0.0.5 1.3.6.1.2.1.25.2.3.1.3
   ```
   Sample output:
   ```
   HOST-RESOURCES-MIB::hrStorageDescr.31 = STRING: /
   HOST-RESOURCES-MIB::hrStorageDescr.36 = STRING: /data
   ```
2. **Read used and total** for a chosen index to judge fill level:
   ```bash
   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
   ```
3. **Probe vendor health objects**, if your controller publishes them, using its MIB's OIDs:
   ```bash
   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](/setup/oid-allowlist.md). 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 `hrStorageUsed` against `hrStorageSize` — the same math covered on the [disk space usage](/sensors/storage/disk-space-usage.md) 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](/monitoring/double-durability.md): 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](https://ostr.io/service/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.

![Chart comparing SNMP disk health signals for an HDD and an SSD, showing capacity fill and vendor wear-level trends over time](https://snmp-monitoring.com/img/sensors/hdd-ssd-health-chart.webp)


## FAQ

**Can SNMP read SMART data from my disks?**
Not through any standard OID. The Host Resources MIB only exposes logical capacity. SMART attributes, if available at all, come from a vendor or controller MIB specific to your hardware — check that device's MIB rather than assuming a universal OID exists.

**How do I monitor SSD wear over SNMP?**
Only if your storage controller or NAS publishes a wear or endurance attribute in its vendor MIB. Base SNMP doesn't expose SSD wear, so identify your hardware's MIB, find the exact OID there, and poll it — don't substitute a guessed number.

**What can I reliably monitor about disks with standard SNMP?**
Capacity: which volumes exist (`hrStorageDescr`), how big they are (`hrStorageSize`), and how full (`hrStorageUsed`). That's portable across nearly every agent and is the backbone of SNMP HDD monitoring.

**Is there an OID for drive temperature?**
Sometimes, via the Entity Sensor MIB `entPhySensorValue` (`1.3.6.1.2.1.99.1.1.1.4`, RFC 3433) if the device exposes it, or a vendor MIB. There's no guarantee a given server publishes it — confirm against the hardware's MIB.

## Conclusion

Honest SNMP HDD monitoring means separating two questions. Capacity — how full each volume is — you can read anywhere, from the Host Resources MIB storage table (`hrStorageDescr`, `hrStorageSize`, `hrStorageUsed`). Deep disk health — SMART, SSD wear, RAID state — has no standard OID and lives in vendor or entity MIBs, so you monitor it where your hardware actually exposes it and never fabricate a value where it doesn't. Publish the storage subtree in your [snmpd.conf](/setup/snmpd-conf.md), keep it in your [OID allowlist](/setup/oid-allowlist.md), and browse the [full sensor catalog](/sensors/all.md) for the exact capacity OIDs. Poll it from outside the box, and even a dying disk still finds a way to warn you.