prometheus-smartraid-exporter
This Prometheus exporter collects metrics from SmartRAID controllers using a CLI
tool (ssacli
) and provides them via a HTTP server, writes them to standard
output or writes them atomically to a file.
Usage
There are two main operation modes:
-
Executing
prometheus-smartraid-exporter
in thehttp
-export-mode as a service, which provides the metrics via a HTTP server.The metrics are (freshly) collected on every scrape. The scraping is to be done directly (by Prometheus). -
Executing
prometheus-smartraid-exporter
in thefile
-export-mode via a systemd timer,cron
job, et cetera, which writes the metrics atomically (via moving a newly created temporary file) to a.prom
-file for Prometheus node exporter’s textfile collector.The metrics are (periodically) collected (once) on every execution. The scraping is to be done indirectly via the Prometheus node exporter (by Prometheus).
Execute prometheus-smartraid-exporter
with the --help
- or -h
-option
for information about the command arguments.
Metrics
Every metric is for a specific data object of the type controller, sensor, array, logical drive or physical drive.
“Primary Key” And “Property” Labels
The “primary key” labels identify the respective data object, with the base set of them depending on its type:
-
Controller
controller_name
-
Sensor
controller_name
andsensor_name
-
Array
controller_name
andarray_name
-
Logical Drive
controller_name
,array_name
andlogical_drive_name
-
Physical Drive
controller_name
andphysical_drive_name
Extra “primary key” labels may be given per type via the
--metrics-extra-primary-key
-option.
In contrast to “primary key” labels are “property” labels like
controller_status
, serial_number
and raid_level
, which are not meant
to identify the respective data object.
In Prometheus, the change of a label’s value (as well as the addition/removal of a label) results in a new/different time series.
For “primary key” labels this is typically desired. For “property” labels, however, this is in principle less desirable (but still unavoidable, though in practise not really a problem), for example, a changed controller status does not cause the controller to be a different one, but does so for the time series.
With only the base sets of “primary key” labels there are some cases where an actually different data object would not cause a different time series for all metrics.
In particular, replacing a controller will likely not cause a different
controller_name
(though its serial_number
should change) and replacing a
physical drive will likely not cause a different physical_drive_name
(and of
course neither a different controller_name
, though its serial_number
and
wwn
should change).
This can however be obtained via the aforementioned extra “primary key” labels.
Testing
This was tested with:
-
ssacli
version 6.30.8.0 onSmart Array P840ar
-
ssacli
version 6.30.8.0 onHPE Smart Array P408i-a SR Gen10
-
ssacli
version 6.30.8.0 onHPE Smart Array P816i-a SR Gen10
Caveats
Notice the exclusion of any warranty for this program, including the implied warranty of merchantability or fitness for a particular purpose (especially – but not limited – to use it for checking or monitoring the health status of controllers, logical and physical drives). See the licence.
Controllers that use the box:bay
or port:id
physical drive naming schema
are currently not supported.