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

Big Brother

Microsoft Operations Manager

HP OpenView

Tivoli (IBM)

Spectrum Enterprise Manager

WhatsUpGold

PRTG Network Monitor

 

OpenSource Monitoring Software:

Big Sister

Mumin

Zabbix

Hobbit

icinga

 

Installation und Inbetriebnahme

Normalerweise 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 festlegen

Mit dem Befehl
htpasswd -c /etc/nagios/htpasswd.users nagiosadmin
wird das Kennwort für den Benutzer nagiosadmin festgelegt.
Bei der Option -c ist zu beachten, dass bei Verwendung eine neue htpasswd.user Datei angelegt wird.

Soll ein weiterer Benutzer angelegt werden, dann ist folgendes einzugeben:
htpasswd /etc/nagios/htpasswd.users weitererUser
Dabei ist zu beachten, dass dieser Benutzer in der contact.cfg angelegt ist und er auch einer Kontaktgruppe angehört. Dadurch ist es möglich bestimmten Gruppen auch nur die Server und Dienste anzuzeigen, für welche diese Gruppe zuständig ist.

 

Test's über die Shell

Dazu wird in das Verzeichnis /usr/lib/nagios/plugins gewechselt.
Dort angekommen kann man folgende Abfrage eingeben um HTTP zu testen:
./check_http -I IP-Adresse -p Port
oder
./check_http -H IP-Adresse -p Port

 

Soll nur ein offener Port getestet werden, so kann folgende Abfrage helfen:
./check_tcp -H IP-Adresse -p Port

 

Windows Server überwachen

Um Windows Server zu überwachen, bietet sich der NSCLient++ an.
Eine kleine Beschreibung dazu findet man hier:
Serie NSClient++

Herunterladen kann man sich diese Software unter folgendem Link: NSClient++ Downloads

 

statusmap_image

Das 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 / notification

Wie 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 SMS

Es 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 servicegroup

Optional 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
cfg_file=/etc/nagios/objects/servicegroups.cfg

Die Datei servicegroups.cfg könnte so aussehen:

define servicegroup{
    servicegroup_name        Web-Server
    alias                    website-mashine
    servicegroup_members    domainverwalter
    members                    HE01, PING, HE02, PING, HE03, PING

}

 

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
NRPE v2.5.1

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
NRPE v2.5.1

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:
http://www.nagios-wiki.de/nagios/howtos/nrpe

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 SLES11

Wer 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:

  • Bei der von mir verwendeten Distribution lag ein Perl-Script mit dem Namen check_netapp.pl bei. Dieses konnte ich aber nur über die Shell verwenden.
  • Dann gibt es Python-Scripte von Sven Velt, die aber nicht kostenlos sind. http://velt.de/computer/check_netappfiler
  • Oder man steigt in die Abgründe von SNMP hinab. Dabei entstehen recht unverständliche Ausdrücke, die ich hier einfach hinterlege.

APC - USV

Um 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 - USV

Um 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 - Switch

Allerspä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 empfangen

Aus 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_health

Um ü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:

  • über den Packetmanager (bei mir ist es YAST) folgende Packete installieren:
    • perl
    • perl-DBI
    • gcc
  • den Oracle-Client(Instant Client) als root installieren
    bei mir sind die folgenden drei Pakete zum Einsatz gekommen:
    • oracle-instantclient11.2-basic-11.2.0.2.0.i386.rpm
    • oracle-instantclient11.2-sqlplus-11.2.0.2.0.i386.rpm
    • oracle-instantclient11.2-devel-11.2.0.2.0.i386.rpm
  • die Umgebungsvariablen setzen!
  • cpan installieren
    • hier sind viele Menschen am verzweifeln, denn cpan gibt es nicht als Paket. cpan gehört irgendwie zu perl, oder umgekehrt, und wird durch Eingabe von cpan aktiviert (also wirklich in der Shell eingeben!)
    • mit Hilfe von cpan DBD::Oracle installieren
      • install DBD::Oracle (Sollte dies Schwierigkeiten bereiten, weil es nicht möglich ist sich mit 'scott/tiger' anzumelden, dann könnte ein "force install DBD:Oracle" helfen)
  • check_oracle_health.tar.gz von oben genannter Quelle herunterladen
  • mit tar xzvf  check_oracle_health.tar.gz auspacken
  • in das neu erstellte Verzeichnis wechseln
  • ./configure mit Parametern aufrufen
    • Bei mir sieht es wie folgt aus:
      ./configure --prefix=/usr/lib/nagios/plugins --with-nagios-user=nagios --with-nagios-group=nagios --with-perl=/usr/bin/perl --with-statefiles-dir=/tmp
    • Um den Pfad für Perl herauszubekommen einfach folgendes Kommando eingeben: which perl
  • make aufrufen
  • make install aufrufen

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
export LD_LIBRARY_PATH=/usr/lib/oracle/11.2/client/lib

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_health

