Ich habe vor längerer Zeit mal Nagios, ein sehr komplexes Überwachungstool, aufgesetzt, aber aus Zeitmangel habe ich mich nie wirklich mit der raffinierten, aber doch sehr komplizierten Konfiguration beschäftigt.

Nun aber ist mir das ganze wieder in die Hände gefallen und ich habe mich mal aufgemacht und wollte Nagios nicht nur zum laufen bringen, sondern auch richtig konfigurieren und überwachen lassen.

Im uu.de-Wiki, welches sonst meistens meine erste Anlaufstelle für so Fragen ist, gibt es leider nur ein unfertiger Artikel. (Wenn ich die Zeit finde, werde ich mich da dann mal ran machen) Also habe ich mir meine Informationen selbst zusammengesucht.

Die Installation von Nagios ist relativ einfach. Nagios2 gibt es sogar in den Paketquellen, Nagios3 lässt sich problemlos selbst kompilieren.

Für mich reicht aber Nagios2 voll und ganz und somit habe ich mittels der Paketverwaltung mal die Pakete installiert:

sudo apt-get install apache2, nagios2, nagios2-common, nagios-plugins

Für die Installation war es das eigentlich schon! Doch ganz so einfach ist es dann doch wieder nicht.
Unter http://localhost/nagios2 ist jetzt schon die Weboberfläche zu sehen. Jedoch fehlt noch die gesamte Konfiguration, also weiter im Konzept.

Da mein Webinterface natürlich nicht für jeden Zugänglich sein soll, habe ich mir noch ein Passwortschutz angelegt:

htpasswd -bc /etc/nagios2/htpasswd.users

Nun gilt es noch den Apache neu zu starteten, damit die Änderung auch wirksam werden:

sudo /etc/init.d/apache2 restart

Nun sollte man bereits beim Aufrufen von Nagios, immer noch unter http://localhost/nagios2, nach einem Benutzernamen und einem Passwort gefragt werden.

Nun geht es los mit der Konfiguration.
Dabei sollte ich vielleicht noch ein paar Worte über das Konzept verlieren.
Wenn man den Aufbau mal verstanden hat ist es eigentlich gar nicht mehr so kompliziert

Für meine Server habe ich ein neuer Ordner angelegt:

sudo mkdir /etc/nagios2/meinnetzwerk/
cd /etc/nagios2/meinnetzwerk/

Darin werden nun alle Dateien angelegt.
Die wichtigsten Dateien, auf welche Nagios zurückgreift, sind hosts.cfg, templates.cfg, services.cfg und hostgroups.cfg.

Besonders die templates.cfg spielt in grösseren Netzwerken mit vielen Servern eine besondere Rolle. Doch dazu später.

Wir beginnen erstmal mit dem formellen Teil. Die Datei contacts.cfg birgt den Namen und die eMail-Adresse des Systemadministrators.
Dazu erstellen wir die Datei erst neu:

sudo touch contacts.cfg

Diese füllen wir mit folgendem Inhalt:

define contact{
contact_name administrator
alias DEIN-NAME
service_notification_period 24×7
host_notification_period 24×7
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 DEINE@EMAIL.ADRESSE
}

define contactgroup{
contactgroup_name admins
alias Nagios Administrators
members administrator
}

Nun können wir unsere ersten Server hinzufügen.
Diese werden in der hosts.cfg aufgelistet. Doch einfach die IP-Adressen einzutragen wäre natürlich viel zu einfach

define host{
host_name SERVERNAME
alias BESCHREIBUNG
address IP.ADRESSE.HIER.EINGEBEN
use generic-host
}

Hier muss für jeden Host ein neuer “define host{}” angelegt werden.

Bis auf use sind eigentlich alle Punkte selbst erklärend. Und damit kommen wir auch schon zum gut durchdachten Konzept von Nagios.
Wir könnten jede einzelne Option wie Prüfintervalle, verwendete Kommandos, Benachrichtigungen, Maximale Überprüfungen etc für jeden Host einzelne definieren. Das wären dann pro Host alleine schon 40 Zeilen.
Nun kann man sich mal überlegen, was passiert wenn ich 20 oder sogar 100 Server eintragen und überwachen will – die Komplexität steigt und es wird schnell mal unübersichtlich.

Darum kann man mittels use eine Art Link zu einem Eintrag in der Datei templates.cfg legen.

