Storage Monitoring Tools and the KPIs Behind Each Failure Domain

When an application slows down, how long does it take to confirm whether storage caused it? The answer depends entirely on whether anything is collecting from the array itself. The server dashboard reports healthy CPU and memory, the network graphs look clean, and the array holding the data says nothing at all.

Storage failures announce themselves late. A pool fills gradually, a controller degrades under sustained load, a replication link stalls quietly, and the first visible symptom arrives as a user complaint about a slow report. Diagnosis then starts from the wrong end of the stack and works backwards.

Organizing storage observability around failure domains fixes that ordering problem. Failure domains give you a set of questions about what can break, each with the specific metrics that answer it. Every layer of IT storage degrades in its own way, and each way has its own signals.

In this blog, you will see the seven storage failure domains, the KPIs that expose each one, how SAN and NAS coverage differ, and a checklist for confirming hardware support before you commit.

What are Storage Monitoring Tools?

Storage monitoring tools collect health, capacity, and performance metrics directly from storage systems and turn them into alerts, dashboards, and historical trends. They talk to the array's own management interface instead of a server's view of a mounted disk, which is what lets them report controller state, pool utilization, drive health, and fabric port behavior.

The category covers several kinds of target:

• Block arrays: SAN systems presenting LUNs and volumes to hosts over Fibre Channel or iSCSI

• File systems: NAS platforms serving shares over NFS and SMB

• Backup and dedupe appliances: Purpose-built systems whose capacity and job health need separate visibility

• Cloud volumes and object stores: Managed storage services reporting through provider APIs

Coverage depth separates one product from another, the same way it decides any infrastructure monitoring purchase. Reporting that a disk is present is a low bar. Reporting its media type, endurance, queue length, and read latency is where the operational value starts.

Why do Storage Problems Reach Users Before They Reach a Dashboard?

Storage problems reach users first because most infrastructure monitoring watches the host, and the host is a poor witness. A virtual machine reports its own disk queue and filesystem usage, and both look normal while the array underneath serves that workload from a pool at 94% capacity or a controller that has failed over to a single node.

The consequences are measurable. Uptime Institute's 2026 outage analysis found that 57% of respondents put the cost of their most recent major outage above $100,000. One in five put it above $1 million.

Three specific blind spots recur:

1. Aggregation hides the hotspot: Array-wide utilization of 70% tells you nothing about the single pool at 98%

2. Thin provisioning breaks the arithmetic: Provisioned capacity can exceed physical capacity by a wide margin, so host-side free space is not a supply signal

3. Hardware degrades before it fails: A dead fan or a battery module out of warranty changes nothing users can see until the day it does

That gap is why storage belongs in the same operational picture as servers and network devices, alongside the other contributors to data center outages.

What are the Seven Storage Failure Domains?

The seven storage failure domains are the distinct ways a storage system stops serving data correctly, each with its own metrics and its own investigation path. Organizing observability this way keeps the question in front of you operational instead of architectural.

1. Capacity exhaustion

2. Latency and throughput degradation

3. Controller and node health

4. Disk and enclosure state

5. Connectivity and path failure

6. Replication and data protection

7. Collection path failure

Each domain gets its own section below.

Failure Domain 1: How do you Catch Storage Capacity Exhaustion Early?

Capacity exhaustion is caught early by tracking the pool alongside the volume, and by tracking the rate of change alongside the current number. A volume at 60% inside a pool at 97% is a problem, and only the pool metric shows it.

The metrics that matter at each level:

• Pool or provisioning group: Used bytes, free bytes, used percent, raw used percent, and the count of degraded or failed volumes inside the group

• Volume: Size, reserved bytes, used bytes, provisioning type, and the allocation warning and limit percentages the array already enforces

• Snapshot space: Reserved, used, and free bytes held separately from user space, since snapshot growth consumes capacity writes expect to find

