Einleitung

Eines der Features von Nagios is die Fähigkeit Dienst-Überprüfungen parallel auszuführen. Dieses Kapite der Dokumentation versucht im Detail zu erklären, was dies bedeutet und wie es die definierten Dienste beeinflusst.

Wie parallele Überprüfungen funktionieren

Bevor man erklären kann, wie parallele Überprüfungen funktionieren, muss man zuerst ein bisschen davon verstehen, wie Nagios Ereignisse plant. Alle interne Ereignisse in Nagios (z.B. Rotation der Log-Datei, Überprüfung von externen Befehlen, Dienst-Überprüfungen, usw.) werden in einer Warteschlange platziert. Für jeden Eintrag in dieser Ereignis-Warteschlange wird die Ausführung zu einem angegebenen Zeitpunkt geplant. Nagios tut sein bestes, um sicherzustellen, dass alle Ereignisse genau dann ausgeführt werden, wenn sie es sollen. Trotzdem kann es passieren, dass sich die Ausführung verzögert, wenn Nagios noch mit einem anderen internen Ereignis beschäftigt ist.

Dienst-Überprüfungen ist eine Art von Ereignissen, die über die Ereignis-Warteschlange von Nagios geplant werden. Wenn es an der Zeit ist eine Dienst-Überprüfung auszuführen, startet Nagios (über den fork()-Aufruf) einen neuen Prozess, damit dieser den Dienst (z.B. über irgendein Plugin) überprüft. Nagios wartet allerdings nicht auf die Beendigung der Dienst-Überprüfung! Stattdessen geht Nagios sofort zu dem nächsten Dienst über, der sich in der nächsten Position der Warteschlange befindet.

Was passiert also, wenn eine Dienst-Überprüfung fertig ausgeführt wurde? Der Prozess der von Nagios für die Überprüfung gestartet wurde sendet eine Nachricht an Nagios zurück, die das Ergebnis der Dienst- Überprüfung enthält. Anschliessend ist es an Nagios das Ergebnis der Dienst-Überprüfung zu überprüfen und zu verarbeiten, wenn der nächste Zeitpunkt dafür ist.

Damit Nagios überhaupt irgendwelche Überwachungen durchführen kann, muss es die Ergebnisse der Dienst-Überprüfungen die fertiggestellt wurden verarbeiten. Dies wird von einem Dienst, dem sogenannten "service reaper", erledigt. "Service Reaper" sind eine Art von Ereignissen, die durch die Warteschlange von Nagios geplant werden. Die Frequenz mit der die Reaper-Ereignisse werden durch die service_reaper_frequency-Option in der Haupt-Konfigurationsdatei festgelegt.
Wenn ein Reaper-Ereignis ausgeführt wird, überprüft es ob irgendwelche Nachrichten existieren, die das Ergebnis einer Dienst-Überprüfung enthalten. Dieser Ergebnisse der Dienst-Überprüfungen werden anschliessend von dem Kern der Dienst-Überwachungs-Logik verarbeitet.
An dieser Stelle erkennt Nagios, ob z.B. Host-Überprüfungen ausgeführt oder Benachrichtigungen versandt werden müssen. Wenn das Ergebnis der Dienst-Überprüfung verarbeitet wurde, plant Nagios den Zeitpunkt der nächsten Überprüfung und platziert die Überprüfung in der Warteschlange.
Der letzte Schritt vervollständigt den Zyklus der Dienst-Überprüfungen!

For diejenigen, die es genauer wissen wollen, aber nicht in den Quellcode geschaut haben; Nagios benutzt "message queues" um die Kommunikation zwischen Nagios und den Prozessen die die Überprüfungen ausführen zu ermöglichen.

Potentielle Stolperfallen...

Man sollte realisieren, das es einige potentielle Stolperfallen gibt um Dienst-Überprüfungen parallel auszuführen. Da durch die Parallelisierung mehr als nur eine Überprüfung zur gleichen Zeit laufen können, können sich diese u.U. gegenseitig behindern. Man muss sich die Arten der Überprüfungen genauer anschauen, um die richtigen Schritte zu unternehmen, um eventuelle Abarten im Betrieb zu erkennen. Dies ist z.B. wichtig, wenn man mit mehr als einer Überprüfung parallel auf Hardware (z.B. ein Modem) zugreifen will. Genauso sollte darauf geachtet werden, dass ein entsprechender Daemon parallele Verbindungen unterstützt, wenn z.B. durch parallele Überprüfungen gleichzeitig auf einen entfernten Host mit Hilfe eines Daemons zugegriffen wird.

Glücklicherweise gibt es ein paar Dinge, die man unternehmen kann, damit einige Typen von Überprüfungen nicht miteinander kollidieren...

