How to Monitor RAID Array Status via SNMP

By the SNMP Monitoring team · Reviewed July 2026

A degraded RAID array is a countdown timer nobody started on purpose. One disk fails, the array keeps serving data off the survivors, and everything looks normal — until a second disk goes during the rebuild and the whole volume is gone. The window between "first disk failed" and "you're one failure from data loss" can be days, and it's completely silent unless something is watching the controller. That something can be SNMP. The catch: unlike CPU or interfaces, RAID health has no standard MIB. It lives entirely in the controller vendor's own tree, so the work is knowing which controller you have and which of its objects to poll.

This is the how-to. The object catalog lives on the reference twin, RAID sensor OIDs. Parent: hardware monitoring.

Why standard MIBs aren't enough for RAID

The instinct is to reach for HOST-RESOURCES-MIB, since it already reports storage. That's a dead end for RAID health. Here's the distinction:

• HOST-RESOURCES hrStorageTable shows the array's capacity and usage — how full the volume is.
• It says nothing about redundancy — a degraded array running on one disk looks identical to a healthy one, because the volume is still there and still the same size.
• RAID health — array state, member-disk state, rebuild progress — lives only in the controller's enterprise MIB under 1.3.6.1.4.1.

So disk-space monitoring and RAID-health monitoring are two different jobs pointed at the same hardware. For the capacity side, see disk-space monitoring; this page is about the health side, which HOST-RESOURCES simply doesn't expose.

Controller MIBs by vendor

RAID status is published by controller-specific enterprise MIBs. The three you'll meet most:

Verify the exact OID against that vendor's MIB before you build on it — these subtrees differ, and a wrong leaf gives you a confidently green dashboard over a degraded array. The device pages carry the platform-specific object notes.

One practical wrinkle: the controller MIB usually isn't answered by the host's default SNMP agent out of the box. You often have to install and register the vendor's management agent — Dell OpenManage Server Administrator, HPE's agents, or the MegaRAID SNMP agent — so the controller subtree actually shows up under the host's SNMP daemon. If a walk of the vendor subtree returns nothing on a machine that definitely has a RAID controller, a missing management agent is the usual reason, not a healthy-but-silent array. Confirm the agent is present and the subtree responds before you trust "no alerts" to mean "all optimal."

Key objects to watch

Whatever the controller, the same four questions matter:

• Logical / virtual drive status — the array as a whole: optimal, degraded, offline, or rebuilding. This is the top-line health signal.
• Physical disk status — each member drive: online, failed, predictive-failure, or rebuilding. Tells you which disk to swap.
• Rebuild progress — a percentage while the array reconstructs onto a replacement or hot spare. The array is vulnerable until it hits 100%.
• Hot spare state — whether a standby disk is present and healthy, ready to auto-rebuild.

The logical-drive status is the one to alert on hardest; the physical-disk status is what you hand the person walking to the rack with a replacement.

Reading RAID status with snmpwalk

Point the walk at your controller's subtree (the vendor MIB — the example below shows the shape of the output, not a universal OID):

snmpwalk -v2c -c <RO_string> <host> <controller-raid-subtree>

...ldStatus.0 = INTEGER: degraded(3)
...ldStatus.1 = INTEGER: optimal(2)
...pdStatus.0.2 = INTEGER: failed(4)
...rebuildRate.0 = INTEGER: 0

Logical drive 0 is degraded, and physical disk 2 within it shows failed — that's your bad member, and rebuild hasn't started (rate 0), likely because there's no hot spare. Logical drive 1 is optimal. The enum values (what integer means "degraded") are defined by the vendor MIB, so map them from that MIB, don't guess. <RO_string> and <controller-raid-subtree> are placeholders — substitute your controller's real objects.

Alerting on degraded/rebuild

The alert logic that keeps you ahead of the countdown:

1. Poll the logical-drive status enum on every array.
2. Alert immediately on any state that isn't optimal/healthy — degraded means you've already lost redundancy.
3. Poll physical-disk status to name the failed member in the alert, so the fix is a swap, not an investigation.
4. Track rebuild progress; keep the incident open — the array is still at risk — until it reaches 100% and the logical drive returns to optimal.
5. Alert separately if a hot spare is missing or failed, since without one a degraded array can't self-heal.

Degraded is not a "look at it tomorrow" state — it's "you are now one disk from data loss." Treat it with real urgency and route it accordingly; see alerts.

Reference & disk space

This is the RAID-health how-to. For controller object detail and enum tables, use the reference twin: RAID sensor OIDs. For the capacity side of the same arrays, see disk-space monitoring. Vendor object specifics: devices. Definitions at glossary; full index at all sensors.

Frequently asked questions

Can SNMP monitor RAID status?

Yes, but only through the RAID controller's vendor-specific enterprise MIB — MegaRAID, Dell PERC/OpenManage, HP Smart Array and similar, all under 1.3.6.1.4.1. The standard MIBs don't carry array health, so you poll the controller's logical-drive and physical-disk status objects.

What OID is RAID status?

There isn't a universal one — RAID status is controller-specific. The logical/virtual drive status and physical-disk status live in your controller vendor's enterprise MIB, and the enum values are defined there too. Verify the exact OID against that vendor's MIB rather than assuming one applies across controllers.

How do I alert on a degraded array?

Poll the logical-drive status enum and alert immediately on any non-optimal state, because degraded means redundancy is already lost. Include the physical-disk status so the alert names the failed member, and keep the incident open through rebuild until the drive returns to optimal.

Does HOST-RESOURCES-MIB show RAID health?

No. HOST-RESOURCES hrStorageTable reports the array's capacity and usage but not its redundancy state — a degraded array looks identical to a healthy one there. RAID health comes only from the controller's enterprise MIB.

Key takeaways

• RAID health has no standard MIB — it lives in the controller's enterprise tree under 1.3.6.1.4.1.
• HOST-RESOURCES shows capacity, not redundancy; a degraded array looks healthy there.
• Watch logical-drive status (alert hardest), physical-disk status, rebuild %, and hot-spare state.
• Degraded = one disk from data loss — alert immediately, keep the incident open through rebuild.
• Verify vendor OIDs and enum values against the controller MIB (MegaRAID, PERC, Smart Array) before trusting them.
• Object catalog: RAID sensors; an off-box external check via external monitoring still pages you if the host itself drops.