Darin kann man Profile definieren, wo alles aufgeführt ist, was bei mehreren Servern gleich ist:

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_period 24×7 ; By default, Linux hosts are checked round the clock
check_interval 5 ; Actively check the host every 5 minutes
retry_interval 1 ; Schedule host check retries at 1 minute intervals
max_check_attempts 3 ; Check each Linux host 10 times (max)
check_command check-host-alive ; Default command to check Linux hosts
notification_period 24×7 ; Linux admins hate to be woken up, so we only notify during the day
notification_interval 30 ; Resend notifications every 2 hours
notification_options d,u,r ; Only send notifications for specific host states
contact_groups nagios-admins ; Notifications get sent to the admins by default
register 0 ; DONT REGISTER THIS DEFINITION – ITS NOT A REAL HOST, JUST A TEMPLATE!
}

Dabei ist wichtig, dass unter Name in der templates.cfg und unter use in der hosts.cfg der selbe Name steht.

Natürlich kann man nicht nur Server, sondern auch einzelne Services überwachen lassen. Diese werden in der Datei services.cfg eingetragen:

define service{
use generic-service
service_description HTTP
check_command check_http!80
host_name webserver01
}

Im Gegensatz zu einem Host verwendet man hier natürlich am Anfang define service. Weiter ist hier der Punkt check_command aus dem Template entfernt worden, da dieser bei einem Service je nach Art variiert. Im Beispiel wird überprüft ob eine HTTP Verbindung auf Port 80 aufgebaut werden kann.

Auch in der templates.cfg sieht es ähnlich aus:

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 0 ; Process performance data
retain_status_information 1 ; Retain status information across program restarts
retain_nonstatus_information 1 ; Retain non-status information across program restarts
is_volatile 0 ; The service is not volatile
check_period 24×7 ; The service can be checked at any time of the day
max_check_attempts 3 ; Re-check the service up to 3 times in order to determine its final (hard) state
normal_check_interval 5 ; Check the service every 10 minutes under normal conditions
retry_check_interval 1 ; Re-check the service every two minutes until a hard state can be determined
contact_groups nagios-admins ; Notifications get sent out to everyone in the ‘admins’ group
notification_options c,r ; Send notifications about warning, unknown, critical, and recovery events
notification_interval 20 ; Re-notify about service problems every hour
notification_period 24×7 ; Notifications can be sent out at any time
register 0 ; DONT REGISTER THIS DEFINITION – ITS NOT A REAL SERVICE, JUST A TEMPLATE!
}

Was noch wichtig zu erwähnen ist, dass Konfiguration in der hosts.cfg denen in templates.cfg vorgezogen werden!

Und damit noch lange nicht genug
Auch inner der templates.cfg-Datei werden keine redundanten Einträge benötigt:

define service{
name service1 ; The name of this
…allgemeine settings…
}

define service{
name service2
use service1
…spezifischere settings…
}

Ich kann also innerhalb der templates auch mittels use auf einen schon vordefinierten Eintrag verweisen.

In der Datei hostgroups.cfg kann man Einstellungen anhand vom Typ eines Servers vornehmen. Intressant wird dies aber erst wenn man mehrere gleiche Server, mit gleichen Aufgaben oder Services betreibt.
Da dies bei mir aber nicht der Fall ist, habe ich mich damit nicht weiter beschäftigt.

Nun fehlt uns noch eine Datei: die timeperiods.cfg.
Diese ist in der Standardkonfiguration bereits in Ordnung und kann einfach kopiert werden:

sudo cp /etc/nagios2/conf.d/timeperiods_nagios2.cfg /etc/nagios2/meinnetzwerk/timeperiods.cfg

Nun haben wir mal eine Grundkonfiguration erstellt und können das Ergebnis anschauen. Doch dazu müssen wir Nagios erst mal noch mitteilen, dass wir nun einen eigenen Ordner, nämlich /meinnetzwerk/ verwenden!
Dazu öffnen wir die Datei /etc/nagios2/nagios.cfg mit einem Editor und ergänzen diese mit folgendem Eintrag:

cfg_dir=/etc/nagios2/meinnetzwerk

Bevor wir nun unseren Deamon neustarten, prüfen wir noch unsere Konfiguration.
Dazu beinhaltet der Befehl nagios2 den Schalter -v:

nagios2 -v /etc/nagios2/heimnetzwerk/hosts.cfg
nagios2 -v /etc/nagios2/heimnetzwerk/services.cfg
nagios2 -v /etc/nagios2/heimnetzwerk/templates.cfg

Erhält man hier keinen Fehler, so kann man nagios2 neustarten:

sudo /etc/init.d/nagios2 restart

Nun weden in der Weboberfläche bereits die ersten Server und Services aufgeführt und dargestellt.
Wenn man das aber tatsächlich einsetzen will, so sollte man die Konfiguration noch extrem verfeinern und auf seine Bedürfnisse abstimmen!

