Alte Nagios Anleitung
Inhaltsverzeichnis
Nagios - Netzüberwachung global
Einführung
In der heutigen Zeit werden viele Dienste verwendet, die in reglmäßigen Abständen auf ihre Funktion hin überprüft werden wollen, bevor der Kunde sich beschwert. Zu den am meist verwendeten gehören Mail (SMTP/POP/IMAP) als auch DNS, HTTP od. auch der Druckerspooler. Selbstverständlich gehören auch CPU Last, Speicherverbrauch oder der verbleibende Speicherplatz mit zu den zu überwachenden Aufgaben eines jeden Administrators.
Da dies in der Regel sehr viel Zeit und auch Geld kostet, überlässt man diese wiederkehrenden Aufgaben einer Software, die entsprechende Tests durchführt und bei Fehlern die Administratoren benachrichtigt, via Mail, Pager od. SMS. Für eben diese Aufgabe entstand die Software Nagios, die auch früher unter dem Namen Netsaint firmierte. Eine gute Zusammenfassung bietet Wikipedia:
Die zu überwachenden Hosts und Services werden mittels Konfigurationsdateien konfiguriert und NAGIOS bekannt gemacht. Das Zusammenfassen in Gruppen für einzelne Hosts, Services und Kontaktgruppen ist ebenfalls möglich. Für die Administration aller Konfigurationsdateien stehen zahlreiche Tools zur Verfügung.
Nagios kann den Status verschiedener Dienste (z.B. SSH, FTP, HTTP) sowie den Festplattenplatz, Speicher- und CPU-Auslastung, Uptime usw. über diverse Module (Plugins) abfragen und auswerten. Da die verwendeten Testmethoden unabhängig vom verwendeten Protokoll sind, ist NAGIOS in der Lage beliebige Hosts bzw. Services unabhängig vom Betriebssystem zu überwachen. Es ist damit sogar möglich Umweltbedingungen (z.B. Temperaturwerte, Luftfeuchtigkeit, Stände von Flüssigkeitstanks, ...) zu überwachen.
Sobald ein Dienst einen kritischen Wert (dessen Grenzwerte man einstellen kann) erreicht oder gar nicht mehr verfügbar bzw. erreichbar ist, alarmiert Nagios die Kontaktpersonen über beliebige Kanäle (z.B. E-Mail, SMS, Pager, IM Messages, Telefonanrufe...) Eine entsprechende Schnittstelle zu den einzelnen Services ist nicht in Nagios enthalten. Diese Schnittstellen lassen sich aber sehr einfach integrieren.
Um ein NAGIOS System ausfallsicher, redundant und fehlalarmsicherer zu gestalten, gibt es die Möglichkeit des Distributed Monitoring- sowie des Redundant/Failover Monitoring Setups. Mithilfe des nrpe (Nagios Remote Plugin Executor) ist es auch möglich, Plugins auf entfernten Rechnern auszuführen, die die Ergebnisse ihrer Untersuchung an den Nagios-Server melden
In diesem HowTo werde ich aufzeigen, wie Nagios installiert und eingerichtet wird, sowie mit Hilfe von Remote Programmen die Überwachung auch von entfernten Rechnern gelingt.
Installation
- HINWEIS Da ich mir nicht gemerkt habe, welche Pakete noch installiert werden müssen, bitte ich die, die der Anleitung nachgehen, eben diese Pakete noch hier einpflegen.
Aus nachvollziehbaren Sicherheitsgründen,entschloss ich mich dazu, den Monitor Server (auf diesem Rechner wird der Nagios Daemon ausgeführt) in einen virtuellen Host zu sperren, welchen ich unter Xen vorher eingerichtet hat. Als Distribution nahm ich Ubuntu Dapper (Anmerkung: Das depbootstrap Skript von Dapper ist (derzeit) ziehmlich kaputt, es ist eine ganze Menge Handarbeit nötig, damit das System sauber funktioniert. Das von Brezzy funktioniert besser).
Um mit Nagios richtig arbeiten zu können, bedarf es eines Webservers mit PHP Unterstützung, sowie noch diverse Tools wie nslookup, f/ping etc. Diese werden später von den Plugins verwendet, um diese Dienste zu überprüfen.
- Dapper Pakete
Unter Dapper habe ich mit einem:
# apt-get install apache2 php4 php4-gd libssl-dev openssl ssh zlib1g-dev wget bzip2 cpp dns-browse g++ libgd2-dev rrdtool make perl-modules postfix telnet wget mailx
noch ein paar Pakete installiert. Da ich einen richtigen Mailserver einsetze, wird Postfix hier nur als Satelliten System eingerichtet, welcher die Mails die vom Nagios versendet werden, per Relay an den richtigen MX weiterreicht. Wer das später nachholen will, kann das per:
# dpkg-reconfigure postfix
nacholen.
- User / Gruppe
Nagios wird unter einem seperaten User laufen, von daher benötigen wir einen entsprechenden Benutzer und eine Gruppe:
# adduser --system -no-create-home nagios # addgroup --system # usermod -G nagios nagios
- Nagios selbst
Da ich die Versionsnummer unter der dicken Staubschicht von der mitgeliferten Dapper Nagios Version nicht erkennen konnte, nahm ich kurzerhand die aktuelle Version von der Webseite:
- Quellen runterladen
# mkdir /usr/src/nagios # cd /usr/src/nagios # wget http://heanet.dl.sourceforge.net/sourceforge/nagios/nagios-2.5.tar.gz # wget http://superb-east.dl.sourceforge.net/sourceforge/nagiosplug/nagios-plugins-1.4.3.tar.gz # wget http://optusnet.dl.sourceforge.net/sourceforge/nagios/nrpe-2.5.2.tar.gz # wget http://mesh.dl.sourceforge.net/sourceforge/nrpent/nrpe_nt.0.8-bin.zip # wget http://www.nagiosexchange.org/typo3conf/ext/net_nagext/pi1/download.php?file=uploads/tx_netnagext_pi1/Basic_NRPE_NT_Plugins/nrpe_nt_plugins.zip&ext=.zip
Damit haben wir nun Nagios selber, die Plugins sowie den Remote Client/Server für Linux und Windows NT (2000/XP/2003)
- Dann werden wir vorher noch schnell die Pakete entpacken:
# find *.gz -print0 -exec tar -xvzf {} \;
Nun können wir das Hauptprogramm compilieren und installieren:
# cd nagios-2.5 # ./configure # make && make install
- Die Plugins
# cd nagios-plugins-1.4.3 # ./configure # make && make install
Hier ist darauf zu achten, ob auch die benötigten Plugins übersetzt werden. Sieht das configure Script zb. kein nslookup od. dig vor, wird das check_dns Plugin nicht übersetzt. Das selbe gilt auch für check_ntp usw.
Konfiguration
Da wir uns später als User Admin in das Webinterface einloggen werden, müssten wir entsprechende Rechte vergeben. Dafür ist die Datei /usr/local/nagios/etc/cgi.cfg zuständig. Die ensprechenden Zeilen fangen mit authorized_for_ an. Dort habe ich die vorhandenen Einträge entfernt und den admin eingetragen. Eventuell müssen ein paar Kommentarzeichen entfernt werden, wenn sich die GUI über einen fehlenden Zugriff beschwert.
Apache2 Config
Bei dieser Variante wird Nagios nach /usr/local/nagios installiert. Damit wir auch auf das Webinterface zugreifen können, bedarf es kleiner Anpassungen beim Apachen. Dazu habe ich die Default Datei /etc/apache2/sites-available/default geöffnet und noch folgendes zwischen <VirtualHost *> und </VirtualHost> eingefügt:
ScriptAlias /nagios/cgi-bin /usr/local/nagios/sbin <Directory "/usr/local/nagios/sbin"> Options ExecCGI AllowOverride None Order allow,deny Allow from all AuthName "Nagios Access" AuthType Basic AuthUserFile /usr/local/nagios/etc/htpasswd.users Require valid-user </Directory> Alias /nagios /usr/local/nagios/share <Directory "/usr/local/nagios/share"> Options None AllowOverride None Order allow,deny Allow from all AuthName "Nagios Access" AuthType Basic AuthUserFile /usr/local/nagios/etc/htpasswd.users Require valid-user </Directory> |
- Webbenutzer anlegen:
# htpasswd -c /usr/local/nagios/etc/htpasswd.users admin
Ein:
# apache2ctl -t # zum überprüfen der Config # /etc/init.d/apache2 reload
und schon ist die neue Config aktiv.
Nagios Konfiguration
Um nicht soviel tippen zu müssen, setze ich zwei Links:
# ln -s /usr/local/nagios/bin/nagios /usr/local/sbin/ # ln -s /usr/local/nagios/etc /etc/nagios
Nun kopieren wir die Beispiel Dateien:
# cd /etc/nagios # for foo in *-sample; do cp $foo $(basename $foo .-sample); done
Dann bedarf es nur wenige Anpassungen in der /etc/nagios/nagios.cfg, die selbsterklärend sind.
minimal.cfg
Mit dabei gibt es eine kleine /etc/nagios/minimal.cfg Datei. Sie enthält alles wichtige, um Nagios zu betreiben. Darin werden verschiedene Dinge konfiguriert:
- Admin Gruppen
- Überwachungsperioden
- Rechner die überwacht werden wollen
- Rechnergruppen
- Kommandos die zur Verfügung stehen
- Dienste die überwacht werden sollen
- ...
Mit anderen Worten, der Dreh- und Angelpunkt einer jeden Nagios Installation. Würde man diese Konfiguration verwenden wollen, gäbe es sogleich Probleme. Denn Nagios würde sich weigern zu starten, da einige Kommandos doppelt definiert wurden.
Bei größeren Setups ist es angebracht, verschiedene Konfigurationen auszulagern, um der Übersicht Herr zu bleiben. In der nagios.cfg wird per Include die minimal.cfg eingebunden und auch die checkcommands.cfg. In der minimal.cfg müssen daher die Kommandos entfernt werden, die sich im Abschnitt # COMMANDS befinden.
Eine einfache Konfiguration sieht in diesem Fall so aus, ohne Kommentare:
define timeperiod{ timeperiod_name 24x7 alias 24 Hours A Day, 7 Days A Week sunday 00:00-24:00 monday 00:00-24:00 tuesday 00:00-24:00 wednesday 00:00-24:00 thursday 00:00-24:00 friday 00:00-24:00 saturday 00:00-24:00 } define contact{ contact_name admin alias Nagios Admin 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 admin@cst-it.dyndns.org } define contactgroup{ contactgroup_name admins alias Nagios Administrators members admin } 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 register 0 ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL HOST, JUST A TEMPLATE! } define host{ use generic-host ; Name of host template to use host_name localhost alias localhost address 127.0.0.1 check_command check-host-alive max_check_attempts 10 check_period 24x7 notification_interval 120 notification_period 24x7 notification_options d,r contact_groups admins } define hostgroup{ hostgroup_name localhost alias localhost members localhost } 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 register 0 ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL SERVICE, JUST A TEMPLATE! } define service{ use generic-service ; Name of service template to use host_name localhost service_description PING is_volatile 0 check_period 24x7 max_check_attempts 4 normal_check_interval 5 retry_check_interval 1 contact_groups admins notification_options w,u,c,r notification_interval 960 notification_period 24x7 check_command check_ping!100.0,20%!500.0,60% } define service{ use generic-service ; Name of service template to use host_name localhost service_description Root Partition is_volatile 0 check_period 24x7 max_check_attempts 4 normal_check_interval 5 retry_check_interval 1 contact_groups admins notification_options w,u,c,r notification_interval 960 notification_period 24x7 check_command check_local_disk!20%!10%!/ } define service{ use generic-service ; Name of service template to use host_name localhost service_description Current Users is_volatile 0 check_period 24x7 max_check_attempts 4 normal_check_interval 5 retry_check_interval 1 contact_groups admins notification_options w,u,c,r notification_interval 960 notification_period 24x7 check_command check_local_users!20!50 } define service{ use generic-service ; Name of service template to use host_name localhost service_description Total Processes is_volatile 0 check_period 24x7 max_check_attempts 4 normal_check_interval 5 retry_check_interval 1 contact_groups admins notification_options w,u,c,r notification_interval 960 notification_period 24x7 check_command check_local_procs!150!200!RSZDT } define service{ use generic-service ; Name of service template to use host_name localhost service_description Current Load is_volatile 0 check_period 24x7 max_check_attempts 4 normal_check_interval 5 retry_check_interval 1 contact_groups admins notification_options w,u,c,r notification_interval 960 notification_period 24x7 check_command check_local_load!5.0,4.0,3.0!10.0,6.0,4.0 } # EOF |
In diesem Beispiel wird nur festgelegt, wann geprüft wird, die Kontakt Gruppe im Falle eines Falls und der Rechner localhost.
Host Konfiguration
- Im wesentlichen besteht eine Host Konfiguration aus folgenden Zeilen:
define host { use generic-host ; Name des Templates, welches verwendet wird (aus der minimal.cfg) host_name localhost ; Name des Rechner alias localhost ; Ein eventueller Alias address 127.0.0.1 ; Die IP Adresse check_command check-host-alive ; Ist der Rechner od. Gerät auch aktiv max_check_attempts 10 ; Wie oft wird probiert, wenn etwas anderes als ein O.K zurückgegeben wird, bei 1 wird sofort ein Alarm ausgesandt check_period 24x7 ; 24 Stunden, 7 Tage die Woche wird geprüft notification_interval 120 ; Alle 120 Minuten wird eine Meldung versendet ... notification_period 24x7 ; und das 24 Stungen am Tag und 7 Tage die Woche notification_options d,r ; Meldung gibt es bei Down und Unreachable contact_groups admins ; die Kontakt Gruppe die Informiert werden soll } |
- Damit später alles übersichtlich bleibt, ordnen wir die Geräte und Rechner in Gruppen ein:
Gruppen Konfiguration
define hostgroup { hostgroup_name localhost ; Name der Gruppe alias localhost ; ein Alias members localhost ; Mitglieder der Gruppe } |
Da wir nur einen Rechner haben, würde es sich eigentlich nicht lohnen, aber ...
Service Konfiguration
- Ein Einfacher Service Test für unseren Rechner localhost:
Dazu verwenden wir am besten den PING:
define service{ use generic-service ; Name des Templates, wieder aus der minimal.cfg host_name localhost ; Der Rechner, der geprüft wird, mit dem Namen, den wir vorher vergeben haben. service_description PING ; Nennen wir dieses Test PING is_volatile 0 ; Ob dieser Service schwanken kann, in seiner Funktion (erreichbar/nicht erreichbar etc.) check_period 24x7 ; 24 Stunden, 7 Tage die Woche wird getestet max_check_attempts 4 ; 4 Mal wird probiert, wenn kein O.K zurückgeliefert wird. normal_check_interval 5 ; Alle 5 Minuten wird getestet retry_check_interval 1 ; Meldet sich der Dienst nicht, wird nach einer Minute erneut probiert. contact_groups admins ; Es werden die Admins benachrichtigt notification_options w,u,c,r ; Meldung gibt es bei Warnung, Unrechable, Critical und wenn es wieder ein O.K (recoveries) gibt notification_interval 960 ; Alle 960 Minuten wird erneut eine Meldung versendet notification_period 24x7 ; Und das alle 24 Stunden am Tag, 7 Tage die Woche check_command check_ping!100.0,20%!500.0,60% ; Das Kommando, welches ausgeführt werden soll, hier check_ping } |
Unter den Links findet sich der Eintrag, für eine vollständige Beschreibung, sämtlicher Möglichkeiten.
Makro Konfiguration
Der Eintrag check_command lässt sich auf mehrere Weisen eintragen:
check_command check_ping -H 192.168.1.2 ; mit IP-Adresse check_command check_ping -H $HOSTADDRESS$ ; Einer Variable check_command check_ping!100.0,20%!500.0,60% ; mit Makros
Mit dem letzteren lassen Argumente dem Befehl mitgeben, welche mit einem Ausrufezeichen (!) von einander getrennt werden. Der Ping Befehl würde unter der Konsole so aussehen:
/usr/local/nagios/libexec/check_ping -H 192.168.1.2 -w 100.0,20% -c 500.0,60%
In diesem Beispiel gäbe es ein Warning bei 20% Verlust und ein Critical bei 60% innerhalb der angegebenen Zeitspanne. Um ein solches Makro zu definieren, muss ein entsprechendes Kommando festgelegt worden sein. In unserem PING Beispiel, sieht das Makro so aus:
define command{ command_name check_ping command_line /usr/local/nagios/libexec/check_ping -H $HOSTADDRESS$ -w $ARG1$ -c $ARG2$ } |
Wir sehen hier also, dass automatisch der zu pingende Rechner gewählt wird (nämlich die Adresse des Rechners, welcher unter host_name eingetragen wurde) und die Werte, ab wann es ein Warning und ein Critical gibt.
Weitere fertige Makros gibt es in der checkcommand.cfg und misccommands.cfg Datei.
Entfernte Rechner überprüfen
Da es mit der Zeit langweilig werden könnte, immer nur localhost zu überprüfen, stehen uns, bzw. Nagios, diverse Varianten zur Verfügung, um auch entfernte Rechner zu überprüfen. Dazu gibt es zwei speziele Hilfsprogramme wie NRPE und NSCA und eine Variante per SSH.
Da mir persönlich NSCA einfach zu umständlich in der Handhabung war, werde ich hier nur auf NRPE und die Variante per SSH eingehen. Wer jedoch gezwungen ist, passive Checks vom Remote Rechner zu empfangen, der muss sich leider mit NSCA auseinander setzen, da nur diese Variante diese Funktion beherrscht. Was die Sicherheit betrifft, ist auch hier NSCA gegenüber NRPE im Vorteil, da dieser mehrere Verschlüsselungen bietet und ein Kennwort für den Austausch bereitstellt. NRPE kann seinen Austausch zwar verschlüsseln, aber ein Kennwort bzw. eine Authentifizierung gibt es hier nicht.
NRPE
NRPE ist vergleichsweise einfach zu installieren und zu verwenden.
Für *X Clients
Auf dem Nagios Rechner
Da wir NRPE schon heruntergeladen und entpackt haben haben, geht es schnellen Schrittes voran:
# cd nrpe-2.5.2 # ./configure --enable-ssl --with-nrpe-user=nagios --with-nrpe-group=nagios # make && make install # echo nrpe 5666/tcp >> /etc/services
Damit wird der Daemon unter dem User nagios laufen und SSL unterstützen. Wir schnüren uns ein kleines Paket, um alles beieinander zu haben:
# cd .. # wget http://www.pug.org/images/4/4b/Nrpe-server.txt # tar cvjf nrpe-und-plugins.tar.bz2 /usr/local/nagios/libexec/ nrpe-2.5.2/src/nrpe Nrpe-server.txt
Wer mit dem Gedanken spielt, die NRPE Version der jeweiligen Distribution einzusetzen, sollte darauf achten, dass es die selbe Versions Nummer führt, denn sonst gibt es Probleme beim SSL Handshake. Die Datei Nrpe-server.txt ist später umzubennen und auf dem entfernen Rechner nach /etc/init.d/nrpe-server zu verschieben. Es handelt sich um ein Startscript, welches von Debian verwendet wird.
Damit wir den entfernen Daemon abfragen können, müssen wir das entsprechende Plugin in das Plugin Verzeichnis vom Nagios kopieren, sowie noch ein entsprechendes Kommando anlegen:
# cp /usr/src/nagios/nrpe-2.5.2/src/check_nrpe /usr/local/nagios/libexec/
Das Kommando in die /usr/local/nagios/etc/checkcommands.cfg:
define command{ command_name check_nrpe command_line /usr/local/nagios/libexec/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ } |
Host Konfiguration
Da ich meine Gruppen in einzelne Konfigurations Dateien ausgelagert habe, hier ein Auszug von einem Webserver, wie dieser überprüft wird:
define host{ use generic-host host_name web alias web address 192.168.1.4 check_command check-host-alive max_check_attempts 10 check_period 24x7 notification_interval 120 notification_period 24x7 notification_options d,r contact_groups admins } #web space define service{ use generic-service host_name web service_description Root Partition is_volatile 0 check_period 24x7 max_check_attempts 4 normal_check_interval 5 retry_check_interval 1 contact_groups admins notification_options w,u,c,r notification_interval 960 notification_period 24x7 check_command check_nrpe!check_disk } # web define service{ use generic-service ; Name of service template to use host_name web service_description Current Load is_volatile 0 check_period 24x7 max_check_attempts 4 normal_check_interval 5 retry_check_interval 1 contact_groups admins notification_options w,u,c,r notification_interval 960 notification_period 24x7 check_command check_nrpe!check_load } |
Wie zu sehen ist, unterscheiden sie sich nicht, von der Konfiguration in unserer minimal.cfg. Parameter muss ich hier nicht mitgeben, da diese auf dem entfernten Rechner angegeben werden.
Auf dem entfernen Rechner
Haben wir das Paket verschnürrt, kann es auf den entfernten Rechner gebracht werden. Mit den Inhalten wird am Besten folgendermaßen verfahren:
# mkdir -p /usr/local/nagios/bin # mkdir /usr/local/nagios/libexec # mkdir /usr/local/nagios/etc/ # echo nrpe 5666/tcp >> /etc/services
Die Plugins im Archiv werden nach /usr/local/nagios/libexec kopiert, währen der nrpe Daemon nach /usr/local/nagios/bin wandert. Das Startscript nach /etc/init.d/ verfrachtet und zum Schluß müssen wir noch den User Nagios anlegen:
# adduser --system --home /usr/local/nagios --shell /bin/bash --no-create-home nagios # addgroup --system nagios # usermod -G nagios nagios
Wenn wir dies haben, kümmern wir uns um die Konfiguration. Der Daemon kann per inetd, xinetd und als Dienst aufgerufen werden. Ich bevorzuge letzteres. Wer die anderen Varianten nutzen möchte, in der README gibt es entsprechende Anweisungen.
Eine typische Konfiguration von /usr/local/nagios/etc/nrpe.cfg sieht so aus:
server_port=5666 server_address=192.168.1.4 # Wenn es mehrere Schnittstellen gibt allowed_hosts=192.168.1.5 # Nur der darf abfragen nrpe_user=nagios nrpe_group=nagios # Values: 0=do not allow arguments, 1=allow command arguments dont_blame_nrpe=0 # wird per Default beim kompilieren nicht aktiviert, der Sicherheit wegen. debug=1 command_timeout=60 # The following examples use hardcoded command arguments... command[check_users]=/usr/local/nagios/libexec/check_users -w 5 -c 10 command[check_load]=/usr/local/nagios/libexec/check_load -w 15,10,5 -c 30,25,20 command[check_disk]=/usr/local/nagios/libexec/check_disk -w 20 -c 10 -p /dev/sda1 command[check_zombie_procs]=/usr/local/nagios/libexec/check_procs -w 5 -c 10 -s Z command[check_total_procs]=/usr/local/nagios/libexec/check_procs -w 150 -c 200 command[check_http]=/usr/local/nagios/libexec/check_http localhost # The following examples allow user-supplied arguments and can # only be used if the NRPE daemon was compiled with support for # command arguments *AND* the dont_blame_nrpe directive in this # config file is set to '1'... #command[check_users]=/usr/local/nagios/libexec/check_users -w $ARG1$ -c $ARG2$ #command[check_load]=/usr/local/nagios/libexec/check_load -w $ARG1$ -c $ARG2$ #command[check_disk]=/usr/local/nagios/libexec/check_disk -w $ARG1$ -c $ARG2$ -p $ARG3$ #command[check_procs]=/usr/local/nagios/libexec/check_procs -w $ARG1$ -c $ARG2$ -s $ARG3$ include=/usr/local/nagios/etc/nrpe_local.cfg |
Wird der Daemon gestartet, kann es passieren, wie bei mir, das noch Symlinks für libcrypt.so und libssl.so erzeugt werden müssen, für den Fall, dass es unterschiedliche Crypto Libs gibt. In meinem Fall gab es zwar eine Meldung, aber er tut seinen Dienst.
Ist dort alles glatt gelaufen, lässt sich nun im Webinterface vom Nagios überprüfen, ob auch alles funktioniert. Ansonsten ist ein Blick in die /var/log/debug angebracht, um eventuellen Fehlern auf die schliche zu kommen.
Wem die Kommandos dort nicht reichen, kann selbstverständlich weitere in die /usr/local/nagios/etc/nrpe.cfg hinzufügen, sofern die entsprechenden check_ Plugins vorhanden sind.
Für NT Clients
Auch Windows lässt sich damit überwachen. Dafür gibt es hier eine ensprechend kompilierte Version. Dieses Programm wird einfach entpackt und am besten nach C:\Programme\nrpe\ kopiert. Die entsprechenden Plugins finden sich im Bin Verzeichnis des Archives. Darin auch enthalten eine nrpe.cfg Datei mit Beispielen. Die Plugins entpacke ich unter C:\Programme\nrpe\plugins. Auf deutschen Windows Versionen bedarf es in der Datei einige Anpassungen. Später dazu mehr.
Da unter NT auch Dienste verwendet werden, müssen wir den nrpe_nt zu den diensten hinzufügen, dazu genügt ein:
# nrpe_nt -i
im Programm Verzeichnis. Es ist darauf zu achten, dass dies auch wirklich unter C:\Programme\nrpe\ passiert. Eine Konfigurations Datei für die NT-Clients kann z.B so aussehen:
#blowfish_secret=pipexcommunications allowed_hosts=192.168.1.5 #server_address=192.168.1.2 server_port=5666 dont_blame_nrpe=0 debug=0 command_timeout=30 # The following examples use no command arguments... command[nt_check_disk_c]=C:\Programme\nrpe\plugins\diskspace_nrpe_nt.exe c: 70 90 command[nt_check_disk_g]=C:\Programme\nrpe\plugins\diskspace_nrpe_nt.exe g: 70 90 command[nt_check_disk_h]=C:\Programme\nrpe\plugins\diskspace_nrpe_nt.exe h: 70 90 command[nt_cpuload]=C:\Programme\nrpe\plugins\cpuload_nrpe_nt.exe 50 80 command[nt_memload]=C:\Programme\nrpe\plugins\memload_nrpe_nt.exe 70 90 command[nt_service]=C:\Programme\nrpe\plugins\service_nrpe_nt.exe "DNS-Server" command[nt_system]=C:\Programme\nrpe\plugins\service_nrpe_nt.exe "System" command[nt_eventlog]=C:\Programme\nrpe\plugins\eventlog_nrpe_nt.exe -m 7200 -s "Service Control Manager" # The following examples allow user-supplied arguments and can # only be used if NRPE_NT was compiled with support for # command arguments *AND* the dont_blame_nrpe directive in this # config file is set to '1'... #command[check_arg]=D:\NRPE_NT\testarg.cmd $ARG1$ #command[check_arg]=D:\NRPE_NT\testarg.exe -H $ARG1$ -p $ARG2$ |
Die nötigen NT Plugins haben wir bereits oben heruntergeladen und müssen nur noch nach C:\Programme\nrpe\plugins\ entpackt werden. In der Konfiguration oben überwache ich einige Festplatten und die CPU und den DNS Dienst etc.
Host Konfiguration auf dem Nagios Server
Eine Bespiel Host Konfiguration kann folgendermaßen aussehen:
define host{ use generic-host host_name NT alias NT address 192.168.1.2 check_command check-host-alive max_check_attempts 10 check_period 24x7 notification_interval 120 notification_period 24x7 notification_options d,r contact_groups admins } define service{ use generic-service host_name NT service_description PING is_volatile 0 check_period 24x7 max_check_attempts 4 normal_check_interval 5 retry_check_interval 1 contact_groups admins notification_options w,u,c,r notification_interval 960 notification_period 24x7 check_command check_ping!100.0,20%!500.0,60% } define service{ use generic-service host_name NT service_description DNS is_volatile 0 check_period 24x7 max_check_attempts 3 normal_check_interval 2 retry_check_interval 1 contact_groups admins notification_interval 240 notification_period 24x7 notification_options w,u,c,r check_command check_nrpe!nt_service } define service{ use generic-service host_name NT service_description C_Disk is_volatile 0 check_period 24x7 max_check_attempts 3 normal_check_interval 2 retry_check_interval 1 contact_groups admins notification_interval 240 notification_period 24x7 notification_options w,u,c,r check_command check_nrpe!nt_check_disk_c |
Hat auch dies geklappt, lassen sich bequem NT Recher mit in die Überwachung mit einbeziehen. Und wer dann noch in der Lage ist, Script mit VB od. WSH zu verfassen, lassen sich auch schnell eigene Plugins schreiben, sofern nicht C++ verwendet werden kann.
per SSH
Diese Variante bietet sämtliche Vorteile, die SSH zur Verfügung stellt und ist von allen Möglichkeiten am einfachsten umzusetzen. Es wird auf ein public-key Verfahren gesetzt in Verbindung mit dem Nagios Plugin check_by_ssh.
Der Nagios Daemon loggt sich als User Nagios auf dem entfernten Rechner ein, führt ein fest definiteres Kommando aus und wertet Ergebnisse aus. Um dies alles möglichst zu vereinfach, hat sich jemand drangemacht, ein Script zu erstellen, welches die Installation auf dem Remote Rechner übernimmt. Diese kann hier heruntergeladen werden. Die enthaltene Anleitung ist ausführlich, sodass ich mir das an dieser Stelle spare nocheinmal zu schreiben ;-)
Sollte dennoch Fragen entstehen, werde ich sie beantworten.
Nützliches
Links
- Nagios
- Nagios Dokumentation
- Beschreibung der Parameter der Host Konfiguration
- Plugins und mehr
- Oberflächen für Nagios
- NRPE NT Daemon
- Nagios Wiki
Hinweise
- MySQL
Seit Nagios 2.x gibt es keinen nativen MySQL support mehr. Über verschiedene Wege soll dies jedoch möglich sein, denn unter den Links befinden sich einige Projekte, welche MySQL einsetzen zum managen.
- check_by_ssh Plugin
Wer wie ich das check_by_ssh Plugin einsetzt um entfernte Rechner zu prüfen, sollte unbedingt den Timeout in der nagios.cfg ordentlich hochsetzen, da sonst eine Flut von Meldungen über den Admin einhergeht, wegen Zeitüberschreitung. --Denny 14:23, 25. Jul 2006 (CEST)