Sometimes when testing a Nagios Plugin on the command line, it’s useful to know the exit code.
You can always use echo $?, but that becomes tedious if you have to type it often.
Additionally you have to remember what the exit codes mean.
The following snippet adds a prompt that changes colour according to the exit code; 0 is green, 1 is yellow, 2 is red and 3 is grey. This makes it easy to see at a glance what the exit code was.
Add the following to a file e.g. debug.sh
export colormap=([0]=32 [1]=33 [2]=31 [3]=37)
export PS1='\[\e[${colormap[$?]}m\]\u@\h:\w\$\[\e[30m\] '
Then source it in .bashrc or on the command line with
source debug.sh
and enjoy.
nagios@localhost:~$ ./check_plugin 192.168.0.1
OK - 1824 bytes in 0.002 seconds
nagios@localhost:~$ ./check_plugin 192.168.0.2
Unable to open TCP socket
nagios@localhost:~$
…und hier gibt’s wieder ein Plugin aus einem Kundenprojekt. Das check_sepsesam Plugin ermöglicht die Überwachung des Backupsystems Sesam des Herstellers SEP.
Das Plugin kann via SSH oder NRPE abgefragt werden und erlaubt die Auswertung der letzten Backup Tasks gefiltert auf Hosts und Tasks. Es erlaubt außerdem die Angabe spezifischer Host- und Tasklisten sowie die Einschränkung auf angegebene Zeiträume um die mehrzeilige Ausgabe des Plugins zu konfigurieren. Auf Wunsch kann die Ausgabe der Performancedaten auch unterdrückt werden.
Es ist wie immer auf www.netways.org und MonitoringExchange zu finden.
So you’ve covered the Data Centre in temperature sensors, and added them into your Nagios / Icinga monitor. You’ve configured the monitoring server to send alerts when things get too hot and everything works perfectly. You proudly explain how it all functions to anyone who will listen.
Unfortunately your colleagues aren’t impressed… What you need is some pretty graphics!
WE PROUDLY PRESENT
The Generate-a-Heatmap-with-data-from-the-NDO-Database Addon for Nagios / Icinga, otherwise known as heatmap.
It’s a pretty little drag-n-drop AJAXy thing that certainly won’t replace a proper Data Centre CFD Model, but it looks realistic enough to show your co-workers.
Parts of the first version were sponsored by Wilken-Group.
Have fun
Recently I visited one of our Austrian customers in the city of Schwaz. Tyrolit, part of the Swarovski Group and one of the world’s leading suppliers of abrasives, are based there.
In common with most large companies their IT department needs to respond 24×7 to any serious problems, and they have a weekly on-call rota for the system administrators.
As always with Nagios, there is more than one way to solve this – one of the most popular being to send all alerts to a single email address and/or ‘phone number which is passed to whomever has the rota. It’s a simple and fairly easy way to manage the problem, especially if you use one of the managed group-call-number services available on the market (e.g. Vodafone CorporateVPN). One of the biggest disadvantages however is that you can no longer find out who received the alert. Plus you are adding another point-of-failure into the notification chain.
For some customers I would recommend handing all notifications to an external handler (e.g. NoMa), which offers a simple configuration GUI; but it wasn’t suitable in this case – so we decided to send the alerts to a Nagios contact group and built a small webpage to manage this group and create Nagios configuration files. With a couple of mouse clicks the Admin-on-Call can be changed.
This is one of the strengths of Nagios. The ability to easily expand the functionality with a script if need be. Which reminds me: I must upload it to www.NagiosExchange.org …
Last 5 Comments