1. Der einfachste Weg um die Kollision von parallelen Dienst-Überprüfungen zu verhindern, ist die Benutzung der service_interleave_factor-Variable. Ausgelassene Dienste helfen die durch eingehende Überprüfungen ausgelösten Lasten auf einem überwachten, entfernten Host zu reduzieren. Setzt man die Variable so, dass der Auslassungs-Faktor "smart" errechnet wird, kann man diese anschliessend per Hand verändern, um das gewünschte Ergebnis zu erzielen.
2. Die zweite Sache, die man unternehmen kann, ist es das max_check_attempts-Argument in jeder Dienst-Definition auf einen Wert grösser als eins zu setzen. Falls die Dienst-Überprüfung dann mit einer anderen laufenden Überprüfung kollidiert, wird Nagios max_check_attempts-1 Mal versuchen die Überprüfung erneut auszuführen, bevor irgendein Kontakt über ein Problem benachrichtigt wird.
3. Man kann versuchen eine Art "abwarten und nochmal versuchen"-Logik in den Quellcode der Befehls zur Dienst-Überprüfung zu implementieren, obwohl man es evtl. als zu schwierig oder zu zeitraubend ansieht.
4. Falls alles andere fehlschlägt, kann man Dienst-Überprüfungen daran hindern parallel zu anderen ausgeführt zu werden, indem man die max_concurrent_checks-Option auf "1" setzt. Dies erlaubt es, das nur jeweils eine Dienst-Überprüfung parallel ausgeführt wird, also keine wirklich spektakuläre Lösung.
   Falls es genügend Anforderungen gibt, wird Ethan Galstad eine Option zu der Dienst-Definition hinzufügen, die es erlaubt pro Dienst anzugeben ob die Dienst-Überprüfung parallel mit anderen Überprüfungen laufen kann oder nicht.

Ausserdem sollte man beachten, wie parallele Dienst-Überprüfungen die lokalen System-Ressourcen auf dem Host, auf dem Nagios installiert ist, beeinflussen. Führt man zu viele Dienst-Überprüfungen parallel aus kann dieses die CPU und den Speicher vielleicht zu stark fordern. Die inter_check_delay_method versucht die Last auf der Maschine gleichmässig zu halten, indem die Überprüfungen gleichmässig über einen Zeitraum verteilt werden (wenn man hier die "smart"-Methode benutzt), doch dies ist keine Garantie für ein gutes Lastverhalten des Monitoring-Servers. Um kontrollieren zu können, wie viele Überprüfungen parallel laufen dürfen, nutzt man die max_concurrent_checks-Variable. Mit diesem Wert sollte man ein bisschen, auf Basis der Gesamtanzahl der zu überwachenden Dienste, den zur Verfügung stehenden System-Ressourcen und anderen Prozessen die auf dem gleichen Server laufen, herumprobieren.
Weitere Informationen wie man den ideealen Wert für die max_concurrent_checks-Variable für das eigene Setup herausfindet, findet man in dem Dokumentations-Kapitel über die Planung der Dienst-Überprüfungen.

Was wird nicht parallel ausgeführt?

Es ist wichtig sich daran zu erinnern, dass ausschliesslich die Ausführung von Dienst-Überprüfungen parallelisiert werden können - und zwar aus einem guten Grund. Andere Teile von Nagios können in keiner sicheren Art und Weise parallel ausgeführt werden. Vor allem Event-Handler, Kontakt-Benachrichtigungen, die Verarbeitung der Ergebnisse der Dienst-Überprüfungen und Host-Überprüfungen können nicht parallelisiert werden. Aus den folgenden Gründen:

Event Handler werden aufgrund ihres Zwecks nicht parallel ausgeführt. Ein Grossteil der Macht von Event Handlern liegt in der Fähigkeit proaktiv Probleme zu lösen. Ein Beispiel ist z.B. der erneute Start des Web-Servers, wenn der HTTP-Dienst nicht mehr verfügbar ist. Um zu verhindern, dass mehrere Event Handler parallel (ohne Kenntnis von dem jeweils anderen Event Handler) versuchen das gleiche Problem zu beheben, wurden Event Handler nicht parallelisiert.

Benachrichtigungen erfolgen auch nicht parallel, aufgrund der möglichen Benachrichtigungs-Methoden, die evtl. eingesetzt weden. Falls eine Benachrichtigung z.B. eine Nachricht über ein Modem versendet, benötigt dieses einen exklusiven Zugriff aud das Modem, während die Benachrichtigung erfolgt. Falls nun mehrere dieser Benachrichtigungen parallel ausgeführt würden, würde nur eine Benachrichtigung erfolgreich abgeschlossen werden, da alle anderen Benachrichtigungs-Prozesse kein Zugriff auf das Modem gehabt hätten. Es gibt zwar wege um dieses herumzukommen, z.B. indem an eine "abwarten und erneut versuchen"-Methode in das Benachrichtigungs-Skript implementiert. Ethan Galstad hat sich aber dafür entschieden, sich nicht darauf zu verlassen, dass die User das dafür nötige Feature in ihren Skripten implementiert haben.
Ein schneller Hinweis:
falls Dienst-Überprüfungen über ein Modem ausgeführt werden, sollte man sicherstellen, dass die Skripte für die Benachrichtigung eine Möglichkeit haben den Zugriff auf das Modem mehrfach zu versuchen. Dies ist nötig, da u.U. eine Dienst-Überprüfung zu dem gleichen Zeitpunkt ausgeführt wird wie eine Benachrichtigung über ein Modem!

Verarbeitung von Ergebnissen von Dienst-Überprüfungen wurde nicht parallelisiert. Dies wurde so entschieden um Situationen zu verhinden, in denen parallele Benachrichtigungen darüber versandt werden, das ein Host down geht, unerreichbar oder wiederhergestellt wird.