Um 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:

  • über den Paketmanager (bei mir ist es YAST) folgende Pakete installieren:
    • perl
    • perl::DBI
    • gcc
  • check_mysql_health.tar.gz von oben genannter Quelle herunterladen
  • mit tar xzvf  check_mysql_health.tar.gz auspacken
  • in das neu erstellte Verzeichnis wechseln
  • ./configure mit Parametern aufrufen
    • bei mir sieht es wie folgt aus:
      ./configure --prefix=/usr/lib/nagios/plugins --with-nagios-user=nagios --with-nagios-group=nagios --with-perl=/usr/bin/perl --with-statefiles-dir=/tmp
    • um den Pfad für Perl herauszubekommen einfach folgendes Kommando eingeben: which perl
  • make aufrufen
  • make install aufrufen

check_http_host

Mit 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
define command{
        command_name    check_http_host
        command_line    $USER1$/check_http -H $HOSTADDRESS$ -u /home/ -s $ARG1$
        }

Die dazu passende Service-Definition könnte dann so aussehen:

define service{
        use                                local-service
        host_name                        Domain-Name
        service_description                www.Domain-Name/Unterverzeichnis/
        check_command                    check_http_host!Suchtext -c 20
        notifications_enabled            1
        notification_interval            2
        contact_groups                    domainverwalter
        max_check_attempts                2
}

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:

  • In MySQL eine Datenbank erstellen. Ich habe meine Datenbank einfach "messwerte" genannt.
  • Als nächstes ist in dieser Datenbank eine Tabelle zu erstellen:
    CREATE TABLE `tabellenname` ( `zeit` varchar(18) NOT NULL, `delay` varchar(8) NOT NULL ) ENGINE=MyISAM DEFAULT CHARSET=latin1;
  • Jetzt sind als root folgende Kommandos auszuführen:
    mysql < createuser.mysql
    mysqladmin reload
    Die dazu benötigte Datei createuser.mysql stelle ich nachfolgend zur Verfügung. Benutzer von Redhat müssen nur beachten, dass sie einen anderen Benutzer für Apache eintragen. Bei SuSE heißt dieser wwwrun.

  • Da nun alle Vorarbeiten erledigt sind, wird es Zeit, dafür zu sorgen, dass in regelmäßigen Abständen Messwerte in die Tabelle geschrieben werden. Für diesen Zweck habe ich ein kleines Shell-Script geschrieben welches bei mir im Verzeichnis /myjob liegt:
    ZEIT=`date +%Y'-'%m'-'%d'-'%H'.'%M`
    WARTE=`/usr/lib/nagios/plugins/check_http -H www.Domain-Name -u /Unterverzeichnis -s Suchtext -c20 | cut -c27-31`
    #echo $ZEIT
    #echo $WARTE
    echo "INSERT INTO tabellenname (zeit, delay) values (\"$ZEIT\", $WARTE);" > /myjob/tabellenname.mysql
    mysql -uroot messwerte < /myjob/tabellenname.mysql
  • Bei der letzten Zeile kann es durchaus nötig sein, das Kennwort für root mitzugeben: -pkennwort
  • Ausgelöst wird dieses Script im 5 Minuten Takt, mit Hilfe der crontab:
    0,5,10,15,20,25,30,35,40,45,50,55 * * * * /myjob/check_website.sh
  • Jetzt muss auf dem Webserver ein Unterverzeichnis in /srv/www/htdocs erstellt werden. In dieses sind dann die nachfolgenden Scripte zu kopieren. Selbstverständlich müssen diese noch angepasst werden, indem die Platzhalter IP-des-Servers, Unterverzeichnis und Tabellenname, durch gültige Werte ersetzt werden.

  • In der Zip-Datei, die ich da zum Herunterladen zur Verfügung stelle, ist die verdana.ttf nicht dabei. Ich selbst habe diese aus meinem Windows-System entnommen. Es sollte also kein Problem sein an diese Datei zu kommen. Selbstverständlich kann auch eine andere Schrift verwendet werden. Dann muss dies aber auch in den Scripten geändert werden.

