Storage performance monitoring: Technologies, key metrics, and best practices

Key metrics to track at this level

At the physical data storage level, the most important metric is capacity. You don't have to pay heed to what data is stored where. But you need to know how much space is used and how much is available. Most storage mediums are susceptible to damage. Temperature is a good way to check if things are running well. High temperature levels can be a sign of hardware issues which could cause disk degradation.

Key metrics to track at this level

These metrics measure the speed and response of storage drives.

• IOPS (Input/Output operations per second): Total read/write operations handled per second.
• Throughput: Volume of data read or written per second in MBps or GBps.
• Latency: The time taken to complete a single I/O request.
• Queue depth: Number of I/O requests waiting to be processed by the drive.
• Mechanical tape metrics: For moving drives like tapes and hard disks, monitoring the tape itself is important.

Key metrics to track at this level

These metrics show how well data moves between storage and the rest of the network.

• Port utilization: Percentage of available bandwidth used on switch ports and HBAs.
• Throughput: Volume of data moving across the interface per second.
• Latency: Time taken for data to travel from source to destination.
• Packet loss: Number of packets dropped or corrupted in transit. This often signals a faulty cable or a congested link.
• Link status: Whether a port is up, down, or flapping (switching rapidly between the two).

Key metrics to track at this level

These metrics show how efficiently logical storage is allocated and performing.

• Capacity utilization: How full the pool is, and how much of a LUN's allocated space is actually in use.
• IOPS (input/output operations per second): How many read/write operations the pool or LUN handles each second. See our IOPS and storage performance guide for a full breakdown.
• Latency: How long each I/O request takes to complete, usually in milliseconds.
• Throughput: How much data moves through the pool or LUN per second, usually in MB/s.
• Queue depth: How many I/O requests are waiting to be processed; a rising queue often signals a bottleneck.
• Error and retry rates: Failed or retried I/O operations, often an early warning sign of a failing drive.

Key metrics to track at this level

These metrics show how well cloud storage is performing, and what it's costing to run.

Capacity utilization: How much storage is provisioned versus how much is actually used. Over-provisioned volumes are a common, easily overlooked source of wasted cloud spend.

IOPS (input/output operations per second): How many read/write operations a volume handles each second. Cloud providers often cap IOPS by volume size or performance tier, so this ceiling is worth watching closely.

Throughput: How much data moves to and from the volume per second, usually in MB/s.

Latency: How long a read or write request takes to complete, usually in milliseconds.

Request rate: For object storage, the number of API calls, like GET, PUT, and LIST, made per second. Object storage is billed by request rather than by drive activity, so this metric doubles as a cost signal.

Error rates: The percentage of failed requests, often visible as HTTP status codes. A rising share of throttling or permission errors can point to problems before they show up as downtime.

Threshold guidance per layer

The same metric can mean different things at different layers. A latency number that's a red flag at one layer might be routine at another. That's because each layer sits at a different distance from the physical medium.

At the drive level, latency is measured in single-digit milliseconds. SSDs typically respond in under 1 ms. HDDs run higher, often 5-15 ms, because of the mechanical head movement involved in reading and writing. Numbers well above these ranges usually point to a drive that's overloaded or failing.

At the LUN or volume level, latency includes time spent in the pool and controller, not just the disk itself. For legacy spinning disk-arrays, LUN latency usually stays under 10-20 ms. For modern All-Flash storage, healthy LUN latency usually stays between 0.5—5 ms.

At the network interface level, latency reflects travel time across the fabric, not the drive. Fibre Channel is built to stay in the sub-millisecond range. iSCSI shares bandwidth with regular Ethernet traffic, so it can run a little higher before it's a concern. A sudden jump here often points to congestion or a bad cable, not a storage problem at all.

Separate thresholds for each layer, instead of one number for the whole environment, help you find where a problem starts. That's more useful than just noticing that something feels slow.

How to read metrics together

A single metric rarely tells the whole story. Most storage problems show up as a pattern across two or more metrics. Reading them in pairs points to a cause much faster than any one number on its own.

High latency paired with high queue depth usually means a bottleneck. More requests are arriving than the system can process, so they pile up while waiting their turn. This is common during traffic spikes, or when a system is undersized for its workload.

High latency paired with a low queue depth tells a different story. Requests aren't backing up, but each one still takes a long time to finish. That points to the controller, the drive firmware, or a failing component, rather than an overloaded system.

High throughput with high latency can mean a system working at its limit: moving plenty of data but straining to keep response times down. Low throughput with high latency usually points to something broken rather than overloaded, since the system isn't managing to push much data through in the first place.

Reading metrics in pairs like this turns a vague "performance is degraded" alert into a specific, actionable diagnosis.

Polling interval trade-offs

How often you sample a metric changes what you can see in it. Poll too rarely, and you smooth over real problems. Poll too often, and you add overhead and noise.

A 1-minute interval catches short-lived spikes, like a brief jump in queue depth when a backup job kicks off. This level of detail helps you track down issues that come and go. But it also produces a lot of data and adds a small amount of load to the systems being monitored.

A 5-minute interval is lighter on both storage and monitoring infrastructure. It's usually enough for capacity planning and long-term trends. But it averages out short spikes. A drive that hits dangerous latency for 90 seconds might show up as barely a bump on a 5-minute chart, even though it was enough to slow things down for users at that moment.

Many teams use a mix. Shorter intervals cover latency, IOPS, and queue depth, where spikes matter most. Longer intervals cover capacity and temperature, which change more slowly and don't need minute-by-minute tracking.

Baseline before alerting

A threshold only works if it reflects how your system actually behaves. Generic thresholds on a brand-new storage system, before it has handled any real workload, usually lead to alerts that are either too sensitive or not sensitive enough.

New systems typically need one to two weeks of data before thresholds mean anything. This window should cover a normal range of activity: weekday peaks, nightly backups, and weekend lulls. That way, the baseline reflects real usage instead of a quiet first few days.

Once that baseline is in place, thresholds can be set against the system's own normal range instead of a generic number from a spec sheet. This also makes it easier to catch problems early. A LUN that usually runs at 5 ms and creeps up to 12 ms is a real warning sign, even though 12 ms would be unremarkable on a system whose normal baseline sits at 15 ms.

Schedule discovery scans

New disks, LUNs, and volumes get added to your storage environment all the time. Set up periodic discovery scans so your monitoring tool finds these additions automatically. Monitoring then starts right away, instead of waiting for someone to add each device by hand.

Enable ML-driven monitoring

Monitoring the key metrics listed above will help you find storage issues proactively. However, setting alarm thresholds can be tough. Static thresholds don't always fit storage environments, where usage patterns shift by time of day, workload, or season. Machine learning-based monitoring studies historical trends for each device. It adjusts thresholds on its own, flagging real anomalies while ignoring normal spikes.

Monitor each disk, LUN, volume, and pool individually

Aggregate, high-level views can hide a problem building inside a single component. A pool can look healthy on average while one disk inside it is failing. Track metrics at the individual disk, LUN, volume, and pool level. That way, localized issues are identified before they spread.

Configure multi-channel notifications

A single notification channel can fail, get buried, or simply go unnoticed. Set up alerts across multiple channels, like email, SMS, and chat apps. That way, the right person sees a critical warning no matter where they are.

Build automated workflows

Some storage issues need a response faster than a human can manage. Configure automated workflows that trigger predefined actions the moment a threshold is breached. These can include restarting a service, freeing up disk space, or escalating a ticket.