Inhaltsverzeichnis
Installation von Nagios (2.6) + NRPE auf Debian Etch
Basis der Installation ist eine Virtuelle Maschine (VMware) mit einem Debian, das möglichst schmal gehalten wurde und nur die wichtigsten Funktionen, wie zum Beispiel eine Netzwerkverbindung und diverse Protokolle dafür, umfasst.
Nach den üblichen Befehlen „apt-get update“, „apt-get upgrade“ und „apt-get dist-upgrade“ hat man die vorliegende VM auf aktuellem Stand und kann sich an die Installation des eigentlichen Nagios-Systemes machen.
Zwei Pakete sind hier für die Installation von Nagios relevant, weitere Pakete sollten über die Abhängigkeiten von apt aufgelöst und direkt mitinstalliert werden:
nagios2
nagios-plugins
Jetzt geht es an die wesentlich aufwendigere Konfiguration von Nagios, bis man dann an die ersten Hosts und Services für das Monitoring denken kann.
Konfiguration von Nagios
Normalerweise sollte das Debian-Paket von Nagios bei der Installation bereits einen Benutzer und eine Gruppe namens „nagios“ anlegen. Sicherheitshalber sollte man das überprüfen und diese ggf. selber anlegen.
Ebenso sollte der Benutzer des spätestens mit Nagios installierten Apache2-Servers bereits Mitglied der Gruppe nagios sein, findet sich dort kein Benutzer www-data (Achtung, so heißt dieser Benutzer nicht in allen Linux-Distributionen, weit verbreitet ist auch apache als Benutzer), wäre dieser noch der Gruppe hinzuzufügen.
Für eben diesen Apache2 sollte Nagios auch eine .conf Datei mitliefern:
/etc/nagios2/apache2.conf
In dieser werden wichtige Aliase definiert, damit der spätere Zugriff über einen Browser auf Nagios überhaupt möglich wird. Diese Einträge sind normalerweise vorhanden und sollten auch auf die vorhandene Ordnerstruktur passen. Die Datei muss im sites-enabled Ordner des Apache2 verlinkt sein (sollte Nagios auch erledigen):
/etc/apache2/sites-enabled/001-nagios
(ln –s 001-nagios /etc/nagios2/apache2.conf ; Aufruf aus /etc/apache2/sites-enabled/)
Bis hierhin sollte bei der Installation unter Debian alles automatisch gelaufen sein. Die folgenden Ordner sind für die weitere Konfiguration von Bedeutung:
/etc/nagios2/ Hauptordner mit den wichtigsten Config-Dateien
/etc/nagios2/conf.d/ Config-Dateien (zB für Hosts oder Services)
/usr/lib/nagios/plugins/ Hier liegen die Perlskripte zu den Plugins
/etc/nagios-plugins/config/ Config-Dateien der Plugins
Eine zentrale Datei für Nagios, die gewissermaßen als Schaltzentrale fungiert, ist die Hauptkonfigurationsdatei von Nagios:
/etc/nagios2/nagios.cfg (im weiteren einfach nagios.cfg genannt)
Hier legt man gewissermaßen grundlegend fest, was Nagios kann oder darf und wo es weitere Config-Dateien sucht.
Bislang war die Installation recht einfach und man sollte nun schon mittels eines Browsers erste Ergebnisse erkönnen können unter der URL:
http://nagios-server/nagios2
Noch ist diese Seite für jeden zugänglich, was auf Dauer nicht Sinn der Sache ist, daher sollte man jetzt Benutzer anlegen, die auf Nagios zugreifen dürfen.
Hierzu liefert der Webserver einen Befehl, der eine Datei mit den berechtigten Benutzern anlegt bzw. ergänzt. Findet sich noch keine Datei namens htpasswd.users im Nagios-Hauptverzeichnis, kann diese mitsamt einem ersten Eintrag so erstellt werden:
htpasswd –c /etc/nagios2/htpasswd.users nagiosadmin
Nun wird man nach einem Passwort für den Benutzer gefragt, welches dann verschlüsselt in der gleichen Datei mit abgelegt wird. Für weitere Benutzer einfach das Flag „-c“ weglassen und statt nagiosadmin den gewünschten Benutzer eintragen.
Um nun den Zugriff auf authentifizierte Benutzer zu begrenzen, muss in der Datei
/etc/nagios2/cgi.cfg
das Flag
use_authentication=0
auf 1 gesetzt werden.
Jetzt sollte die obige URL nur noch mittels der eingetragenen Benutzer-Passwort-Kombination die Monitoring-Seite von Nagios öffnen, die natürlich recht noch leer ist, da bisher kaum Hosts oder Services zur Überwachung definiert wurden.
Die Datei cgi.cfg bietet dabei noch weitere Möglichkeiten, den Zugriff auf Nagios zu reglementieren, zum Beispiel wer die Konfiguration per Browser einsehen darf oder vieles mehr. Die einfachste Variante wäre hier, die Benutzer-Passwort-Kombination auf Systemadministratoren zu begrenzen und in cgi.cfg bei allen Punkten ein „*“ einzutragen, womit nur angemeldete Nutzer diese Punkte dann sehen dürfen. Wird eine ausgefeiltere Rechteverwaltung gewünscht, sollte man sich die Hilfetexte in der Datei durchlesen und dann den verschiedenen Rechten die passenden Benutzer zuteilen. Hier kann man auch generell Zugriffe sperren, indem man einfach nichts hinschreibt, dann hat niemand die Berechtigung, die betreffende Funktion einzusehen.
Zu diesem Zeitpunkt sollte also ein funktionierendes Nagios stehen, dass nur für dazu berechtigte Benutzer die für diese zugänglichen Daten anzeigt.
Allerdings sind bisher noch kaum Daten vorhanden, lediglich der Gateway und der localhost (also der Nagios-Rechner) mit wenigen Standardservices wird automatisch angelegt und überwacht.
Der nächste Punkt wäre also, zunächst Hosts und Services zu definieren, die überwacht werden sollen.
Host- und Servicedefinitionen
Im Ordner /etc/nagios2/conf.d findet man einige Konfigurationsdateien und vor allen Dingen auch jeweils ein Template für die Host- und Servicedefinition.
Schauen wir uns zunächst diese Templates an.
generic-host_nagios2.cfg:
#Generic host definition template - This is NOT a real host, just a template! define host{ name generic-host ; The name of this host template notifications_enabled 1 ; Host notifications are enabled event_handler_enabled 1 ; Host event handler is enabled flap_detection_enabled 1 ; Flap detection is enabled failure_prediction_enabled 1 ; Failure prediction is enabled process_perf_data 1 ; Process performance data retain_status_information 1 ; Retain status information across program restarts retain_nonstatus_information 1 ; Retain non-status information across program restarts check_command check-host-alive max_check_attempts 10 notification_interval 0 notification_period 24x7 notification_options d,u,r contact_groups admins register 0 ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL HOST, JUST A TEMPLATE! }
Wie man sieht werden hier einige Flags gesetzt, die mit Verwendung dieses Templates bei der Definition eines Hosts für diesen automatisch gelten. An diesen Einstellungen muss nichts verändert werden, nur wenn man gewisse Daten für manche Hosts abschalten will, sollte man ein weiteres Template erstellen, indem die gewünschten Flags auf 0 gesetzt werden. Auch möglich wäre es über contact_groups zu verschiedenen Hostgruppen verschiedene Kontakte einzutragen, sprich ein Template mit admins, ein weiteres zum Bespiel mit admins und privilegierten Benutzern, die einen Teil einsehen dürfen oder viele Möglichkeiten mehr.
Eine Hostdefinition könnte dann zum Beispiel so aussehen:
define host{ use generic-host ; Name des Templates host_name mein_Host ; Name des Rechners im Netzwerk address IP ; optional die IP-Addresse des Rechners im Netz }
Unschwer erkennbar ist diese Definition sehr übersichtlich und erfordert theoretisch nur die Angabe des Host-Namen. Um eventuellen DNS-Problemen aus dem Weg zu gehen, kann man die IP-Addresse noch mit angeben, könnte dann aber auf Probleme stoßen, wenn diese nicht statisch bzw. fest zugewiesen sind.
Und nun das etwas spannendere service-Template:
generic-service_nagios2.cfg
# generic service template definition define service{ name generic-service ; The 'name' of this service template active_checks_enabled 1 ; Active service checks are enabled passive_checks_enabled 1 ; Passive service checks are enabled/accepted parallelize_check 1 ; Active service checks should be parallelized (disabling this can lead to major performance problems) obsess_over_service 1 ; We should obsess over this service (if necessary) check_freshness 0 ; Default is to NOT check service 'freshness' notifications_enabled 1 ; Service notifications are enabled event_handler_enabled 1 ; Service event handler is enabled flap_detection_enabled 1 ; Flap detection is enabled failure_prediction_enabled 1 ; Failure prediction is enabled process_perf_data 1 ; Process performance data retain_status_information 1 ; Retain status information across program restarts retain_nonstatus_information 1 ; Retain non-status information across program restarts notification_interval 0 ; Only send notifications on status change by default. is_volatile 0 check_period 24x7 normal_check_interval 5 retry_check_interval 1 max_check_attempts 4 notification_period 24x7 notification_options w,u,c,r contact_groups admins register 0 ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL SERVICE, JUST A TEMPLATE! }
Mit diesem Template definiert man wieder die Standardflags für jeden Service, der dieses Template verwendet. Interessant ist hierbei zum Beispiel normal_check_interval, womit festgelegt wird, wie oft Nagios eine Abfrage zum betreffenden Dienst durchführt. Die Angabe von 5 hier bedeutet, dass das in nagios.cfg festgelegte Intervall (Standard 60 Sekunden) 5 mal abgewartet wird, vor einer neuen Abfrage (also 5 Minuten). Für die meisten Anwendungen ist das ein sehr sinnvoller Wert, wenn man aber später Netzwerkkarten oder Switch-Ports überwachen möchte, wird mit einem 5-Minuten-Intervall die Kurve sehr verflacht und man verpasst etwaige Spitzen. Hier würde sich das Anlegen eines weiteren Templates mit einem 1-Minuten-Intervall (also normal_check_interval = 1) lohnen.
Eine Service-Definition könnte dann so aussehen:
define service{ use generic-service ; Name des Templates host_name mein_Host ; Name des Rechners im Netzwerk service_description mein Service ; Name des Services check_command check_Befehl ; Auszuführender Befehl für diesen Service }
Zu beachten ist hierbei, dass Nagios die Befehle erst kennen muss, bevor sie ausgeführt werden können, dazu jedoch etwas später mehr.
Für beide Templates noch interessant ist sicherlich die Kontaktgruppe, sprich wer eine E-Mail bekommen soll, wenn sich bei einem Host oder bei einem Service etwas verändert. Für diese Benachrichtigungen sind folgende Einstellungen in beiden Templates wichtig:
notifications_enabled 1 Ohne dieses Flag werden überhaupt keine Mails erzeugt
notification_interval 0 Setzt man hier eine 1, bekommt man konstant Mails, bei 0 nur, wenn sich der Zustand ändert
notification_period 24×7 Legt den Zeitraum fest, in dem man benachrichtigt wird. Hier 24 Stunden pro Tag und 7 Tage in der Woche
notification_options w,u,c,r Legt fest, bei welchen Zustandsänderungen eine Mail erzeugt wird (w=warn, c=critical, d=down, u=unreachable und r=restart)
contact_groups admins Legt die Kontaktgruppe fest (Verwaltung in contacts_nagios2.cfg)
Wichtig für die Definitionen von Hosts und Services ist, dass sie in einem Ordner liegen, der als config-dir in nagios.cfg eingebunden ist. Empfehlenswert ist hier die Verwendung des Ordners /etc/nagios2/conf.d . Dort legt man am besten für jeden Host eine eigene Datei mit sprechendem Namen (zum Beispiel mein_Host.cfg) an und definiert in dieser sowohl den Host als auch die zu diesem Host zugehörigen Services, die überwacht werden sollen.
Nun können also Hosts angelegt und für diese Hosts Services definiert werden, allerdings weiß Nagios noch nicht, welche Befehle es eigentlich kennt (außer einigen Standardbefehlen) und auch die bereits angesprochenen Mails versendet es noch nicht. Bis Nagios soweit läuft, werden die Mails auch noch nicht aktiviert, da es mehr als nervig ist, wenn Nagios während Installation und Konfiguration dauernd Mails schickt.
Woher nimmt also Nagios das Wissen um seine Befehle?
Für die mit Nagios standardmäßig mitgelieferten Befehle findet sich die Datei command.cfg im Nagios-Hauptordner, dazu kommt der Config-Ordner der Plugins, wo für jeden mit den Plugins mitgelieferten Befehl eine eigene Config-Datei existiert. In diesen Dateien werden die in Nagios verfügbaren Kommandos definiert oder anders gesagt, festgelegt, was Nagios kann. Natürlich muss zu jedem dieser Kommandos auch ein Perl-Skript existieren, in dem steht, was das Kommando eigentlich macht. Diese Skripte werden hier als Blackbox behandelt, es interessiert lediglich, wie sie aufgerufen werden und was sie dabei als Wert zurückgeben. Für fortgeschrittene Benutzer könnte es interessant werden, später eigene Plugins zu schreiben, dies soll aber hier nicht das Thema sein.
Eine solche Kommando-Definition sieht dann zum Beispiel so aus:
define command{ template <templatename> ; möglich, wird aber fast nicht verwandt name <objectname> ; Alias für command_name command_name <commandname> ; Name für Kommando command_line <commandline> ; eigentlicher Befehl }
Im Regelfall wird eine solche Kommando-Definition so aussehen, dass nur ein Kommando-Name und die Kommandozeile definiert werden, dies ist völlig ausreichend. In der Kommandozeile ruft man nun das gewünschte Perlskript auf und legt fest, welche Argumente und auch wie viel Argumente dem Skript übergeben werden sollen, Zusätzlich können diese Argumente entweder fix hier vorgegeben werden oder auch variabel durch den Aufruf in der Service-Definition.
Ein Beispiel:
command_line /usr/lib/nagios/plugins/check_load --warning=$ARG1$,$ARG2$,$ARG3$ --critical=$ARG4$,$ARG5$,$ARG6$
Mit dieser Kommandozeile wird das Plugin „check_load” aufgerufen, das zum Überprüfen der Prozessorlast eines Systems geeignet ist. Typische Argumente für dieses Plugin sind die Flags warning und critical, denen hier jeweils 3 Werte in der Servicedefinition zugewiesen werden müssen. In diesem Fall sind die Argumente als Grenzwert zu sehen, ab wann das Plugin nicht mehr „OK“ als Antwort liefert, sondern eben „Warning“ oder „Critical“. Im Plugin wird dabei für drei verschiedene Durchschnittswerte unterschieden, die Auslastung über 15 Minuten, 5 Minuten und 1 Minute. Für jeden dieser Werte kann man in einer Servicedefinition Grenzwerte festlegen.
Jedes Plugin hat natürlich andere Argumente und Flags und so muss man sich für jeden Befehl selber überlegen, welche Argumente und auch wie viele man mitgeben möchte. Manches Mal ist es sogar sinnvoll, ein Kommando mehrmals zu definieren, um diesem zum Beispiel nur ein Argument oder aber auch mal mehrere mitgeben zu können. Für die mit Nagios und den Plugins mitgelieferten Skripte gibt es jedenfalls sehr brauchbare Kommandodefinitionen, die man sich allerdings kurz anschauen sollte, um in einer Servicedefinition einen korrekten Aufruf zu ersetllen.
Noch ein kurzes Beispiel, wie dieser bei der obigen Kommandodefinition aussehen könnte:
check_command check_load!5.0!4.0!3.0!10.0!6.0!4.0
Nagios vergleicht nun diese Zeile mit der obigen Definition von check_load und baut dann den gewünschten Befehl zusammen. Konkret würde Nagios hier also erst „/usr/lib/nagios/plugins/check_load” hinschreiben, dann als weiteren fixen Bestandteil der Definition „–warning=“ dazusetzen. Nun kommt ein variabler Teil, nämlich das erste Argument. Dieses findet sich, getrennt durch Ausrufezeichen, nach dem Befehlsausfruf, hier also 5.0. So geht es dann weiter, bis Nagios die Definition voll hat. Würde man also mehr Argumente mitgeben, hätte das keinen Effekt, da Nagios genau 6 Argumente erwartet, weitere ignoriert und zu wenige anmeckert. Wenn also ein Befehl um Argumente erweitert werden soll, darf man nicht vergessen, die Definition anzupassen, sonst verschwendet man eventuell einiges an Zeit bei der Fehlersuche.
Ein Blick in den Browser offenbart, dass Nagios einige Grundfunktionen auf dem lokalen Rechner (also dem, auf dem Nagios installiert ist) bereits überwacht. Die dazu passende Konfigurationsdatei ist
/etc/nagios2/conf.d/localhost_nagios2.cfg
Man kann nun weitere Services für den lokalen Rechner definieren und diese werden dann automatisch (nach einem Restart des Nagios-Dienstes mittels /etc/init.d/nagios2 restart) angezeigt.
Allerdings können die meisten dieser Befehle tatsächlich nur auf einer lokalen Maschine ausgeführt werden, da aber im Regelfall auch andere Rechner überwacht werden sollen, braucht es ein Tool, dass diese Befehle auf einem entfernten Rechner ausführt.
NRPE (Nagios Remote Plugin Executor)
Wie bereits erwähnt, können die (Perl)skripte der Nagios Plugins nur auf dem lokalen Rechner ausgeführt werden. Ein Aufruf mit einem anderen Host ist zwar möglich, liefert aber trotzdem die gleichen Werte wie der lokale Rechner zurück. Man benötigt also ein Tool, mit dem ein entfernter Aufruf möglich ist: NRPE.
Damit NRPE funktioniert, muss auf dem Zielrechner SSH installiert sein, was normalerweise der Fall ist. Zusätzlich müssen natürlich die Plugins auch auf dem Zielrechner verfügbar sein, dazu kommen dann noch 2 Pakete zum eigentlichen Betrieb von NRPE.
Es wird bei dem Zielrechner wieder von einem Debian-System ausgegangen, für andere System muss man die folgenden Vorgänge entsprechend adaptieren und anpassen.
Der erste Schritt zur Überwachung eines entfernten Rechners wäre wie gesagt, das Überprüfen, ob SSH installiert ist. Da dies mit einer Debian-Grundinstallation installiert wird, wird hier nicht näher darauf eingegangen.
Weiter geht es mit der Installation der Nagios-Plugins, wobei Installation hier ein großzügiger Begriff ist, denn es werden lediglich die Pakete an die passenden Stellen entpackt und die Config-Dateien angelegt, ein Dienst wird dabei nicht gestartet. Die Installation erfolgt dabei analog dem Nagios-Rechner mit:
apt-get install nagios-plugins
Jetzt werden noch zwei Pakete für NRPE benötigt:
nagios-nrpe-plugin
nagios-nrpe-server
Nach der Installation mittels apt-get wird auf dem Zielrechner automatisch ein Dienst namens nagios-nrpe-server (zu finden in /etc/init.d) gestartet. Zusätzlich gibt es auch eine zentrale Konfigurationsdatei, die man nach seinen Wünschen anpassen kann und auch muss:
/etc/nagios/nrpe.cfg
Anmerkung (26.02.2008):
Seit einiger Zeit wird bei der Installation der Pakete
nagios-plugins
nagios-nrpe-plugin
nagios-nrpe-server
auch Nagios2 selber mit installiert und als Dienst gestartet.
Dies kann und sollte man wieder abschalten. Dazu zunächst Nagios2 stoppen (/etc/init.d/nagios2 stop) und dann die Verweise in den Runlevel-Ordnern entfernen, damit ein Reboot nicht automatisch wieder Nagios2 startet:
update-rc.d -f nagios2 remove
Danach startet Nagios2 nicht mehr automatisch (außer man führt ein Update der Pakete durch).
Eine eventuell sauberere Lösung oder eine Deinstallation von Nagios2 wurde noch nicht getestet.
/Anmerkung
Die in dieser Datei gemachten Einstellungen kann man bedenkenlos übernehmen, einzig die ziemlich am Ende stehende Liste der Kommandos sollte entsprechend den eigenen Wünschen bearbeiten und ergänzen. Alternativ könnte man auch, wie auf dem Nagios-Rechner, jede dieser Kommandodefinitionen in eine eigene Datei auslagern und diese Datei oder Ordner in nrpe.cfg verlinken. Da dies aber die Übersichtlichkeit eher verringern als fördern würde, sollte man die Befehle lieber an dieser Stelle zentral deklarieren. Dazu bieten sich zwei Möglichkeiten an. Zunächst kann man Befehle mit fixen Argumenten definieren und erlaubt dem Nagios-Rechner so nur einen ganz bestimmten Aufruf, oder aber man erlaubt das Mitschicken eines oder mehrerer Argumente und passt die Deklaration entsprechend an. Für welche Variante man sich entscheidet, ist eigentlich egal, aber es gibt einige Überlegungen, die das Mitschicken von frei wählbaren Argumenten als Sicherheitsrisiko erachten, da dieser Befehl letztlich von jedem Rechner aus verfügbar ist, auf dem Nagios installiert wurde. Es wird daher empfohlen, jeden Befehl explizit auszuformulieren und bei nötigen Mehrfachaufrufen die Befehlsnamen zu variieren oder aber auf die später erklärte Variante mit SNMP auszuweichen. Im Regelfall sollten solche mehrfach Befehle eher selten auftreten.
Wenn man sich nun die bereits vorhandenen Standardbefehle in der Datei anschaut, erkennt man, dass die Deklaration ein wenig anders aussieht, als dies beim Nagios-Rechner erläutert wurde:
command[check_load]=/usr/lib/nagios/plugins/check_load -w 15,10,5 -c 30,25,20
Mit „command” wird in der Datei deutlich gemacht, dass eine Kommandodefinition folgt. In den eckigen Klammern steht dann, wie dieser Befehl aufgerufen wird, hier wäre das also „check_load“, danach folgt die Angabe, wo das passende Perlskript zu finden ist und welche Argumente an dieses Skript übergeben werden sollen. Wie man an dem Beispiel erkennen kann, werden hier automatisch immer 6 Argumente fix mitgeschickt und der Aufruf des Befehls erfolgt also tatsächlich über NRPE nur mit „check_load“ ohne jegliche Argumentangabe. Führt man diesen Befehl also vom Nagios-Rechner aus, gibt es die gewünschte Ausgabe mit eventuellen Meldungen, wenn die Grenzwerte für warning oder critical überschritten werden.
Auf diese Weise passt man nun alle Befehle an seine eigenen Vorstellungen an und fügt etwaige weitere hinzu. Sicherheitshalber sollte man alle Befehle lokal einmal testen, ob sie auch die gewünschte Ausgabe liefern, damit man bei einer späteren Fehlersuche nicht alles noch mal prüfen muss. Ist hier alles soweit erledigt, startet man den Dienst noch einmal neu, damit alle Änderungen auch übernommen werden (das sollte man natürlich auch vor dem Testen machen, sonst funktionieren auch die Tests nicht) und wendet sich nun wieder dem Nagios-Rechner zu.
Auch hier muss man die beiden NRPE-Pakete installieren (nagios-nrpe-plugin nagios-nrpe-server), die weitere Konfiguration von NRPE wie eben auf dem entfernten Rechner entfällt hier aber, man muss lediglich eine Config-Datei für den Kommandoaufruf für NRPE definieren. Diese könnte zum Beispiel so aussehen:
# this command runs a program $ARG1$ with 2 arguments define command { command_name check_nrpe_2arg command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ -a $ARG2$ $ARG3$ } # this command runs a program $ARG1$ with 1 arguments define command { command_name check_nrpe_1arg command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ -a $ARG2$ } # this command runs a program $ARG1$ with no arguments define command { command_name check_nrpe command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ }
Man erkennt hier unschwer einen weiteren Grund, warum man auf dem entfernten Rechner die Befehle fix definieren sollte, man müsste sonst auch eine ganze Reihe von NRPE-Befehlen definieren, für jede Argumentmenge einen.
Der eigentliche Aufbau des Befehls ist schnell erklärt: Bekannt sein sollte das Gerüst ja bereits aus der Beschreibung der Nagios Konfiguration, daher wird sich auf die Erläuterung der command_line beschränkt. Die Angabe „$USER1$“ ist ein Platzhalter, der in /etc/nagios2/resource.cfg definiert ist und nichts anderes als den Pfad zum Plugin Ordner darstellt. Dort findet sich dann der Befehl „check_nrpe“ der mit NRPE installiert wurde und dessen Aufruf hier nun definitiert wird. Dieser Befehl erfordert die Angabe eines Hosts, sprich eines Zielrechners nach dem Flag „-H“ und danach mindestens ein weiteres Argument, nämlich das gewünschte Kommando, das auf dem Zielrechner ausgeführt werden soll, kenntlich durch das Flag „-c“. Soll nun diesem entfernt aufgerufenem Kommando noch Argumente übergeben werden (es wurde also mit variablen Argumenten definiert), so geschieht dies nach dem Flag „-a“.
Damit ist man jetzt in der Lage, auch bei anderen Rechnern zu schauen, wie denn die CPU ausgelastet ist oder wie viele Benutzer sich dort angemeldet haben. Ein solcher Befehlsaufruf in einer Config-Datei könnte dabei zum Beispiel so aussehen:
define service{ use generic-service ; Name of service template to use host_name Zielhost service_description Current Load ; Name of service check_command check_nrpe!check_load }
Diese Servicedefinition versucht nun mittels NRPE auf dem angegebenen Zielrechner den Befehl check_load auszuführen. Da er in diesem Beispiel definiert wurde, würde der Befehl also die gewünschten Werte zurückliefern und nach einem Neustart des Nagios-Dienstes auch im Browser anzeigen.
Man kann jetzt also jeden Rechner, auf dem NRPE und die gewünschten Plugins installiert wurden, mittels Nagios überwachen.
Damit kann man schon einiges anfangen und auch sinnvoll überwachen, aber es ist zum einen recht mühsam, immer Plugins zu suchen oder auch zu schreiben, um einen zusätzlichen Wert oder Dienst oder Host zu überwachen, vieles kann man hier mit SNMP bereits abfragen und der Befehl check_snmp ist auch schon Teil des Nagios-Systems. Wie dieser allerdings zu installieren und zu nutzen ist, wird Teil einer anderen Dokumentation werden. Ebenso möchte man sicherlich nicht nur punktuelle Daten haben, wie sie Nagios liefert, sondern auch eine graphische Auswertung dieser Daten über einen gewissen Zeitraum. Hier wird dazu nagiosgrapher eingesetzt und auch dazu wird es eine separate Dokumentation geben.
Der letzte hier noch fehlende Punkt ist die bereits angesprochene Mail-Benachrichtigung.
Mails in Nagios einrichten
Vorbedingung für diese Funktion ist ein funktionierendes Mailprogramm auf dem Rechner, das Mails erzeugen kann. In der hier vorliegenden Debian-Installation wurde postfix als Verbindungsstelle zu einem Relay-Server aufgesetzt. Natürlich sollten in den Templates spätestens jetzt wieder die Flags für die Benachrichtigung aktiviert werden, wenn sie überhaupt deaktiviert wurden.
Nun müssen die Kontakte und Kontaktgruppen für Nagios definiert werden, die zentrale Datei dafür ist hier:
/etc/nagios2/conf.d/contacts_nagios2.cfg
Ein Kontakt könnte dabei zum Beispiel so aussehen :
define contact{ contact_name root alias Root service_notification_period 24x7 host_notification_period 24x7 service_notification_options w,u,c,r host_notification_options d,r service_notification_commands notify-by-email host_notification_commands host-notify-by-email email root@localhost }
Dieser Kontakt wird intern als „root” angesprochen und wird nach außen als „Root” angezeigt. Er würde mit den eingetragenen Zeitperioden sowohl über Veränderungen bei Hosts, als auch bei Services immer informiert werden, die dabei berücksichtigten Veränderungen wären „warning“, „unknown“, „critical“ und „restart“ bei Services und „down“ und „restart“ bei Hosts. Die verwendeten Kommandos sind Standard-Kommandos von Nagios und in /etc/nagios2/commands.cfg definiert. Zuletzt wird eine Mailadresse angegeben, die natürlich auch existent sein sollte. An diese Adresse wird dann in Zukunft eine Mail verschickt, wenn ein Service oder Host seinen Zustand von OK auf einen der hier angegebenen Zustände ändert, ebenso, wenn er von diesem Zustand wieder zu OK wechselt, sofern für den betreffenden Service oder Host in dessen Definition angegeben ist, dass dieser Kontakt eine Benachrichtigung erhalten soll. Hier kommen wieder die Templates ins Spiel, in denen Kontaktgruppen angegeben sind, die eine Benachrichtigung erhalten sollen. Entweder ergänzt man hier die Benachrichtigung an einzelne Kontakte, oder aber man fasst seine Kontakte in Kontaktgruppen zusammen, was vermutlich eine sinnvollere Verwaltung ermöglicht.
Kontaktgruppen werden in der gleichen Datei definiert, wie die Kontakte und könnten zum Beispiel so aussehen:
define contactgroup{ contactgroup_name admins alias Nagios Administrators members root }
Da in den Kontakten selber schon die grundlegenden Dinge für einen Kontakt festgelegt wurden, reicht es für die Gruppe, einen internen Ansprechnamen, dazu einen Alias und die Mitglieder zu definieren.
Nimmt man sämtliche Beispiele für die Templates und Definitionen zusammen, würde jetzt an die Mail-Adresse „root@localhost“ jedes Mal eine Mail verschickt, wenn sich ein Service oder Host in seinem Zustand ändert, da in den Templates die Gruppe „admins“ als Kontaktgruppe eingetragen ist, diese wiederum hat als Mitglied den Kontakt „root“, dessen Mailadresse eben die genannte ist.
Natürlich muss man dies nun auf seine eigenen Bedürfnisse anpassen.