VMware ESXi Hardware überwachen

Um 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 Monitoring

Passive 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.

  • Auf dem zentralen Nagios-Server muss der NSCA-Daemon installiert sein und per xintd gestartet werden. Dazu ist es nötig sowohl die nsca.cfg als auch die nsca in xinet.d zu konfigurieren:
    1. nsca.cfg:
      • debug=0
      • command_file=/var/spool/nagios/nagios.cmd
      • alternate_dump_file=/var/spool/nagios/nsca.dump
      • aggregate_writes=0
      • append_to_file=0
      • max_packet_age=30
      • password=geheim
      • decryption_method=10
    2. nsca in xinet.d
        # default: off
        # description: NSCA (Nagios Service Check Acceptor)
        service nsca
        {
                flags           = REUSE
                socket_type     = stream
                type            = UNLISTED
                port            = 5667
                wait            = no
                user            = nagios
                group           = nagios
                server          = /usr/bin/nsca
                server_args     = -c /etc/nagios/nsca.cfg --inetd
                log_on_failure  += USERID
                disable         = no
                only_from       = 127.0.0.1 dezentralerServer
        }
        
        

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
CFG="/etc/nagios/send_nsca.cfg"
#CMD="intranet;HTTP;3;UNKNOWN - nur ein NSCA-Test"
CMD="intranet;HTTP;2;Alarmstufe ROT - nur ein NSCA-Test"
#CMD="intranet;HTTP;1;Alarmstufe GELB - nur ein NSCA-Test"
#CMD="intranet;HTTP;0;Alles OK - nur ein NSCA-Test"

/bin/echo $CMD | /usr/bin/send_nsca -H 192.168.222.242 -d ';' -c $CFG

Damit dies auch funktioniert, ist auf dem zentralen Nagios-Server der entsprechende Service auf passive_checks_enabled        1
active_checks_enabled        0
max_check_attempts        1
zu setzen und auf dem dezentralen Nagios-Server die send_nsca.cfg zu bearbeiten:

password=geheim
encryption_method=10

 

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
ocsp_command=submit_service_check
ocsp_timeout=5
obsess_over_hosts=1
ochp_command=submit_host_check
ochp_timeout=5

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{
    command_name submit_host_check
    command_line $USER1$/submit_host_check $HOSTNAME$ $HOSTSTATEID$ '$HOSTOUTPUT$'
    }

define command{
    command_name submit_service_check
    command_line $USER1$/submit_service_check $HOSTNAME$ '$SERVICEDESC$' $SERVICESTATEID$ '$SERVICEOUTPUT$'
    }

 

Damit ein Service-Check diese Funktionalität nutzt, muss die Zeile obsess_over_service    1 eingefügt werden:

define service{
        use                             generic-service
        host_name                       intranet
        service_description             HTTP
        check_command                   check_http
        max_check_attempts            2
        notifications_enabled
            0
        obsess_over_service            1
        }

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 ist

Hier 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.