I’m working on a new server. The server contains a Dell PERC 6/i which is driven nicely by the mptsas kernel module. OpenSuSE 12.2 64-bit installed easily on the hardware RAID-1 array.
I need a good monitor for the array that will notify when there is a problem.
The “mtp-status” command (which is in the opensuse repositories) works nicely for getting the status. I see that the Debian folks have an mpt-statusd daemon that is a shell script that sleeps for an interval, checks status via mpt-status and if if there is an issue sends notifications via email. The mpt-statusd script that I pulled from a Debian source is not suitable for running on opensuse as written. Has anyone already “SuSE-fied” mpt-statusd? I hate to do the work if it is available somewhere that I have not already looked into.
There may be no need for customisation of the script.
The following is installed by default on my openSUSE 12.2 / 64 bit machine
mpt-status - Program Showing the Status of LSI 1030 RAID Controller
To enable the daemon i need to set “system services(runlevel)” in YaST in expert mode for service (mdadmd)
Unless I am missing something, the description of mdadmd is that it can be used to monitor SOFTWARE raid devices. I am using a HARDWARE raid adapter to implement the array. Thus the use of mpt-status for getting the array status. There are no software-implemented arrays nor “fakeraid” arrays in this picture.
# lspci | grep SAS
01:00.0 SCSI storage controller: LSI Logic / Symbios Logic SAS1068E PCI-Express Fusion-MPT SAS (rev 08)
Yes. And both are installed and function correctly. But that is not the discussion topic.
mpt-status can be used to get a snapshot of the then-current status. Additional code is required to monitor the status for changes and deliver alerts of the changed state. Thus my original post.
One such monitoring tool is the mpt-statusd (daemon) shell script provided with Debian. But that script is not compatible with openSuSE’s init (now systemd) structure as written.
vazhavandan;2521412 Wrote:
> These are available in the standard repos.
Yes. And both are installed and function correctly. But that is not the
discussion topic.
mpt-status can be used to get a snapshot of the then-current status.
Additional code is required to monitor the status for changes and
deliver alerts of the changed state. Thus my original post.
One such monitoring tool is the mpt-statusd (daemon) shell script
provided with Debian. But that script is not compatible with openSuSE’s
init (now systemd) structure as written.
The perl script on the url you provided is essentially what I have been working on this afternoon in shell script by using the relevant parts from the mpt-statusd script. It was my plan to do as you suggested with that which I am coding. That is, to invoke every few minutes via cron. It will save the the previous status info in /var/run/ for comparison with the next invocation. Easier to implement quickly than the daemonizing for me.
I managed to cobble together a cron-invoked script that used some of the code logic from the aforementioned mpt-statusd script from Debian. After beefing up the script to interpret the bit-mask of the return-value from the mpt-status module (refer to “man mpt-status”), I was further frustrated to learn during testing that the bit-masked return-value is only returned when including the “-n” option to mpt-status. From the man page:
-n --newstyle
Use the new style output. This parameter was introduced to retain backwards compatibility. If not set, you get the old style output. It is very likely that the output of the newstyle format will change heavily in the future, so do not rely on it when writing plugins for monitoring software, for example.
That’s pretty lame. So the more informative bit-masked return value from the program is not something to rely on? Bleah. Omitting the -n option will get you a much-less informative non-zero return value. Better than nothing, but barely.
In frustration, I went ahead and installed the LSI MegaRaid Storage Monitor package downloaded from the LSI website. It works fine with the Dell 6/Ir card with the 1068E chip. It is far more bloated than a small simple script, but does have a nice GUI interface for configuring email alert for failed aspects of an array.