By the SNMP Monitoring team · Reviewed July 2026
There is no standard "RAID status OID." Unlike CPU, interfaces, or even UPS, RAID health has no MIB-II home — it lives entirely in the controller vendor's enterprise MIB. So the question "what's the OID for RAID?" always has the same shape of answer: which controller do you have? This page is the paste-ready reference for the three controller families you'll actually meet — LSI/Broadcom MegaRAID, Dell PERC (via OpenManage), HPE Smart Array — and the objects to read once you know your controller.
The "how do I alert on a degraded array" side is the twin: monitor RAID. Hubs: sensors, all OIDs.
Controller MIB map
RAID objects sit under each vendor's enterprise arc 1.3.6.1.4.1:
| Controller family | MIB / agent | Where it lives |
|---|---|---|
| LSI / Broadcom MegaRAID | MegaRAID SNMP agent | Enterprise MIB under 1.3.6.1.4.1 |
| Dell PERC | OpenManage (OMSA) | Dell enterprise MIB under 1.3.6.1.4.1 |
| HPE Smart Array | cpqida (HP Insight) | HPE enterprise MIB under 1.3.6.1.4.1 |
Two of these are effectively the same silicon wearing different clothes — Dell PERC controllers are rebadged LSI/Broadcom — but you read them through Dell's OpenManage agent, not the MegaRAID one, so the OIDs differ. The exact leaf for "logical drive status" is controller-specific and must be verified against that vendor's MIB. This reference deliberately doesn't print a specific leaf, because a wrong RAID OID gives you a confidently green dashboard over a dying array. Platform notes: devices.
What to read
Whatever the controller, the same handful of objects carry the health story:
- Logical / virtual drive status — the array as a whole: optimal, degraded, offline, rebuilding. The top-line signal.
- Physical disk status — each member drive: online, failed, predictive-failure, rebuilding. Tells you which disk to swap.
- Rebuild progress — a percentage while an array reconstructs onto a replacement or hot spare; the array is at risk until it hits 100%.
- Hot-spare state — whether a standby disk is present and ready to auto-rebuild.
Alert hardest on logical-drive status; use physical-disk status to name the failed member in the alert.
Status enum interpretation
RAID status objects are enums, and here's the trap: the integer-to-meaning mapping is vendor-defined. One controller might use 2 = optimal, 3 = degraded; another uses entirely different numbers. So you can't read a raw 3 and assume "degraded" — you have to map it through the specific controller's MIB. The safe pattern:
- Load the controller's MIB so the enum resolves to a name, not a bare integer.
- Confirm which value means healthy (optimal/ok) for that controller.
- Alert on any state that isn't the healthy one, rather than hard-coding "alert if value == 3."
- Verify the mapping in a lab or against a known-good array before trusting it in production.
Hard-coding an enum number copied from another vendor is one of the most common ways a RAID check silently fails to fire.
There's a second, quieter prerequisite that catches people out: the controller subtree usually isn't answered by the host's stock SNMP agent at all. RAID objects are served by the vendor's management agent — Dell OpenManage Server Administrator, HPE's Insight agents, or the standalone MegaRAID SNMP agent — which has to be installed and registered with snmpd before the enterprise subtree appears. So a walk that returns nothing on a machine you know has a RAID controller almost always means a missing or stopped management agent, not a healthy array with no alarms. That failure mode is dangerous precisely because "no data" and "all optimal" look the same to a naive check: a monitoring system that only alerts on a degraded value will stay silent when the agent is gone and the array is quietly dying. The defensive move is to verify the subtree actually responds — treat an empty walk as its own alertable condition — before you trust "no RAID alerts" to mean "RAID is fine."
Worked snmpwalk example
Walk the controller's RAID subtree (the arc and names below show the pattern — read your MIB):
snmpwalk -v2c -c <RO_string> <host> <controller-raid-subtree>
...logicalDriveStatus.0 = INTEGER: degraded(3)
...logicalDriveStatus.1 = INTEGER: optimal(2)
...physicalDriveStatus.0.2 = INTEGER: failed(4)
...rebuildProgress.0 = INTEGER: 0
Logical drive 0 is degraded, physical disk 2 in it shows failed, and rebuild is at 0 (likely no hot spare). Logical drive 1 is optimal. The enum values here are illustrative — map them from your controller's MIB. <RO_string> and <controller-raid-subtree> are placeholders; substitute your controller's real objects.
Standard vs vendor
It's worth being clear on why HOST-RESOURCES doesn't help here. Its hrStorageTable reports the array's capacity and usage — how full the volume is — but says nothing about redundancy. A degraded array running on one surviving disk looks identical in HOST-RESOURCES to a healthy one: same size, same used, same free. So disk-space monitoring and RAID-health monitoring are genuinely different jobs on the same hardware. For the capacity side, see disk OIDs; this page is the health side, which only the controller MIB exposes.
How to monitor RAID (how-to)
Reference stops here. The alerting logic — treating degraded as urgent, keeping the incident open through rebuild, the management-agent requirement — is the twin: monitor RAID via SNMP. Related: disk OIDs, devices, the OID catalog, and glossary.
Frequently asked questions
Is there a standard RAID OID?
No. RAID health has no standard MIB — it lives entirely in controller-specific enterprise MIBs under 1.3.6.1.4.1. So there's no universal "RAID status OID"; you identify your controller (MegaRAID, Dell PERC, HPE Smart Array) and read its objects, mapping the status enums through that vendor's MIB.
What MIB do MegaRAID, PERC and Smart Array use?
LSI/Broadcom MegaRAID uses the MegaRAID SNMP agent's enterprise MIB; Dell PERC is read through OpenManage (OMSA); HPE Smart Array is exposed by the cpqida objects in HP Insight — all under 1.3.6.1.4.1. Note the host usually needs the vendor's management agent installed for the controller subtree to appear.
What OID is logical drive status?
It's controller-specific — the logical/virtual drive status object lives in your controller vendor's enterprise MIB, and the enum values are defined there too. Verify the exact OID and the meaning of each enum value against that MIB rather than assuming a leaf or number carries across controllers.
Does HOST-RESOURCES-MIB show RAID health?
No. HOST-RESOURCES hrStorageTable reports capacity and usage but not redundancy — a degraded array looks identical to a healthy one there. RAID health comes only from the controller's enterprise MIB, which is why RAID and disk-space monitoring are separate jobs.
Key takeaways
- RAID health has no standard MIB — it's in the controller's enterprise tree under
1.3.6.1.4.1. - Three families: MegaRAID (LSI agent), Dell PERC (OpenManage), HPE Smart Array (cpqida).
- Read logical-drive status (alert hardest), physical-disk status, rebuild %, hot-spare state.
- Status enums are vendor-defined — map through the MIB; never hard-code a copied integer.
- HOST-RESOURCES shows capacity, not health — see disk OIDs.
- Verify every vendor RAID OID against its MIB; procedure: RAID how-to.