feat(storage): IBM Storage Virtualize (FlashSystem, Storwize, SVC) REST API plugin

[Valdragon4]

Community contributors

Description

New plugin storage::ibm::flashsystem::restapi for IBM Storage Virtualize systems — FlashSystem, Storwize and SAN Volume Controller — through the REST API served on port 7443 (Storage Virtualize 8.1.3 and later).

The repository currently covers this product line through storage::ibm::storwize::ssh (four modes over SSH). The REST API exposes much more, and this plugin runs in production on two FlashSystem 5300 (Storage Virtualize 8.7.0.8) with twelve modes:

Mode	What it checks
system-status	meant as the host check: DOWN only when the array stopped serving (no answer, no canister online, no pool online) — a dead power supply or a degraded partition never take the host down, because that would make every service UNREACHABLE
hardware	enclosures, node and expansion canisters, power supplies, batteries, fan modules, drives, arrays, mdisks, quorum devices, plus the enclosure online_*/total_* counters and the temperature / power draw metrics
drives	per-drive FlashCore Module wear, NVMe path redundancy and physical fill (detailed lsdrive/<id> views)
capacity	physical usage (the figure that matters on over-allocated FlashCore Module pools), logical usage, pool status, data reduction ratio read from the layer that actually reduces (data reduction pools, or the FCM hardware compression from the detailed mdisk view)
volumes	aggregated volume states, abnormal volumes named in the output, --add-all-volumes for the full list
volume-groups	backup state, restore in progress, attached policies
hosts	declared hosts, offline / degraded
eventlog	unfixed alert entries — the GUI "Recommended Actions" — with message entries counted but not alerting
fc-ports	Fibre Channel ports, negotiated speed, host logins aggregated from the NPIV target ports
eth-ports	Ethernet ports and their IP configuration
performance	latency (volume, read, write, backend, drive), IOPS, bandwidth, cache occupancy, CPU overall and per canister
replication	storage partitions (8.7 high availability), policy-based volume group replication (8.5.2+), partnerships, and legacy Metro/Global Mirror relationships

Design points worth knowing for the review:

• Nothing array-specific is hard-coded: everything is discovered from the API, and every --filter-* is empty by default. Default severities follow one rule — CRITICAL means service lost, WARNING means redundancy lost — since every part of this hardware is redundant.
• The array rate-limits authentications (HTTP 429) and a session lasts two hours: the token is cached in a statefile and re-obtained on 401/403. An optional response cache (--command-cache-ttl, 0 by default) lets a site that splits the monitoring into many services share the ls* answers between checks.
• Every API command is a POST, including the ls* reads; the prefix (/rest/v1 since 8.1.3, /rest before) is auto-detected or pinned with --api-path.
• hosts inverts the usual order on purpose: offline is WARNING (the array cannot tell a deliberately powered-off server from a failed one), degraded is CRITICAL (a running host on eaten-into redundancy). The reasoning is in the help; I am happy to align on whatever default you prefer.

Two naming questions — this is why the pull request is opened as a draft:

1. Path. The code sits under src/storage/ibm/flashsystem/restapi/. The product line is "Storage Virtualize" and covers Storwize and SVC as well, and the existing SSH plugin lives under storwize/. Would you rather have storage/ibm/storwize/restapi for symmetry, or a new storage/ibm/storagevirtualize/restapi? I will move it wherever you say.
2. Hardware mode name. The SSH plugin calls it components; this one calls it hardware. Same answer: I will align.

Type of change

• Patch fixing an issue (non-breaking change)
• New functionality (non-breaking change)
• Functionality enhancement or optimization (non-breaking change)
• Breaking change (patch or feature) that might cause side effects breaking part of the Software

How this pull request can be tested ?

Automated tests — twelve Robot suites, fifty cases, against a Mockoon environment built from a real FlashSystem 5300 collection and anonymised (WWPNs, serials, ids, host / volume / partition / system names, addresses):

robot tests/storage/ibm/flashsystem/restapi/

Each mode is exercised through its plain run, filters, a forced status expression and numeric thresholds, so OK, WARNING and CRITICAL paths are all covered. Result on RHEL 9 with the framework dependencies: 50 tests, 50 passed, 0 failed.

Against a real system — an account with the Monitor role is enough:

perl centreon_plugins.pl --plugin=storage::ibm::flashsystem::restapi::plugin --mode=hardware \
    --hostname=<array> --api-username=<user> --api-password=<password> --insecure

API facts, for the reviewers (the arrays present a self-signed certificate, hence -k):

# authentication: credentials in headers, a token in the answer
curl -k -X POST https://<array>:7443/rest/v1/auth \
     -H 'X-Auth-Username: <user>' -H 'X-Auth-Password: <password>'
# {"token": "..."}

# every command is a POST, parameters in a JSON body
curl -k -X POST https://<array>:7443/rest/v1/lssystem \
     -H 'X-Auth-Token: <token>' -H 'Content-Type: application/json' -d '{}'
curl -k -X POST https://<array>:7443/rest/v1/lseventlog \
     -H 'X-Auth-Token: <token>' -H 'Content-Type: application/json' -d '{"filtervalue":"fixed=no"}'
# detailed view of one object: the id goes in the path
curl -k -X POST https://<array>:7443/rest/v1/lsdrive/0 \
     -H 'X-Auth-Token: <token>' -H 'Content-Type: application/json' -d '{}'

Sample outputs — the plugin's real output against the anonymised environment (these are the expectations of the Robot suites):

OK: Array is serving: canisters 2/2 online, pools 1/1 online
OK: Hardware: 35 component(s), 0 not online - All hardware components are online - Enclosure: temperature 26 C, power draw 540 W - All enclosure subsystems are fully populated | 'hardware.components.detected.count'=35;;;0; ...
OK: Drives: 12 detected - All drives have both paths online | 'drives.detected.count'=12;;;0; '0#drive.endurance.used.percentage'=0%;;;0;100 ...
OK: Physical capacity: used 47.10 %, 146.48 TB, free 164.51 TB, overallocation 137 % - Logical: used 292.98 TB, free 629.24 TB - Data reduction: 1.81:1, saved 118.97 TB - Pool 'pool-a' status: online, overallocation: 137%, data reduction: no, used 32.74 %, free 629.06 TB | ...
WARNING: Host 'host-29' status: offline, ports: 4, partition: partition-b - Host 'host-43' status: offline, ports: 4, partition: partition-b ...
CRITICAL: Storage partition 'partition-b' high availability status: problem, link: synchronized, system-a: healthy, system-b: healthy | 'replication.partitions.detected.count'=2;;;0; ...
OK: Performance: latency 0.398 ms, read 0.341 ms, write 0.472 ms, 7923 IOPS, bandwidth 408.00 MB/s, cpu 15 %, compression cpu 0 %, write cache 34 %, total cache 80 %, backend 0.314 ms, drives 0.194 ms, fc 29503 IOPS, fc 546.00 MB/s - All node CPUs are ok | ...

Also included: the packaging directory (centreon-plugin-Hardware-Storage-Ibm-Flashsystem-Restapi), one help entry per option with the default expression under the matching severity, and the Storage Virtualize vocabulary the help uses added to the spell checker dictionary.

Checklist

• I have followed the coding style guidelines provided by Centreon
• I have commented my code, especially hard-to-understand areas of the PR.
• I have rebased my development branch on the base branch (develop).
• I have provide data or shown output displaying the result of this code in the plugin area concerned.