This commit is contained in:
@@ -0,0 +1,95 @@
|
||||
# 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.
|
||||
|
||||
## Shares
|
||||
|
||||
- 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.
|
||||
Reference in New Issue
Block a user