Thin provisioning is where most capacity incidents originate. The array presents more capacity than it physically holds, so the moment that matters arrives when consumption catches up with supply, long after hosts stopped reporting anything unusual.

Rate of change converts a number into a decision. Free capacity divided by weekly growth gives you a date, and that date drives procurement alongside broader capacity planning.

Failure Domain 2: Which Metrics Expose Storage Latency and Throughput Problems?

Latency and throughput problems are exposed by reading four metrics together at the volume and LUN level: latency in milliseconds, IOPS, throughput in bytes per second, and queue length. Any one of them read alone will mislead you.

Read them as a set:

• Latency rising while IOPS stays flat: The array is working harder for the same demand, which points at contention or a degraded component

• Latency rising while IOPS rises: Demand grew, so the question becomes whether the array is at its designed ceiling

• Queue length climbing: Requests are waiting, which usually precedes the latency the application will report

• Busy percent near saturation: The volume, port, or provisioning group has no headroom left to absorb a spike

Split read and write wherever the array exposes both. Write latency degrades first on systems under cache pressure, and an averaged figure conceals that entirely.

Effective storage performance monitoring depends on baselines more than universal thresholds. A batch workload tolerating 20 ms and a transactional database needing single-digit milliseconds cannot share an alert rule, so baseline each volume against its own history and alert on deviation.

When latency has no workload explanation, the next place to look is the layer serving it.

Failure Domain 3: The Storage Controller and Node Health Signals Worth Watching

Storage controller and node health signals tell you whether the array still has the redundancy its design assumes. Most arrays keep running after a controller fault, which is exactly why the event passes unnoticed until the second one arrives.

Watch these:

• Node CPU: User percent, system percent, and idle percent per node, with an eye on imbalance between nodes more than absolute load

• Cache behavior: Read and write cache hit percentages, and the corresponding miss counts, since a sudden hit-rate drop often explains a latency shift with no change in workload

• Node memory: Free and clean page counts, showing whether the controller has working memory available

• Failover state: Whether the system currently runs on all nodes or has consolidated onto fewer

Imbalance is the signal people miss. When one node carries far more load than its partner, the array is either mid-failover or holding a path configuration that will hurt during maintenance.

Controller redundancy has a physical counterpart one level down, inside the chassis.

Failure Domain 4: How do you Monitor Disk and Enclosure State?

Disk and enclosure state is monitored through two separate layers, and most storage monitoring tools cover only the first. Drive-level metrics come from the array's own inventory. Enclosure hardware health comes from the physical chassis, and it needs its own collection.

At drive level, track state, media type, capacity and used bytes, per-disk read and write latency, IOPS, and queue length. Endurance matters on all-flash and NVMe systems, where write wear is a finite budget, and it deserves a trend line instead of a threshold.

At enclosure level, the components that fail are unglamorous and consequential:

1. Power supply units

2. Fans

3. Drive cages

4. Temperature sensors

5. I/O modules

6. Controller nodes

7. Battery modules

ObserveOps ships an out-of-the-box metric plugin in the Plugin Library that collects those seven component statuses from HPE 3PAR, HPE Alletra, and HPE Primera systems. The plugin attaches to an existing HPE storage monitor, so hardware health arrives alongside the performance metrics already collected.

Battery modules deserve specific mention. A depleted cache battery changes write behavior on many arrays, and the resulting shift looks like a workload problem until somebody checks the chassis. Component-level health also feeds the reliability picture that MTBF tracking depends on.

Hardware in good order still delivers nothing when the paths to it disappear.

Failure Domain 5: What Should Storage Connectivity and Path Monitoring Cover?

Connectivity and path monitoring should cover the array's own ports, the paths each host holds, and the fabric those paths run across. A host with four paths that quietly drops to one keeps working normally right up to the moment it stops.

Take a database server with four paths across two fabrics. A switch firmware update removes two of them, throughput holds steady, and nobody investigates until a later update takes a third.