Was ich bis jetzt noch nicht hingekriegt habe, ist das überwachen von Prozessen, Ressourcen wie CPU, RAM, Diskspace und anderen spezifischen, lokalen Vorgängen.

Dies sollte aber kein grosses Problem mehr sein, dazu aber in einem anderen Beitrag mehr!

In der Hoffnung möglichst viel aus dem Server herauszuholen, habe ich mich für ein ESXi als Betriebssystem entschieden.

Die Wahl viel eigentlich relativ schnell, da ich so mehrere Server betreiben kann. Ein weiterer Vorteil von ESXi gegenüber allen anderen Virtualisierungssystemen die ich kenne ist, dass man mehr einer vMaschine mehr Ressourcen zuordnen kann als eigentlich vorhanden ist. Und da ich “nur” 2x 2.8Ghz und 4GB Ram (soll bald auf 6GB aufgerüstet werden) zur Verfügung habe, kann dies noch ganz praktisch sein.

Doch bevor ich das OS installierte, wollte ich erst noch das RAID einrichten. (Vorab; im Server stecken zwei 18GB und zwei 72GB Platten.)

Aufgrund der Konstellation der Platten fiel meine Wahl recht schnell. So wurden die beiden 18GB Platten mittels RAID 1 und die 72GB Platten zu einem RAID 0 zusammengefasst.

So war das Betriebssystem, welches auf den 18er beherbergt wurde durch ein RAID geschützt.

Doch zurück zur Installation: So schnell die Wahl auch viel, umso länger dauerte die Installation. Begonnen habe ich mit dem normalen ESXi 4.0 von der VMware-Seite.

Als ich mich nach einem erfolglosen Installationsversuch weiter umgesehen habe, bin ich auf ein ESXi 4.0 for HP gestossen. Doch auch dies wollte den modifizierten  Linuxkernel, welcher die Basis von ESX und ESXi bildet nicht booten lassen.

Nach erneuter Suche habe ich ganz am unteren Ende der VMware-Seite einen unscheinbaren Link ausgemacht:

“VMware ESXi 4.0 is certified to run on a broad range of 64-bit hardware. For 32-bit hardware support, download the previous version, VMware ESXi 3.5.”

Also habe ich auch noch ESXi 3.5 auf CD gebrannt und gebootet. Und siehe da!! Nach gerade mal 15 Minuten war das Betriebssystem installiert und konnte gestartet werden.

Einrichten und Konfigurieren des ganzen geht problemlos über die ein bisschen farblose Oberfläche. Und viel mehr als eine statische IP muss man hier auch nicht tun. Praktisch hierbei war für mich, dass ich, dank dem iLO Port (ähnlich einer Remote Management Karte), das ganze ohne weiteren Bildschirm und Tastatur managen konnte.

Dann war es endlich soweit!

Vom Server selbst kann man dann den VMware Infrastructure Client herunterladen, welche, entgegen meinen Erwartungen, nicht nur für Windows verfügbar ist.

Diese kurz installiert und schon wird auf den Server verbunden. Als erstes sollte man hier das Passwort ändern, ausser man steht auf Überraschungsbesucher

Nachdem auch das erledigt ist, kann man schon seine ersten virtuellen Server anlegen. Besonders gut gefällt mir hier, die Möglichkeit ein ISO oder Laufwerk vom lokalen Computer direkt dem Server zu übergeben.

Das Aufsetzten einer neuen VM ist sichtlich einfach und genau gleich gehalten wie bei allen anderen VMware Produkten. Dadurch war schon nach kurzer Zeit mein erster Ubuntu 8.04 LTS Server verfügbar und online.

Doch bevor ich loslegte, wollte ich erst noch die VMware Tools installieren. Dazu gibt es den Menupünkt “Install VMware Tools” unter VM.

Nach einem Klick darauf habe ich auf eine Rückmeldung meines Servers gewartet – leider vergebens. Unwissend ob es nun geklappt hat oder nicht, machte ich mich auf die Suche nach einer Hilfestellung und bin dabei über einen Beitrag von Roman gestolpert, womit sich auch dieses kleine Problem lösen liess.

Da der DL380 Server alles andere als Stromsparend ist, wollte ich auch noch WOL aktivieren. Vom Einrichten von WOL auf einem Client wusste ich noch, wie mühsam es sein kann, war jedoch umso erstaunter, als sich die ganze Konfiguration in einem Punkt im BIOS verflüchtigte.

Nach ca 2 Stunden war mein ESXi-Server aufgesetzt und konfiguriert und mein erster virtueller Server online und ich glücklich

Fotos folgen noch