SNMP RAID Monitoring
A RAID array is designed to survive a dead disk without telling anyone. That's the feature, and it's also the danger. SNMP RAID monitoring exists so you find out about the failed drive, because your users won't — the array just keeps serving data quietly on reduced redundancy until a second disk goes and takes everything with it. Poll the controller over SNMP and you can read the health of each physical disk, the state of every virtual volume, and whether a rebuild is underway. This page explains what to watch, why the reading lives in a vendor MIB, how to find the right OID, and how to make sure the alert leaves the building.
What is RAID monitoring
RAID — a redundant array of independent disks — stitches several physical drives into one logical volume so that losing a disk doesn't lose your data. Depending on the level, the array can tolerate one or more drive failures and rebuild onto a spare. Monitoring it means continuously reading the states the controller tracks: the status of each physical disk (online, failed, predictive-failure, rebuilding), the status of each logical volume or virtual disk (optimal, degraded, offline), the controller's own health, and the progress of any rebuild in flight.
The reason this matters so much is the silence. When a disk in a well-configured array dies, applications keep running. There's no error to the user, no crash, often nothing in the foreground at all — the whole point of redundancy is that the failure is invisible. The array is now degraded, running without its safety margin, and it stays that way indefinitely unless someone notices. If a second drive fails before the first is replaced and rebuilt, the volume goes offline and the data is gone.
Monitor raid snmp status on a schedule and that silent failure becomes a loud one. You learn about the degraded array the moment it happens, swap the disk, and let it rebuild while the redundancy still means something. Because this is about the health of storage hardware rather than the operating system's own view of a filesystem, it belongs with the other environmental sensors — hardware-condition telemetry, not OS metrics.
Why it's not in the standard host-resources MIB
The Host Resources MIB (RFC 2790) can tell you how full a storage volume is — hrStorageUsed and friends report capacity and usage. What it cannot tell you is whether that volume is riding on a degraded array with a dead disk in it. Redundancy state is a property of the RAID controller, a layer beneath the filesystem, and the host-resources tree simply doesn't model it. A disk can fail and hrStorageUsed won't budge, because from the OS's perspective the logical volume is still there and still the same size.
That's why RAID health is an advanced, vendor-specific sensor. The controller — a Broadcom/LSI MegaRAID card, a Dell PERC, an HPE Smart Array, or similar — exposes its state through its manufacturer's management agent and MIB, under the enterprise subtree 1.3.6.1.4.1.<vendor>. There's no single standard raidVolumeStatus OID that answers across every controller, so you work from the vendor's MIB.
Two practical routes exist. Many server vendors ship a management agent (Dell OpenManage, HPE's Insight agents, MegaRAID's SNMP subagent) that plugs into the host's SNMP daemon and publishes controller status under the vendor tree. Alternatively, when no such agent is available, you can wrap the controller's own command-line tool in a small script and surface its output as a custom OID through the SNMP agent's script-extension mechanism — turning "one disk failed" into a pollable value. Either way, the exact OID or object comes from the vendor's MIB or your own script, never from a guess.
Finding the right vendor OID
Read the MIB, then confirm against the running controller — the routine that works for every non-standard device. Install the vendor's management agent and MIB, load the MIB into snmptranslate or a browser, and read the object names so you can tell physical-drive status from virtual-disk status.
Then walk the host's enterprise subtree and find the array objects:
snmpwalk -v2c -c public 10.0.0.10 1.3.6.1.4.1
Look for the controller's branch and the status columns within it. A good sanity check: match the reported states against what the controller's own CLI tool says right now, so you know which OID means "this disk is healthy" versus "this volume is degraded." The table below orients you among the common controllers; the precise numeric OID is always whatever that vendor's MIB defines.
| Source | MIB / agent | What it exposes | Where the exact OID comes from |
|---|---|---|---|
| Broadcom / LSI MegaRAID | MegaRAID SAS MIB (SNMP subagent) | Physical drive + virtual drive status, rebuild state | Vendor MIB |
| Dell PERC | Dell OpenManage (OMSA) MIB | Controller, array, and disk status | Vendor MIB |
| HPE Smart Array | HPE Insight agents MIB | Logical/physical drive status | Vendor MIB |
| Generic / any controller | Wrap the controller CLI as a custom OID | Any status the CLI reports | Your script + SNMP agent extension |
Verify every OID against live controller state before trusting it. A status value you can't correlate to a real disk is a status value you'll misread during an incident.
Setting it up as a custom OID
Wiring RAID status in follows the general custom OID approach, adapted for a controller:
- Install the vendor management agent (or prepare a script that parses the controller CLI) so the RAID state is exposed through SNMP.
- Discover the status OIDs with the
snmpwalksweep above, and map each to a physical disk, a virtual volume, and the controller. - Add those OIDs to the allowlist so the agent will actually serve them — the OID allowlist guide shows the
view ... includedline, and the snmpd.conf reference covers the full configuration. - Poll on a schedule and record the states, so a transition into "degraded" is captured the moment it occurs.
- Alert on any non-optimal state — a failed disk, a degraded volume, or a predictive-failure warning.
Since RAID status is served through the host's SNMP daemon via the vendor agent, you poll the server itself here — unlike a PDU or UPS, the controller lives inside the machine.
Alerting
Signals worth alerting on:
- A physical disk reporting anything other than OK/online.
- The array leaving its optimal state (degraded or rebuilding).
- A rebuild running far longer than expected, or restarting.
- Hot-spare count dropping to zero.
RAID alerting isn't about thresholds on a number; it's about state. The trigger you cannot afford to miss is any transition away from "optimal" — a physical disk reporting failed or predictive-failure, or a virtual volume dropping to degraded. Those are binary, urgent, and time-sensitive, because a degraded array is a countdown to the next failure. Rebuild progress is worth watching too, since an array is at its most vulnerable while rebuilding.
Here's the trap with on-host alerting: the machine whose array just went degraded is the machine you're depending on to tell you. If that server is struggling — or if the degradation is the first sign of a bigger hardware problem — the local notifier may not get its message out. Polling from outside the server removes that dependency, which is the double durability idea: an independent external checker keeps reading the controller's state even when the host is in a bad way. ostr.io Monitoring polls your SNMP endpoints from outside your infrastructure and sends real-time email and SMS alerts, so a degraded array reaches you while there's still a healthy disk to save it.