Port-level metrics worth collecting:

• State and configuration: Link state, port mode, port type such as FC or iSCSI, protocol, configured rate, and maximum rate

• Identity: Port WWN and node WWN, which are what let you match an array port to the host that depends on it

• Load: Read and write IOPS, throughput, latency, queue length, and busy percent per port

Host-side, iSCSI path counts and host set membership are the two figures that reveal a redundancy loss. On Fibre Channel deployments, the array's view of the connected switch gives you the fabric context a storage area network needs for path troubleshooting.

This is also where san management and monitoring separate. Management covers zoning, masking, and provisioning changes. Monitoring reports what those configurations are currently doing, which is the part that has to run continuously.

Paths carry production traffic, and replication carries the ability to recover once that traffic stops.

Failure Domain 6: How do you Verify Storage Replication is Working?

Replication is verified by checking that the relationship reports a healthy state and that it is still advancing, since a stalled replica reports success on its last completed cycle indefinitely. The status field alone is a weak signal.

What to collect:

• Relationship state: Whether each replication pair reports healthy, degraded, or errored

• Progress: Whether the replica has advanced since the last poll, which is what distinguishes a stalled link from a quiet one

• Errors: Replication error counts and the events behind them

ObserveOps collects replication status from HPE Alletra systems and SyncIQ replication status from Dell Isilon NL410 clusters. Backup appliance capacity and health belong in the same domain, since a full appliance ends protection as effectively as a broken link, which is also true of network backup infrastructure generally.

Every domain above assumes one thing, which is that the metrics are still arriving.

Failure Domain 7: What Happens When the Metric Collection Path Fails?

Collection path failure is the domain where monitoring stops reporting while every dashboard stays green, and it is the one most tools ignore. A silent monitor and a healthy array produce identical screens.

The usual causes:

• Credential expiry: A rotated password or an expired API token ends collection without changing device availability

• Interface changes: A firmware upgrade alters the management API the collector depends on

• Reachability: A firewall rule change blocks the management port while leaving data paths untouched

• Provisioning gaps: A new array is racked, cabled, and serving production before anyone adds it to a discovery profile

The defense is to alert on metric absence as well as metric values. In ObserveOps, storage systems are onboarded through a Storage Discovery Profile paired with a credential profile, and a monitor that goes quiet while remaining reachable is the condition worth watching. This is the practical core of storage resource monitoring.

Credential and protocol requirements vary by vendor and by model, and they are worth confirming during evaluation rather than after purchase.

How do SAN and NAS Monitoring Requirements Differ?

SAN and NAS monitoring differ because the two architectures fail in different places. SAN monitoring follows block paths, LUNs, and fabric ports. NAS monitoring follows file protocols, shares, and cluster nodes.

Protocol split is the practical difference. A network attached storage cluster can show acceptable aggregate throughput while SMB latency degrades and NFS stays clean, so protocol-level separation is what makes the metric useful.

ObserveOps collects NFS and SMB protocol throughput and latency separately on Dell Isilon NL410 clusters, along with cluster health, per-node CPU and memory, and storage pool capacity. On the block side, per-LUN IOPS, throughput, latency, queue length, and busy percent are collected from HPE 3PAR systems.

What Storage Observability Changes for the Business

Storage observability changes four things a business can put a number against: capacity spend, incident duration, audit posture, and vendor accountability. Each maps to a budget line as much as to a dashboard.

1. Capacity spend: Growth trends per pool turn storage purchasing into a scheduled decision, cutting both emergency procurement and over-buying

2. Incident duration: Correlating array metrics with application behavior removes the hours spent proving which layer is responsible

3. Audit and risk posture: Component health and replication state evidence that recovery commitments are being met

4. Vendor accountability: Independent performance data supports warranty conversations and renewal negotiations

