Storage monitoring requirements

Storage is a first-class domain with strict read-only behavior.

Array

Display:

current array state;
parity presence/state;
data disk membership;
missing/disabled/emulated disks;
read/write activity;
parity check state, progress, speed, errors and history;
last/next check when available.

No start/stop/check/correct action is offered in v1.

Disks

For every disk:

stable identity and role;
model/serial with privacy-aware display;
size and filesystem;
used/free/inodes;
temperature and trend;
read/write throughput, IOPS and latency when available;
spin state when available;
SMART overall and selected attributes;
self-test age/result;
reallocated, pending and offline-uncorrectable sectors;
CRC/interface errors;
SSD wear/percentage used where relevant.

Rules must avoid declaring a disk healthy when SMART data is unavailable/stale.

Pools

Support cache and ZFS/Btrfs pool concepts discovered in the environment:

members;
usable/used/free;
profile/redundancy;
degraded/faulted/offline member state;
scrub status/results;
filesystem errors;
write/read performance;
SSD wear;
mover-related signals when available.

Do not assume all pools use the same filesystem.

name and configured policy;
used size and growth;
participating storage;
cache/pool relationship;
recent growth;
forecast to thresholds;
unavailable/stale state.

Potentially expensive size calculation must be rate-limited/cached and optional.

Forecasting

Capacity forecast:

uses configurable historical window;
reports method and confidence/uncertainty;
handles irregular bulk imports;
never presents a precise date without qualification;
can be disabled when insufficient history exists.

Baseline alert classes

array degraded/missing disk;
parity errors;
SMART critical attribute;
temperature sustained above policy;
pool degraded/faulted;
capacity thresholds;
read-only filesystem;
scrub/check errors;
stale storage data.

Availability, device health, capacity pressure and thermal pressure are separate signals. An online device can therefore be capacity-critical or thermally critical without being presented as offline, and a stale observation makes all current signal severities Unknown. Pulse uses the stable source device ID as the canonical physical identity. Repeated identical observations are idempotent; conflicting roles or facts for one physical ID fail closed instead of producing duplicate or contradictory topology nodes.

Safety tests

Storage fault behavior is tested through fixtures/simulator or read-only captured data. Never trigger real SMART damage, pool degradation, disk removal or array operations.

2.7 KiB Raw Blame History