Search Exchange
Search All Sites
Nagios Live Webinars
Let our experts show you how Nagios can help your organization.Login
New ListingsDirectory Tree
check_3ware_SSH
The original p_view=289 check_3ware">http://www.nagiosexchange.org/RAID_Controller.58.0.html?&tx_netnagext_pi1p_view=289 check_3ware Perl script works well but I didn't feel like installing nagios on the servers just for one service. Solution: modify the script to run the commands over SSH. This requires a little more setup on your part, though less than setting up nagios :).
Usage:
1) Download tw_cli from 3ware's website, install on remote host(s). Make sure you have the right version, might take a few tries to find it.
2) Create //nagios// user on remote host, with home directory.
3) On remote host, edit ///etc/sudoers//. Add the following line to allow nagios to execute tw_cli as root:
**{{nagios ALL=NOPASSWD: /usr/bin/tw_cli}}**
4) On local (monitoring) host, generate an authentication key:
**{{$ su - nagios}}**
**{{$ ssh-keygen}}**
5) Copy the authentication key to the remote host:
**{{$ scp /home/nagios/.ssh/id_rsa nagios@192.168.1.15:/home/nagios/.ssh/authorized_keys}}**
**- Note: above command assumes the //authorized_keys// file doesn't exist! If it does, you will want to append it.**
6) You can now run the script on a remote host as root with the nagios user on the local (monitoring) host:
**{{$ ./check_3ware -C 0 -U 0 -H 192.168.1.15 -u nagios}}**
7) Here's how it looks in //checkcommands.cfg//:
**{{$USER1$/check_3ware -C $ARG1$ -U $ARG2$ -H $HOSTADDRESS$ -u nagios}}**
**Q:** Why not use check_by_ssh?
**A:** I would rather have the script in one place rather than on all the servers. Makes maintenance easier.
**A:** I've had problems with check_by_ssh. Of course, that could be attributed to my stupidity ;)
**Q:** Do I need //both// scripts, one for local, the other for ssh?
**A:** No, to check local, just omit the {{-H}} and {{-u}} options.
- //ianar? s?vi//
Usage:
1) Download tw_cli from 3ware's website, install on remote host(s). Make sure you have the right version, might take a few tries to find it.
2) Create //nagios// user on remote host, with home directory.
3) On remote host, edit ///etc/sudoers//. Add the following line to allow nagios to execute tw_cli as root:
**{{nagios ALL=NOPASSWD: /usr/bin/tw_cli}}**
4) On local (monitoring) host, generate an authentication key:
**{{$ su - nagios}}**
**{{$ ssh-keygen}}**
5) Copy the authentication key to the remote host:
**{{$ scp /home/nagios/.ssh/id_rsa nagios@192.168.1.15:/home/nagios/.ssh/authorized_keys}}**
**- Note: above command assumes the //authorized_keys// file doesn't exist! If it does, you will want to append it.**
6) You can now run the script on a remote host as root with the nagios user on the local (monitoring) host:
**{{$ ./check_3ware -C 0 -U 0 -H 192.168.1.15 -u nagios}}**
7) Here's how it looks in //checkcommands.cfg//:
**{{$USER1$/check_3ware -C $ARG1$ -U $ARG2$ -H $HOSTADDRESS$ -u nagios}}**
**Q:** Why not use check_by_ssh?
**A:** I would rather have the script in one place rather than on all the servers. Makes maintenance easier.
**A:** I've had problems with check_by_ssh. Of course, that could be attributed to my stupidity ;)
**Q:** Do I need //both// scripts, one for local, the other for ssh?
**A:** No, to check local, just omit the {{-H}} and {{-u}} options.
- //ianar? s?vi//
Reviews (1)
bystefanlasiewski, November 18, 2009
1 of 1 people found this review helpful
Nice simple check. The Perl code is readable.
The script provides options which let you specify the specific Controller and specific Unit.
I prefer to use NRPE, NSCA or check_by_ssh to check my remote hosts, and the built-in SSH seems redundant. This is just my preference.
I'm testing this on FreeBSD 7.2 (By changing the path) with a 3ware 9000 series. It seems to work fine. I'll probably use it on some CentOS 5.4 machines shortly.
Some issues:
1. I need to specify the specific Unit (e.g "check_3ware.pl --controller 0 --unit 1"), otherwise this script only checks Unit 0.
2. The script has a list of keywords for the WARNING and OK states. Anything else becomes CRITICAL. If the array shows a "DEGRADED" or OFFLINE message, this script will consider that a WARNING. Really, the script should specify OK, WARNING and CRITICAL states. Anything else should become UNKNOWN.
It's easy enough to change the OK and WARNING criteria by adding them to the @state_ok & @state_warning Perl arrays.
The script provides options which let you specify the specific Controller and specific Unit.
I prefer to use NRPE, NSCA or check_by_ssh to check my remote hosts, and the built-in SSH seems redundant. This is just my preference.
I'm testing this on FreeBSD 7.2 (By changing the path) with a 3ware 9000 series. It seems to work fine. I'll probably use it on some CentOS 5.4 machines shortly.
Some issues:
1. I need to specify the specific Unit (e.g "check_3ware.pl --controller 0 --unit 1"), otherwise this script only checks Unit 0.
2. The script has a list of keywords for the WARNING and OK states. Anything else becomes CRITICAL. If the array shows a "DEGRADED" or OFFLINE message, this script will consider that a WARNING. Really, the script should specify OK, WARNING and CRITICAL states. Anything else should become UNKNOWN.
It's easy enough to change the OK and WARNING criteria by adding them to the @state_ok & @state_warning Perl arrays.