Consider a finance platform that slows every month-end. Host metrics stay clean, the array console reports no faults, and three engineers spend two days on it before anyone checks controller cache behavior. Array-side visibility answers that in the first hour, and the difference shows up as a staffing cost rather than a technical one.

Those four lines are how storage observability earns its place in the wider datacenter monitoring budget.

Which Storage Systems does Motadata ObserveOps Monitor?

Motadata ObserveOps monitors block arrays, NAS platforms, backup appliances, and cloud storage services, with published KPI coverage for each. The full storage monitoring capability set runs wider than the list below, which reflects what is documented today.

Block and unified arrays:

• HPE 3PAR, HPE Primera, HPE Alletra, HPE MSA

• Dell EMC Unity, Dell EMC VNX Control Station, Dell EMC VNX Storage Processor, Dell Compellent, Dell PowerVault

• Hitachi VSP and E-Series

• IBM FlashSystem, covering IBM storage monitoring tools requirements

• Huawei OceanStor

• Qsan XCubeNXT, Fibrenetix

NAS and file platforms:

• NetApp OnTap Cluster, discovering nodes, storage virtual machines, LUNs, disks, and pools, the route for NetApp storage monitoring tools coverage

• Dell Isilon NL410 scale-out NAS

• QNAP TS, Synology RS

Backup and cloud storage:

• HPE StoreOnce, AWS Backup

• AWS S3 and EBS, Azure Blob, File, Table, and Queue Storage, GCP Cloud Storage and Filestore, OCI Block Volume, File Storage, and Object Storage

Depth varies by system, so evaluate against the published KPI list for your specific model. HPE 3PAR alone exposes separate metric sets for system capacity, disks, provisioning groups, hosts, nodes, ports, Fibre Channel switches, volumes, and LUNs. Host-level consumption is handled separately through disk space monitoring.

What Should you Confirm Before Choosing Storage Monitoring Software?

Before choosing storage monitoring software, confirm coverage against your own hardware list instead of a vendor category page. The best storage monitoring tools for one environment are frequently the wrong ones for another, and the deciding factor is usually a single unsupported model.

Work through this before shortlisting:

• Model-level support: Confirm every array model you own appears by name, since vendor-level support rarely covers every line

• Firmware and version: Ask which firmware or software versions the integration was validated against

• Credentials required: Establish what access the tool needs, and whether a read-only account suffices

• Protocols and ports: Confirm which management interfaces and ports must be reachable from the collector

• KPI depth per domain: Check the published metric list against the seven domains above, particularly enclosure hardware and replication

• Alerting model: Confirm you can alert on absence of data, not only on threshold breach

• Multi-site collection: Confirm remote sites can be polled locally and forwarded centrally

• Historical retention: Establish how long metric history is kept, since rate-of-change analysis needs months of data

Run the shortlist against one array during evaluation. A support matrix confirms the model, and a discovery run confirms the credentials, the protocols, and the metrics that actually arrive.

Move From Array-by-Array Checks to One Failure Domain View With Motadata ObserveOps

Storage observability assembled one vendor console at a time gives you seven separate answers to one question, and the correlation happens in somebody's head at 2am. Organizing around failure domains changes what the tooling is asked to do. Each domain gets its own metrics, its own alerts, and its own investigation path.

Motadata ObserveOps collects those domains across HPE, Dell, NetApp, Hitachi, IBM, Huawei, QNAP, Synology, and Qsan systems, including an enclosure health plugin for HPE 3PAR, Alletra, and Primera. All of it lands in Metric Analysis, where it drives alert policies, dashboards, and reports next to the servers and network devices depending on the same hardware.

One category-level concession is worth making. A single storage vendor with a handful of arrays is well served by that vendor's own console and a free monitoring tool, and the argument for a platform is weak there. The case builds when vendors multiply and when somebody needs one answer about which layer is responsible.

Storage rarely fails all at once. It degrades in one domain at a time, and the tools that catch it are the ones watching all seven.

FAQs