Bevor man anfängt, blind neue Commands für Nagios zu definieren, sollte man die zugrundeliegenden Plugins erst einmal manuell testen.
Dabei ist darauf zu achten, das man den Test genauso durchführt wie Nagios das tun würde.
root angelegt, als user nagios nicht mehr überschrieben werden können. ./plugin_name testen. Nagios tut dies auch nicht. Plugins immer mit vollständigem Pfad (z.B. /usr/local/nagios/libexec/mein_plugin) aufrufen. Jedes unter Unix gestartete Programm beendet sich mit einem Returncode, so auch die Nagios Plugins.
Die Variable $? enthält immer den Status des letzten ausgeführten Befehls. Somit liefert ein
echo $?
nach dem Test eines Plugins den Returncode.
Wenn man sich nun sein neues Plugin mit seinen individuellen Parametern zusammengestellt hat, kann man sich mit der command definition für Nagios beschäftigen.
Bsp: check_http gegen eine HTTP Seite als Virtual Host, gegen eine URI. Desweiteren soll das Command auf einen Redirect des Webservers mit einem CRITICAL reagieren.
Nach recherche der Hilfe zu check_http mittels check_http –help wissen wir nun, dass das command so aussehen sollte:
/usr/local/nagios/libexec/check_http -H www.test.org -I 192.168.0.1 -u "/test/case.php" --onredirect=critical
Zerlegen des CLI Commands:
Nagios kennt in den meisten Fällen bereits den Pfad zum Pluginsverzeichniss über das Macro $USER1$.
Um diese Command Definition später noch für andere Websites verwenden zu können möchten wir den Hostname und die URI dynamisch aus der Servicedefinition und die IP Adresse vom zugehörigen Host bekommen.
Für Nagios ergibt sich dann folgendes Command:
define command{
command_name check_http_critical_redirect
command_line $USER1$/check_http -I $HOSTADDRESS$ -H $ARG1$ -u "$ARG2$" --onredirect=critical
}
Die Servicedefinition könnte dementsprechend so aussehen:
define service{
host_name webserver_1
service_description www.test.org Redirect Error
...
...
check_command check_http_critical_redirect!www.test.org!/test/case.php
...
}