Monitoring HP EVA status from icinga / nagios. Plugin check_eva.py
I promised to talk about all sorts of unusual equipment from a monitoring point of view, and in this article I will talk about remote control of a fairly common array of HP EVA virtual disks. In order to “practice on cats” let's take a Hewlett-Packard EVA4400 with an HSV300 controller and two disk shelves, since it stands through the wall and it is possible to take all the screenshots and data from a live system.
The most unexpected thing about this device is the way to work with SNMP. Sometimes they start saying that it supports SNMP and even gives a link to the documentation. Even more confusing is that you can go to Command View / System Options / Configure Event Notification and see that from there you can download the MIB for the device.
So - this is not the MIB. "Not Penny's boat!"
')
HP has done on this device only SNMP notifications, in common parlance - SNMP traps, which it sends to the SNMP server itself. It does not process external SNMP requests — snmpwalk cannot walk through it, alas.
Someone Pall Sigurdsson (palli@opensource.is) wrote the check_eva.py script (download here ), which somehow collects as much as we need all the data about the system state by polling the device controller.
If the focus is explained, then all the magic disappears. In fact, the script works through SSSU - this is the HP Storage System Scripting Utility.
We will need sssu_linux_x86. You can find it on the disk where we have the EVA Command View control software itself or download it from the HP website ( here or a direct link here ).
This is not the newest version of the utility (version 6.0.2, 2007), but it works. Moreover, we don't need the newest one.
For the plugin to work, on the OS where our monitoring server is deployed, two things need to be done:
1.to make sure that python is installed
If not, then we put it in our favorite way for our OS.
2. Install the SSSU utility (actually copy to the search path and make a symlink in / usr / local / bin /, where the script wants to find it).
If we have Red Hat Enterprise Linux 2.1, Red Hat Enterprise Linux 3 (x86), Red Hat Enterprise Linux 4 (x86), SUSE Linux Enterprise Server 10 (x86), SUSE Linux Enterprise Server 9 (x86), or any other system, supported by Hewlett-Packard, we don’t need any further steps, you can go directly to the section “Preparing the script for work”.
But since we are not looking for simple ways, and we have a monitoring system running on another OS (FreeBSD 9.0), we will also understand how to run the Linux binary on FreeBSD. Here, too, there is nothing complicated, the way is documented .
By default, binary compatibility with Linux is disabled in FreeBSD. To enable it, from under the root enter the command:
In order for it to be active when the system is rebooted, then in /etc/rc.conf you should add:
To make sure that the KLD (kernel dynamic linker) has loaded, enter:
linux.ko is present. After running the utility, we get the error:
We do the following: install an emulator for linux libraries:
But sssu again swears, most likely, the emulator libraries are few, something else is needed. Enter:
ldd will show dependencies on libraries, as well as their presence in the system:
The libpam.so.0 and libaudit.so.0 libraries were not found. You can see what rpm they are in, for example, through this site - rpm.pbone.net . The search shows that libpam is in rpm from Fedora: pam-0.79-8.i386.rpm, and libaudit.so.0 in rpm from Mandriva: libaudit0-1.7.13-9.1.3.i586.rpm. Download them to yourself and get them from rpm using rpm2cpio:
Then we copy both libraries to the directory where the linux / compat / linux / lib compatibility libraries are located, and make symlinks so that the system knows which one to pick up:
We start, we check. We see on the monitor:
What we needed. You can enter it: Manager - specify the IP or host name of the EVA Command View, username, password - respectively. The utility works.
sssu_linux_x86 need to be put in / usr / local / bin and make a symlink on it so that the script knows where to find it:
For FreeBSD everything.
Happy users of Linux systems who have sssu_linux_x86 planted in the search path and have made a symlink on it continue from this point. So, python and SSSU work for us.
Run the script it with the key --help
With options, everything is clear:
Modes:
Checking:
EVA responds.
Further details vary from the configurator used, but this sequence of steps is the same for nagios / icinga:
1. Create a verification team.
If we do not want to shine the passwords in the configurator, then in the system file nagios / icinga with the name resource.cfg we write:
$ USER7 $ = user_name_for_EVA,
$ USER8 $ = password_for_EVA
Numbers - any that you have free.
Our verification team is:
$ USER1 $ / check_eva.py --host $ HOSTADDRESS $ --username $ USER7 $ --password $ USER8 $ --mode $ ARG1 $
2. Then, for each request mode, we create services, bind them to our verification team, for which only the $ ARG1 $ argument changes.
3. We assign services to the hosts directly or include them in the template, and assign the template to the hosts (if we have a lot of racks)
4.Save the configuration, wait for the polling of new devices to end:
We look at the picture. All information about our storage system in full view:
Gray color is a sign that the cursor is on this line, there, in fact, everything is also OK.
1.Skript will not work with SSSU version 10.2 and newer. Works great with versions 9.4 and older. Perhaps the new EVA models will not work with older versions of SSSU - this has not been verified.
2. The author has not been in touch for a long time. But the source code of the script is, so you can always spend a little time and finish to fit your needs. "Open software! = Closed software."
Sometimes SSSU gives an error that it is impossible to create an https connection. Overload control interface on EVA
PS I would very much like the experts to tell whether it is possible to achieve a similar result in the zabbix monitoring system and what sequence of steps is needed, considering that there are no HP EVA templates in the system out of the box, SSSU is not included in the list of supported agents, but is SNMP targeted. the system does not respond.
Hint: The problem can be solved. But in a different, longer way.
The most unexpected thing about this device is the way to work with SNMP. Sometimes they start saying that it supports SNMP and even gives a link to the documentation. Even more confusing is that you can go to Command View / System Options / Configure Event Notification and see that from there you can download the MIB for the device.
So - this is not the MIB. "Not Penny's boat!"
')
HP has done on this device only SNMP notifications, in common parlance - SNMP traps, which it sends to the SNMP server itself. It does not process external SNMP requests — snmpwalk cannot walk through it, alas.
Someone Pall Sigurdsson (palli@opensource.is) wrote the check_eva.py script (download here ), which somehow collects as much as we need all the data about the system state by polling the device controller.
Secret of focus
If the focus is explained, then all the magic disappears. In fact, the script works through SSSU - this is the HP Storage System Scripting Utility.
We will need sssu_linux_x86. You can find it on the disk where we have the EVA Command View control software itself or download it from the HP website ( here or a direct link here ).
This is not the newest version of the utility (version 6.0.2, 2007), but it works. Moreover, we don't need the newest one.
For the plugin to work, on the OS where our monitoring server is deployed, two things need to be done:
1.to make sure that python is installed
icinga# python Python 2.7.3 (default, Sep 11 2012, 11:58:26) [GCC 4.2.1 20070831 patched [FreeBSD]] on freebsd9 Type "help", "copyright", "credits" or "license" for more information. >>> If not, then we put it in our favorite way for our OS.
2. Install the SSSU utility (actually copy to the search path and make a symlink in / usr / local / bin /, where the script wants to find it).
If we have Red Hat Enterprise Linux 2.1, Red Hat Enterprise Linux 3 (x86), Red Hat Enterprise Linux 4 (x86), SUSE Linux Enterprise Server 10 (x86), SUSE Linux Enterprise Server 9 (x86), or any other system, supported by Hewlett-Packard, we don’t need any further steps, you can go directly to the section “Preparing the script for work”.
But since we are not looking for simple ways, and we have a monitoring system running on another OS (FreeBSD 9.0), we will also understand how to run the Linux binary on FreeBSD. Here, too, there is nothing complicated, the way is documented .
Ensuring binary compatibility of FreeBSD with Linux.
By default, binary compatibility with Linux is disabled in FreeBSD. To enable it, from under the root enter the command:
# kldload linux In order for it to be active when the system is rebooted, then in /etc/rc.conf you should add:
linux_enable="YES" To make sure that the KLD (kernel dynamic linker) has loaded, enter:
# kldstat Id Refs Address Size Name 1 2 0xc0100000 16bdb8 kernel 7 1 0xc24db000 d000 linux.ko linux.ko is present. After running the utility, we get the error:
icinga# ./sssu_linux_x86 ELF interpreter /lib/ld-linux.so.2 not found We do the following: install an emulator for linux libraries:
# cd /usr/ports/emulators/linux_base-f10 # make install distclean But sssu again swears, most likely, the emulator libraries are few, something else is needed. Enter:
ldd sssu_linux_x86 ldd will show dependencies on libraries, as well as their presence in the system:
./sssu_linux_x86: librt.so.1 => /lib/librt.so.1 (0x281c8000) libpthread.so.0 => /lib/libpthread.so.0 (0x281d2000) libdl.so.2 => /lib/libdl.so.2 (0x281ec000) libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x281f1000) libm.so.6 => /lib/libm.so.6 (0x282a7000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x282d0000) libc.so.6 => /lib/libc.so.6 (0x282df000) /lib/ld-linux.so.2 (0x2819a000) libpam.so.0 => not found libaudit.so.0 => not found The libpam.so.0 and libaudit.so.0 libraries were not found. You can see what rpm they are in, for example, through this site - rpm.pbone.net . The search shows that libpam is in rpm from Fedora: pam-0.79-8.i386.rpm, and libaudit.so.0 in rpm from Mandriva: libaudit0-1.7.13-9.1.3.i586.rpm. Download them to yourself and get them from rpm using rpm2cpio:
rpm2cpio < pam-0.79-8.i386.rpm | cpio -ivd ./lib/libpam.so.0.79 rpm2cpio < libaudit0-1.7.13-9.1.3.i586.rpm | cpio –ivd Then we copy both libraries to the directory where the linux / compat / linux / lib compatibility libraries are located, and make symlinks so that the system knows which one to pick up:
ln -s /compat/linux/lib/libpam.so.0.79 /compat/linux/lib/libpam.so.0 ln -s /compat/linux/lib/libaudit.so.0.0.0 /compat/linux/lib/libaudit.so.0 We start, we check. We see on the monitor:
SSSU for HP StorageWorks Command View EVA Version: 6.0.2 Build: 5 Manager: What we needed. You can enter it: Manager - specify the IP or host name of the EVA Command View, username, password - respectively. The utility works.
sssu_linux_x86 need to be put in / usr / local / bin and make a symlink on it so that the script knows where to find it:
ln -s /usr/local/sbin/sssu_linux_x86 /usr/local/bin/sssu For FreeBSD everything.
Preparing the script to work.
Happy users of Linux systems who have sssu_linux_x86 planted in the search path and have made a symlink on it continue from this point. So, python and SSSU work for us.
Run the script it with the key --help
icinga# ./check_eva.py --help check_eva version 1.0 This plugin checks HP EVA Array with the sssu command Usage: ./check_eva.py [OPTIONS] OPTIONS: [--host <host>] [--username <user>] [--password <password] [--path </path/to/sssu>] [--mode <mode>] [--test] [--debug] [--help] Valid modes are: check_systems, check_controllers, check_diskgroups, check_disks, check_diskshelfs, check_diskshelves Example: ./check_eva.py --host commandview.example.net --username eva --password myPassword --mode check_systems With options, everything is clear:
--host < > --username < Command View> --password < > --path < sssu, > --mode <> --test --debug --help Modes:
check_systems – check_controllers – check_diskgroups – check_disks – check_diskshelfs, check_diskshelves – . Checking:
icinga# ./check_eva.py --host ip.ad.dr.es --username user --password pass OK - 1 objects found | '/Eva_totalstoragespace'=7539.91 '/Eva_usedstoragespace'=4737.25 '/Eva_availablestoragespace'=2802.66 /Eva = good (initialized_ok) - licensestate = good - systemtype = HSV300 - firmwareversion = 09534000 - nscfwversion = CR18CBlep-09534000 - totalstoragespace = 7539.91 - usedstoragespace = 4737.25 - availablestoragespace = 2802.66 EVA responds.
Further details vary from the configurator used, but this sequence of steps is the same for nagios / icinga:
1. Create a verification team.
If we do not want to shine the passwords in the configurator, then in the system file nagios / icinga with the name resource.cfg we write:
$ USER7 $ = user_name_for_EVA,
$ USER8 $ = password_for_EVA
Numbers - any that you have free.
Our verification team is:
$ USER1 $ / check_eva.py --host $ HOSTADDRESS $ --username $ USER7 $ --password $ USER8 $ --mode $ ARG1 $
2. Then, for each request mode, we create services, bind them to our verification team, for which only the $ ARG1 $ argument changes.
3. We assign services to the hosts directly or include them in the template, and assign the template to the hosts (if we have a lot of racks)
4.Save the configuration, wait for the polling of new devices to end:
We look at the picture. All information about our storage system in full view:
Gray color is a sign that the cursor is on this line, there, in fact, everything is also OK.
Known limitations
1.Skript will not work with SSSU version 10.2 and newer. Works great with versions 9.4 and older. Perhaps the new EVA models will not work with older versions of SSSU - this has not been verified.
2. The author has not been in touch for a long time. But the source code of the script is, so you can always spend a little time and finish to fit your needs. "Open software! = Closed software."
Sometimes SSSU gives an error that it is impossible to create an https connection. Overload control interface on EVA
PS I would very much like the experts to tell whether it is possible to achieve a similar result in the zabbix monitoring system and what sequence of steps is needed, considering that there are no HP EVA templates in the system out of the box, SSSU is not included in the list of supported agents, but is SNMP targeted. the system does not respond.
Hint: The problem can be solved. But in a different, longer way.
Source: https://habr.com/ru/post/170903/
All Articles