ITWorx Pulse release export
bd774932d5
Public source validation / validate (push) Failing after 3m8s
96 lines
2.7 KiB
Markdown
96 lines
2.7 KiB
Markdown
# 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.
|