Die alteingesessenen Nagios-Admins kennen das Problem: Es ist keines, es ist ein Feature – so habe ich mich von der Community belehren lassen!

Es hängt zusammen mit einer Statusdatei, welche Nagios anlegt, damit nach einem Neustart des Daemons nicht immer alle Checks ohne Daten dastehen und erst alles wieder aufgebaut werden muss. Deshalb wird darin der letzte Zustand gespeichert und dann auch abgerufen.
Wieso dabei auch der Hostname gespeichert und aus dieser Datei anstelle der Konfigurationsdatei ausgelesen wird, kann ich mir leider nicht erklären. Aber eben: Das ist ein Feature, kein Bug!

Die Lösung des Problems liegt darin, dass der Name nicht nur in der offiziellen Konfigurationsdatei, sondern auch in der Statusdatei unter var/retention.dat angepasst wird. Bevor das geschieht, muss aber der Nagios-Daemon gestoppt werden.

Also (der Pfad der Nagios-Installation bitte anpassen):

/etc/init.d/nagios stop
vi /usr/local/nagios/var/retention.dat
/etc/init.d/nagios start

Verzweifelt nicht an euer Sehkraft, es ist wirklich so

Das könnte dich auch interessieren:

1. Unbekannte Systeme in Nagios Die Nagios Status Map ist ja eine ganz feine Sache,...
2. Notification von Nagios ans iPhone Auf der Suche nach einer Lösung, wie ich die Notifications...
3. Windows Updates prüfen mit Nagios Um unserer Server optimal überwachen zu können, habe ich eine...
4. Nagios als Inventory-Lösung Heute bin ich über ein interessantes Script gestossen, welches aus...
5. NRPE Module installieren Aktuell arbeite ich an einer Lösung, um mittels Nagios zu...

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!