|
|
 Diese kleine Anleitung richtet sich vorwiegend an Benutzer von SuSE-Linux 10.x. Grundsätzlich funktioniert Nagios auch auf anderen Distributionen, nur können dann verschiedene Verzeichnisse anders heißen.
Nagios wird von mir verwendet, weil es ein leistungsfähiges Tool zur Netzwerküberwachung ist, das als Open-Source vorliegt. Ausserdem ist es kostenlos erhältlich und lag der von mir verwendeten Distribution bei. Hierbei ist allerdings anzumerken, dass Nagios bei openSUSE nur bei der käuflichen Version beiliegt. Bei der frei herunterladbaren Installations-CD/DVD wird man sich anders behelfen müssen.
Kommerzielle Monitoring Software
OpenSource Monitoring Software:
Installation und InbetriebnahmeNormalerweise wird Nagios über yast installiert und ist in den meisten Distributionen standardmäßig vorhanden. Es ist aber auch möglich Nagios über externe RPM-Pakete zu installierten. Ich selbst habe mich an die mitgelieferten Pakete gehalten. Ist die Installation erfolgt, dann ist dafür zu sorgen, dass Nagios beim Booten auch gestartet wird. Dies geschieht bei SuSE in yast mit dem RunLevel-Editor. Danach sollte Nagios über die URL http://ip-adresse/nagios/ erreichbar sein.
Kennwort für nagiosadmin festlegenMit dem Befehl Soll ein weiterer Benutzer angelegt werden, dann ist folgendes einzugeben:
Test's über die ShellDazu wird in das Verzeichnis /usr/lib/nagios/plugins gewechselt.
Soll nur ein offener Port getestet werden, so kann folgende Abfrage helfen:
Windows Server überwachenUm Windows Server zu überwachen, bietet sich der NSCLient++ an. Herunterladen kann man sich diese Software unter folgendem Link: NSClient++ Downloads
statusmap_imageDas statusmap_image Bild, mit dem das statusmap.cgi die verschiedenen Hosts in einer topologischen Karte symbolisiert, wird aus Grafiken im GD2-Format zusammengesetzt. Zwar gibt es auch Dokumentationen, die darauf verweisen, dass auch GIFs, JPEGs und PNGs erlaubt sind aber meine Erfahrung hat gezeigt, dass dies zumindest bei der von mir verwendeten Distribution nicht stimmt. Mit dem Programm pngtogd2, das als Tool zu Thomas Botells GD-Bibliothek in den meisten Distributionen vorhanden ist, lassen sich aus PNG-Dateien einfach GD2-Logos konvertieren. Als Bildgröße sollten 40*40 Pixel verwendet werden. Bei der von mir verwendeten Distribution befinden sich die Logos in /usr/share/nagios/images/logos. Zum Erstellen eines GD2-Logos hat sich bei mir folgenes Komando bewährt: pngtogd2 hp.png hp.gd2 cs 2 Tip: Wer mehrere verschiedene Logo's verwendet, der sollte darauf achten, dass diese eine möglichts geringe Farbtiefe haben. Die meisten der von mir erstellten Logo's haben nur 16 Farben. Um dem interessierten Leser das Leben etwas zu erleichtern, hänge ich hier ein paar von mir erstellte Logos als PNG-Datei und die konvertierten GD2-Dateien in einem zusätzlichen ZIP-Archiv an: So könnte ein etwas umfangreiches Status Map aussehen:  Benachrichtigung / notificationWie bei vielen komplexen Systemen verfügt Nagios über ein ausgeklügeltes Benachrichtigungssystem, bei dem man an vielen Schrauben und Schaltern drehen kann. Die wichtigste Datei ist die /etc/nagios/objects/contacts.cfg define contact{
contact_name nagiosadmin ;
use generic-contact ;
alias Nagios Admin ;
email hugo@mycompany.de ;
}
define contactgroup{
contactgroup_name admins
alias Nagios Administrators
members nagiosadmin
}
Per default ist nur eine Gruppe mit einer Kontaktperson angelegt. Um bei einem Fehlerfall benachrichtigt zu werden ist einfach eine gültige eMail-Adresse für den Kontakt nagiosadmin einzutragen. Sollen mehrere Personen benachrichtigt werden, dann sind im einfachsten Fall auch mehrere Kontakt-Sektionen anzulegen und die verwendeten contact_name mit einem Komma separiert in der zu informierenden Gruppe unter members einzutragen. Nachfolgend ist ein Beispiel zu sehen, bei welchem die mit contact_groups definierte Gruppe informiert wird, wenn der Host down ist. Wenn nun gewünscht wird, dass die Kontaktgruppe auch informiert wird, wenn z.B. ein Ping nicht möglich ist, dann muss in die entsprechende Section die contact_groups definiert werden, denn sonst wird die Gruppe admins benachrichtigt.
###############################################################################
# eKiosk
###############################################################################
define host{
use windows-server ;
host_name eKiosk
alias eKiosk
parents IT-Switch
address ekioskxp
check_command check-host-alive
max_check_attempts 1
process_perf_data 0
retain_nonstatus_information 0
notification_interval 30
notification_period 24x7
notification_options d,u,r
notifications_enabled 1
contact_groups pcsupport
}
define service{
use generic-service ;
host_name eKiosk
service_description PING
check_command check_ping!100.0,20%!500.0,60%
contact_groups pcsupport
}
define hostextinfo{
host_name eKiosk
notes
icon_image windows.gif
statusmap_image windows.gd2
}
Sollen die Benachrichtigungen auf bestimmte Zeiten begrenzt werden, weil die zu überwachenden Geräte beispielsweise nur zu bestimmten Zeiten in Betrieb sind, dann sollte in der Datei timeperiods.cfg eine geeignete Zeitperiode definiert werden. Die Zeitperiode, die verwendet werden soll, muss dann in der Section define host angegeben werden (notification_period 10x5). Nachfolgend stelle ich eine beispielhafte Zeitperiode für eine fünf-Tage-Woche zur Verfügung:
define timeperiod{
timeperiod_name 10x5
alias 10 Hours A Day, 5 Days A Week
# sunday 00:00-24:00
monday 08:00-18:00
tuesday 08:00-18:00
wednesday 08:00-18:00
thursday 08:00-18:00
friday 08:00-18:00
# saturday 00:00-24:00
}
Wenn nun ein Dienst nicht erreichbar ist, wird in periodischen Abständen eine Nachricht verschickt. Es ist möglich diese Abstände zu beeinflussen, indem in jeder Service-Section der Parameter notification_interval gesetzt wird. Der Wert in Minuten gibt dann an, nach welcher Zeit eine erneute Nachricht verschickt werden soll. Ist eine Wiederholung der Nachricht nicht gewünscht, dann ist der Wert 0 einzutragen. Benachrichtigung per SMSEs gibt Fälle, da ist eine Benachrichtigung per eMail nicht sinnvoll. Denn was nützt eine solche Benachrichtigung, wenn der Mail-Server nicht mehr läuft und oder das Gateway ohne Anbindung ist. In einem solchen Fall wäre ein SMS-Versand ganz hilfreich. Ich habe mich für gammu und einem ausgedienten Handy (in meinem Fall ein Sony-Ericsson K750i) entschieden. Die beiden Pakete gammu und wammu sind bei SuSE 11.1 bereits enthalten und somit ist mir die Suche und/oder Installation von externen Paketen erspart geblieben. Bei der Auswahl eines geeigneten Handys hilft die Datenbank weiter: http://de.wammu.eu/phones/ Für die Erstellung einer Configurationsdatei von gammu sollte man zu aller Erst die grafische Oberfläche wammu probieren. Mit den gewonnenen Informationen kann dann gammu mit dem Kommando gammu-config eingerichtet werden. Bei der Überprüfung kann dann gammu --identify weiter helfen. Ist dieser Test von Erfolg gekrönt, dann kann eine erste Textnachricht verschickt werden: echo "Hallo! Ich bin ein Gammu-Test." | gammu --sendsms TEXT Mobilnummer Wenn dieser Test funktioniert hat, dann sollte als User nagios eine gammu-Configurationsdatei erzeugt werden. Einfach su - nagios eingeben und mit gammu-config einrichten. Sollte dies nicht möglich sein, so muss man dem Benutzer nagios mit Hilfe von YAST die bash als Konsole einrichten. Bevor es mit den Configurationsdateien von Nagios weiter geht, muss noch ein Eintrag in der /etc/sudoers getätigt werden: %nagios ALL = NOPASSWD: /usr/bin/gammu Dies bewirkt, dass nagios gammu ohne Passwortabfrage ausführen darf. Einfach als User nagios die folgende Zeile eingeben: echo "Hallo! Ich bin ein Gammu-Test." | sudo -u root gammu --sendsms TEXT Mobilnummer Jetzt fehlen nur noch ein paar Zeilen in den Configurationsdateien von Nagios. Dort wird eine Kontaktperson benötigt, die Textnachrichten zugeschickt bekommen soll. Dies geschieht in der contacts.cfg:
define contact{
contact_name USER_pager
use generic-contact
alias USER_pager
service_notification_period 24x7
host_notification_period 24x7
service_notification_options w,u,c,r
host_notification_options d,u,r
service_notification_commands notify-service-by-sms
host_notification_commands notify-host-by-sms
pager Mobilnummer
}
Damit Nagios auch weiß, was es zu tun hat, fehlen noch zwei Sectionen in der command.cfg:
# 'notify-host-by-SMS' command definition
define command {
command_name notify-host-by-sms
command_line echo "Nagios02 / $NOTIFICATIONTYPE$ / Host: $HOSTNAME$ /
Address: $HOSTADDRESS$ / State: $HOSTSTATE$ / $LONGDATETIME$ /
Info: $HOSTOUTPUT$" | sudo -u root gammu --sendsms TEXT $CONTACTPAGER$
}
# 'notify-service-by-SMS' command definition
define command {
command_name notify-service-by-sms
command_line echo "Nagios02 / $NOTIFICATIONTYPE$ / Host: $HOSTALIAS$ /
Address: $HOSTADDRESS$ / State: $SERVICESTATE$ / $LONGDATETIME$ /
Info: $SERVICEOUTPUT$" | sudo -u root gammu --sendsms TEXT $CONTACTPAGER$
}
Hier ist zu beachten, dass die command_line in einer Zeile steht. Ich habe sie zur besseren Darstellung umbrechen müssen. Danach noch ein Reload von Nagios durchführen und es sollte funktionieren. Anlegen einer servicegroupOptional ist es möglich eine oder mehrere servicegroup anzulegen. Dazu wird in /etc/nagios/objects die Datei servicegroups.cfg erstellt und diese in /etc/nagios/nagios.cfg mit folgenen Zeilen eingebunden: # Definitions for servicegroups Die Datei servicegroups.cfg könnte so aussehen: define servicegroup{
Nagios Remote Plugin Executor (NRPE)Wenn Nagios installiert wird, dann ist meist auch das NRPE-plugin mit dabei. Wenn Sie Nagios nicht installieren möchten aber trotzdem das NRPE-Plugin benötigen, dann sollten Sie dieses am Besten mit YAST installieren.  Als nächstes ist dafür zu sorgen, dass der xinetd gestartet wird. Am besten erledigt man dies in YAST. Danach startet man in xinetd den Dienst nrpe. Um einen Test über die Shell durchzuführen muss in das Verzeichnis /usr/lib/nagios/plugins gewechselt werden. Dort muss dann folgendes Kommando eingegeben werden: ./check_nrpe -H localhost Damit der Nagios-Server per NRPE auf diese Maschine zugreifen darf, muss noch die Datei /etc/xinet.d/nagios-nrpe (/etc/xinet.d/nrpe) angepasst werden, indem die IP-Adresse des Nagios-Severs eingetragen und evtl. disable auf no gesetzt wird:
# default: off
# description: NRPE (Nagios Remote Plugin Executor)
service nrpe
{
socket_type = stream
wait = no
user = nobody
group = nogroup
server = /usr/bin/nrpe
server_args = -c /etc/nagios/nrpe.cfg --inetd
flags = REUSE
type = UNLISTED
port = 5666
log_on_failure += USERID
only_from = 127.0.0.1 ip_des_nagios-servers
}
Ab jetzt sollte ein erfolgreicher NRPE-Funktionstest vom Nagios-Server aus möglich sein. Diesen führt man im Verzeichnis /usr/lib/nagios/plugins aus: ./check_nrpe -H ip_des_nrpe-client Will man nun vom Nagios-Server auf dem entfernten Rechner z.B. die Anzahl der http Prozesse überwachen, muss auf diesem entfernten Rechner unter /etc/nagios die Datei nrpe.cfg ergänzt werden. Als Beispiel habe ich folgende Zeile eingefügt: command[check_http_procs]=/usr/lib/nagios/plugins/check_procs -a http -c 6:6 Nach der Änderung ist verständlicherweise xinetd neu zu starten, je nach System kann auch ein reload ausreichen. Dann kann auf dem Nagios-Server folgender Befehl eingegeben werden: ./check_nrpe -H ip_des_nrpe-client -c check_http_procs Einen interessanten externen Link dazu gibt es unter: Möchte man nun, dass ein derartiger Test vom Nagios-Server durchgeführt wird, ist folgende Section einzubauen:
define service{
use generic-service
host_name ZUTESTENDERSERVER
service_description Apache
check_command check_apachetesten
}
Damit dieses Kommando auch funktioniert, muss es noch in der Datei /etc/nagios/objects/commands.cfg definiert werden:
# 'check_nrpe' command definition
define command{
command_name check_apachetesten
command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c check_http_procs
}
NRPE in SLES9 SLES10 SLES11Wer NRPE in SLES9, SLES10 oder SLES11 installieren möchte, dem werden diese Seiten weiterhelfen: http://wiki.gwdg.de/index.php/NRPE_auf_SLES9_SLES10_und_SLES11_installieren ftp://ftp5.gwdg.de/pub/opensuse/repositories/server:/monitoring/SLE-10-SP3/ Im einfachsten Fall gibt man in einer Telnet-Sitzung eines der Kommandos ein: zypper sa -t YUM ... Wenn dieser Befehl erfolgreich ausgeführt wurde, dann ist es möglich NRPE über YAST zu installieren.
Netapp-Filer Um Filer von z.B. der Firma Netapp über Nagios zu überwachen gibt es recht unterschiedliche Herangehensweisen:
APC - USVUm eine USV von APC in die Nagios-Überwachung zu integrieren, sind ein paar SNMP-Abfragen nötig. In Nagios sieht die Darstellung bei mir wie in folgendem Bild aus. Unterhalb der Bilder ist die Section für die Abfrage in Nagios hinterlegt.  MASTRGUARD - USVUm eine USV von MASTERGUARD in die Nagios-Überwachung zu integrieren, kommt man wie auch bei anderen Herstellern um SNMP-Abfragen nicht vorbei. Leider sind die OID's nicht dokumentiert. Wer einen SNMP-Browser benutzen kann, wird aber recht schnell geeignete OID's für seine Abfragen finden. Die von mir zusammengestellte Abfrage sieht in Nagios wie im folgenden Bild aus:  Je nach Netzwerkinfrastruktur kann es nötig sein sich per Telnet aufzuschalten und die Community mit dazugehöriger IP-Adresse für den abfragenden Server einzurichten. - Dies ist meist nur dann interessant, wenn mehrere Netzwerksegmente betrieben werden und/oder nicht jeder abfragen können darf.  Cisco - SwitchAllerspätestens, wenn der Administrator ein paar Parameter von einem Cisco-Switch überwachen möchte, dann kommt er an gezielten SNMP-Abfragen nicht vorbei. Hilfreich bei der Erstellung einer solchen Section kann ein snmp-Browser sein. An dieser Stelle füge ich beispielhaft eine von mir erstellte Abfrage-Section an: Bei den Abfragen der einzelnen Port's stellt sich allerdings die Frage, ob diese Werte überhaupt lesbar und aussagekräftig sind. Auch stellt sich dann die Frage, ob die auflaufenden Werte nicht besser über ein Tool erfasst werden, welches in der Lage ist, diese Werte grafisch aufzubereiten. Hier bieten sich kostenpflichtige und kostenfreie Programme an:
Da es für Nagios bereits ein fertiges Plugin für ein Zusammenspiel mit MRTG gibt, habe ich mich dafür entschieden. Dies hat auch den Vorteil, dass in Nagios die Schwellwerte für eine Alarmierung definiert werden können. Eine entsprechende Section zur Überwachung eines Port's sieht wie folgt aus: 
SNMP-Traps empfangenAus Gründen der Sicherheit unterstützen immer mehr Geräte die Protokolle snmp V1 und snmp V2 nicht mehr. Spätestens dann sollte sich der Nagios-Administrator mit dem Thema SNMP-Trap beschäftigen. - Leider ist das WWW voll mit Foreneinträgen zu diesem Thema, die aber nicht sonderlich hilfreich sind. Als begeisterter SuSE-Anhänger gehe ich von der SuSE-Distribution 12.1 aus. Bei allen anderen Distributionen sollte es aber ähnlich funktionieren. Als Erstes wird ein SNMP-Trap-Deamon benötigt. Bei SuSE ist das der snmptrapd, welcher über yast installiert und dann im Runlevel-Editor aktiviert wird. Ist dies geschehen, kann man einen Test-Trap auf diese Maschine schicken und sich die Datei /var/log/net-snmpd.log ansehen. Dort steht recht deutlich, dass zwar etwas empfangen, aber keine Regeln bestehen und dieser Trap deshalb verworfen wurde. Also muss im Verzeichnis /etc/snmp die Datei snmptrapd.conf erstellt werden. Diese existiert per default einfach nicht. Bei mir besteht diese Datei im ersten Schritt aus nur zwei Zeilen: traphandle default /myjob/handle_trap.sh disableauthorization yes Die erste Zeile legt fest, welches Programm sich um die Weiterverarbeitung der Traps kümmert und die zweite Zeile deaktiviert die Authorisierung. Wer möchte kann sich an dieser Stelle noch mit dem snmptt beschäftigen. Ich selbst begnüge mich vorerst mit der Übergabe der Variablen an ein Bash-Script, um dann eine Meldung per NSCA an Nagios zu übergeben. Hier nun das beispielhafte Script: #!/bin/bash CFG="/etc/nagios/send_nsca.cfg" NAGIOS="nagsrv" ZEIT=`date +%Y'-'%m'-'%d'-'%H'.'%M` echo $ZEIT >> /myjob/handle_text.txt read HOST && echo "host: $HOST" >> /myjob/handle_text.txt read IPADDR && echo "ip: $IPADDR" >> /myjob/handle_text.txt read SWITCH && echo "Meldung: $SWITCH" >> /myjob/handle_text.txt STNO=2 TEXT=$SWITCH # VM06 if [[ $IPADDR =~ "192.168.223.70" ]]; then CMD="VM06;snmp-Trap;$STNO;$TEXT" /bin/echo $CMD | /usr/bin/send_nsca -H localhost -d ';' -c $CFG fi Damit diese NSCA-Nachrichten ausgewertet werden, muss noch der passende passive Check eingerichtet werden:
define service{
use generic-service ;
host_name VM06
service_description snmp-Trap
check_command check_esxi_hardware
max_check_attempts 1
is_volatile 1
active_checks_enabled 0
passive_checks_enabled 1
check_freshness 0
}
Entgegen verschiedener Dokumentationen, muss die Zeile check_command angegeben werden, obwohl sie nicht benötigt wird. Ohne diese Zeile bekommt man nach dem Neustart von Nagios eine Fehlermeldung. Die Zeile is_volatile sorgt dafür, dass alle einlaufenden Traps zu einer Benachrichtigung führen. Eine Voraussetzung ist das Einrichten von NSCA. Wie das funktioniert steht unter der Überschrift "Verteiltes Monitoring". check_oracle_healthUm über Nagios verschiedene Check's auf einer Oracle-Datenbank durchzuführen, hat sich das populäre Plugin check_oracle_health recht gut bewährt. Erhalten kann man es unter folgendem Link: http://labs.consol.de/lang/de/nagios/check_oracle_health/ Damit dieses Plugin funktioniert wird ein installierter Oracle-Client(Instant Client) benötigt. Des Weiteren werden die Perl-Module DBI und DBD::Oracle benötigt. Letzteres ist meist nicht Bestandteil der verschiedenen Distributionen und wird am Besten über CPAN installiert. Voraussetzung dafür sind die Installationen der Pakete perl und gcc. Zum besseren Verständnis für alle, die sich mit den vielen nichts sagenden Kommentaren in den diversen Foren rumgeärgert haben, hier Schritt für Schritt:
Jetzt sollte die Datei check_oracle_health erstellt worden sein. Diese kann in /usr/lib/nagios/plugins kopiert und für Nagios ausführbar gemacht werden. Damit Nagios dieses Plugin verwenden kann sind die Umgebungsvariablen im Startscript von Nagios zu setzten. Bei mir sieht es so aus: export ORACLE_HOME=/usr/lib/oracle/11.2/client Damit check_oracle_health funktionieren kann, muss selbstverständlich auch ein Benutzer mit entsprechendem Kennwort und den benötigten Berechtigungen auf der Datenbank eingerichtet sein.
check_mysql_healthUm Check's auf MySQL-Datenbanken durchzuführen, die über einen check_tcp!3306 hinausgehen, empfiehlt sich das Plugin check_mysql_health, welches unter folgendem Link zu bekommen ist: http://labs.consol.de/lang/de/nagios/check_mysql_health/ Voraussetzung ist die Installation des Moduls DBI und wenn möglich des moduls DBD::mysql. Hier die Anleitungsanweisung Schritt für Schritt:
check_http_hostMit check_http_host ist es möglich die Antwortzeiten einer Webseite zu überprüfen. Dazu ist als Vorarbeit nötig die command.cfg zu erweitern: # 'check_http_host' -> Webseite nach Textbaustein durchsuchen Die dazu passende Service-Definition könnte dann so aussehen: define service{ Zu beachten ist, dass das Unterverzeichnis optional ist. Der Suchtext sollte ein Begriff auf der zu prüfenden Seite sein, der nach Möglichkeit nur ein Mal vorhanden ist und möglichst im hinteren Bereich der Seite zu finden ist. Da solche statischen Abfragen innerhalb von Nagios nicht besonders aussagekräftig sind, kann man auch solche Abfragen nach Manier von MRTG alle 5 Minuten durchführen, die ermittelten Messwerte in einer Datenbanktabelle sammeln und daraus eine Grafik generieren. Eine solche Grafik könnte dann so aussehen:  Um eine solche Grafik zu erstellen, sind folgende Dinge zu tun:
VMware ESXi Hardware überwachenUm VMware ESXi Hardware zu überwachen, verwende ich das Plugin check_esxi_hardware.py Eine ausführliche Beschreibung zu diesem Plugin findet man unter: http://www.thomas-krenn.com/de/wiki/VMware_ESXi_Hardware_mit_Nagios_oder_Icinga_%C3%BCberwachen Das Plugin selbst kann dort bezogen werden: http://www.claudiokuenzler.com/nagios-plugins/check_esxi_hardware.php Bei Testumgebungen, die etwas leistungsschwach sind, kann es nötig sein, dieses Plugin per NSCA zu nutzen, da es sonst zu einem Timout kommt. Die passende Sektion in der command.cfg sieht bei mir folgendermaßen aus:
# 'check_esxi_hardware' command definition
define command{
command_name check_esxi_hardware
command_line /usr/lib/nagios/plugins/check_esxi_hardware.py -H $HOSTADDRESS$
-U $ARG1$ -P $ARG2$ -V auto
#command_line /usr/lib/nagios/plugins/check_esxi_hardware.py -H 192.168.213.3
-U benutzer -P kennwort -V auto
}
Dieses Plugin ist leider kein Allheilmittel, denn es werden nicht alle Fehler übermittelt aber doch recht viele. Verteiltes MonitoringPassive Service- und Host-Checks können genutzt werden, um bei mehreren, dezentral installierten Nagios-Instanzen Ergebnisse an einen zentralen Server zu senden. Interessant ist eine solche Vorgehensweise, um bei verschiedenen Standorten dezentral Checks durchzuführen und die Ergebnisse an eine zentrale Nagios-Instanz zu schicken. Üblicherweise werden die Resultate über den NSCA (Nagios Service Check Acceptor) an die zentrale Nagios-Instanz geschickt. Diese empfängt sie über die External-Command-File-Schnittsttelle und verarbeitet diese als passive Checks.
Ist das NSCA auf dem zentralen Nagios-Server installiert und in Betrieb genommen, dann kann man mit einem Shell-Script vom dezentralen Nagios-Server die Funktion testen. Vorher sollte möglicherweiser noch der Port 5667, in der Firewall, auf dem zentralen Nagios-Server geöffnet werden. #!/bin/bash Damit dies auch funktioniert, ist auf dem zentralen Nagios-Server der entsprechende Service auf passive_checks_enabled 1 password=geheim
Ist dieser Test von Erfolg gekrönt, kann im nächsten Schritt auf dem dezentralen Nagios-Server der OCSP/OCHP-Mechanismus in der nagios.cfg eingeschaltet werden: obsess_over_services=1 Jetzt werden noch die beiden Skripte submit_service_check und submit_host_check benötigt, die dann in /usr/lib/nagios/plugins kopiert und mit den dazugehörigen Rechten versehen werden: Damit diese Plugins auch ausgeführt werden können, müssen in der commands.cfg noch die beiden commands definiert werden: define command{
Damit ein Service-Check diese Funktionalität nutzt, muss die Zeile obsess_over_service 1 eingefügt werden: define service{ Somit wird er dezentrale Nagios-Server veranlasst, seine Ergebnisse an den zentralen Nagios-Server zu übermitteln. Nun kann es passieren, dass der dezentrale Nagios-Server ausfällt. - So etwas gibt es tatsächlich. - Dann wären die Service-Checks mit der Zeit nicht mehr frisch. Um dieses Problem zu umgehen, verwendet man beim zentralen Nagios-Server die Direktive: check_freshness 1 Damit diese Direktive auch seine Wirkung entfalten kann, muss in der nagios.cfg check_service_freshness=1 und check_host_freshness=1 eingeschaltet werden. Etwas detailiertere Informationen hierzu gibt es unter folgendem Link: http://www.nagios-wiki.de/nagios/doku3/freshness Wer diese Möglichkeiten kombiniert, der wird in der Lage sein, nicht nur ein verteiltes Monitoring zu realisieren, sondern auch für eine Redundanz zu sorgen.
Prüfen, ob auf einem Windows-Server ein Netzlaufwerk eingehängt istHier geht es darum, mit Nagios zu überwachen, ob ein Netzlaufwerk auf einem Windows-Server eingehängt ist und ein Zugriff darauf möglich ist oder eben nicht. Nun könnte man auf die Idee kommen, diese Aufgabe mit Hilfe vom NS-Client zu lösen. Dies scheitert aber daran, dass dieser NS-Client nicht über Rechte verfügt um ein Netzlaufwerk zu prüfen. Es sind leider nur eigene Festplatten prüfbar. Ich habe dieses Problem dadurch gelöst, indem ich auf dem Windows-Server alle 5 Minuten eine BAT-Datei ausführen lasse. Diese sieht folgendermaßen aus: if exist s:\nul goto working if NOT exist s:\nul echo Nein, diese Datei gibt es nicht! exit :working s: cd \ dir > s:\stempel.txt exit Wenn alles reibungslos funktioniert, dann legt der zu prüfende Windows-Server in das Netzlaufwerk eine Datei mit einem neuen Erstellungsdatum ab. Dies ist der erste Schritt. Beim zweiten Schritt prüft auf dem Nagios-Server ein Plugin das Alter dieser Datei. Dies funktioniert bei mir nur dashalb, weil der Nagios-Server auch ein Samba-Share bereitstellt, welches geprüft werden soll. Der dafür nötige Service-Check sieht bei mir so aus:
define service{
use generic-service
host_name EASY
service_description S: mounted
#check_command check_file_age!-w 1000 -c 1500 -f /sap/stempel.txt
check_command check_file_age!1000!1500!/sap/stempel.txt
max_check_attempts 2
obsess_over_service 1
}
Die dazu passende Command-Definition sieht dann so aus:
# 'check_file_age'
define command{
command_name check_file_age
#command_line $USER1$/check_file_age -w 100000 -c 200000 -f "/myjob/stempel.txt"
command_line $USER1$/check_file_age -w $ARG1$ -c $ARG2$ -f $ARG3$
}
Sollte es einmal vorkommen, dass der Samba-Server nicht gleichzeitig auch Nagios-Server ist, dann gibt es noch die Möglichkeit diese Prüfung auf dem Samba-Server per crontab auszuführen und das Ergebnis dann per NSCA an den/die Nagios-Server zu übermitteln. Ein Script, welches die nötigen Informationen an den Nagios-Server übermittelt, könnte so ausehen: Dabei ist zu beachten, dass auf dem zentralen Nagios-Server der NSCA-Deamon aktiv ist, dieser die Nachrichten vom dezentralen Dienst annehmen darf und der Port 5667 geöffnet ist. |
|
|
