Monitoring OpenStack Swift With Opsview
As a starting point we’ll perform a ‘front door’ check as this should work no matter what Swift implementation you are using.
Note that we're using Authentication version 2.0 with Keystone rather than tempauth.
The following assume you already have both Opsview Server and OpenStack Object Storage (Swift) configured and running.
Pre-requisite set up tasks
The machine running the check needs to have a Swift client and an Opsview Agent. If you plan to monitor from a Swift proxy server you should only need the latter; if you plan to execute the checks from your Opsview server, then you’ll need the former.
Installing the Swift client
This relies on having Python installed – grab the source from:
https://github.com/openstack/python-swiftclient.git
https://github.com/openstack/python-keystoneclient.git
sudo python setup.py install
(for both)
Installing the Opsview Agent on Ubuntu
echo "deb http://downloads.opsview.com/opsview-core/latest/apt precise
main" > /etc/apt/sources.list.d/opsview-core.list
apt-get update
apt-get install opsview-agent
Obtaining the check
The plugin details are here:
http://exchange.nagios.org/directory/Plugins/Clustering-and-High-2DAvailability/check_swift/details
The direct download link:
http://exchange.nagios.org/components/com_mtree/attachment.php?link_id=3589&cf_id=30
Place this into /usr/local/nagios/libexec (on the Opsview Agent) and make the file executable (
chmod +x check_swift
) and owned by nagios (
chmod nagios:nagios check_swift
).
Environment variables
If you don’t already have the ST_AUTH (tenant), ST_USER and ST_KEY environment variables set, then you may want to modify the check accordingly (as per the following diff):
diff check_swift.orig check_swift
52c52
< export OS_AUTH_URL=$OPTARG
> export ST_AUTH=$OPTARG
55c55
< export OS_USERNAME=$OPTARG
---
> export ST_USER=$OPTARG
58c58
< export OS_PASSWORD=$OPTARG
---
> export ST_KEY=$OPTARG
Setting up NRPE
Whilst you could run the check from your Opsview server (if you install the Swift client), it is’d more likely it would be executed on an Opsview Agent via NRPE.
Therefore we need to add a service check command to the NRPE configuration on the Opsview Agent:
echo "command[check_swift]=/usr/local/nagios/libexec/check_swift \$ARG1\$" >> /usr/local/nagios/etc/nrpe_local/override.cfg
/etc/init.d/opsview-agent restart
Configuring the check
On your Opsview server you’ll need to define a new Service Check, Figure 1 shows a completed example.
Figure 1 – Service check definition
If you like to copy & paste, the arguments to check_nrpe are:
-H $HOSTADDRESS$ -c check_swift -a '-V 2 -U admin:admin -A
http://127.0.0.1:5000/v2.0/ -K secrete -c container'
Substitute the values as applicable or override them at the host-level.
The check in action
Figure 2 shows the host-level view of the service check (note that it appears to be ignoring the -c container value).
Figure 2 – Service check results
There you go, quick and easy basic monitoring of OpenStack Swift.
Troubleshooting
If it doesn’t work, first check you can perform an upload using the swift client:
swift -V 2 -U admin:admin -A http://127.0.0.1:5000/v2.0/ -K secrete upload
container check_swift
The second test is to verify the Nagios plugin returns a zero exit code:
check_swift -V 2 -U admin:admin -A http://127.0.0.1:5000/v2.0/ -K secrete
-c container
echo $?
Note that the plugin redirects output to /dev/null so you may need to tweak a copy of the script so that you can see the swift error messages if this step fails.
Lastly test NRPE:
check_nrpe -H localhost -c check_swift -a '-V 2 -U admin:admin -A
http://127.0.0.1:5000/v2.0/ -K secrete -c container -s 128'
Posted by: Brian King
