Einleitung
Zeiträume erlauben es eine grössere Kontrolle darüber zu haben, wenn Dienst-Überprüfungen ausgeführt werden, wann Host- oder Dienst-Benachrichtigungen versandt werden dürfen und wann einzelne Kontaktpersonen diese bekommen dürfen. Mit dieser Kontrollmöglichkeit treten aber auch potentielle Probleme auf, wie wir später beschreiben werden. Anfangs war ich sehr zögerlich Zeiträume aufgrund der möglichen Probleme in Nagios einzuführen. Die Entscheidung diese richtig zu nutzen (oder auch garnicht auf diese Features zurückzugreifen) liegt somit bei der Konfiguration...
Wie Zeitärume mit Dienst-Überprüfungen zusammenarbeiten
Ohne die Implementierung von Zeiträumen würde Nagios alle Dienste die definiert wurden 24 Stunden am Tag, 7 Tage
die Woche überprüfen. Während dies für die meisten Dienste die überwacht werden müssen durchaus zutrifft, macht
dies für andere nicht unbedingt Sinn.
Muss man z.B. wirklich alle Drucker rund um die Uhr überwachen, wenn diese nur während der normalen
Geschäftszeiten benutzt werden? Vielleicht sollen auch Entwicklungs-Server überwacht werden. Da diese aber nicht
als "mission critical" eingestuft werden, müssen diese z.B. auch nicht über das Wochenende hinweg überwacht werden.
Die Definition von Zeiträume erlaubt diese Überwachungen genauer und effizienter zu steuern.
Das <check_period>-Argument in jeder Dienst-Definition erlaubt es anzugeben in welchen Zeiträumen dieser Dienst überprüft werden soll. Wenn Nagios die Überprüfung eines Dienstes in seiner Queue einplant, stellt es sicher, das die nächste Überprüfung zu einem gültigen Zeitpunkt innerhalb des angegebenen gültigen Zeitraumes passiert. Sollte dies nicht der Fall sein, verschiebt Nagios die nächste Überprüfung auf den nächsten gültigen Zeitpunkt. Dies heisst, dass der Dienst u.U. für eine weitere Stunde, einen Tag oder eine Woche nicht überprüft wird...
Potentielle Probleme mit Dienst-Überprüfungen
Falls ein Zeitraum benutzt wird, der nicht eine ganzen "24x7"-Zeitraum abdeckt, wird man Probleme bekommen, vor allem wenn ein Dienst (oder der dazu korrespondierende Host) down ist, wenn die Überprüfung auf den nächsten gültigen Zeitpunkt verschoben wird. Hier sind einige dieser Probleme:
Den Zeitraum für Dienst-Überprüfungen auf etwas anderes als 24 Stunden am Tag, 7 Tage die Woche zu beschränken, kann einige Probleme hervorrufen. Ok, nicht wirklich echte <Probleme> aber Nagios arbeitet dadurch nicht mehr so akkurat. Sollte man also keinen wirklich guten Grund dafür haben, empfehlen wir dringend das <check_period>-Argument jedes Dienstes auf "24x7" zu stellen.
Wie Zeiträume mit Benachrichtigungen zusammenarbeiten
Die sinnvollste Benutzung der Zeiträume ist die Kontrolle darüber, wann Benachrichtigungen an Kontaktpersonen
verschickt werden. Mit der Benutzung der <service_notification_period>- und <host_notification_period>-Argumente
in der Kontakt-Definition kann man für jeden einzelnen Kontakt eigene Zeiträume definieren, in denen diese Person
benachrichtigungen erhalten darf. Dies ist sehr nützlich, falls es z.B. gewollt ist, das Host-Benachrichtigungen
an jedem Tag der Woche an die Kontaktperson gesendet werden, Dienst-Benachrichtigungen aber nur an Wochentagen an
den Kontakt geschickt werden sollen.
Es sollte aber beachtet werden, dass diese beiden Benachrichtigungs-Zeiträume jede mögliche Zeit abdecken
müssen, damit der Kontakt benachrichtigt werden kann. Die Kontrolle über Benachrichtigungs-Zeiträume sollte pro
spezifischem Dienst und Host wie folgt passieren:
Indem die <notification_period>-Option in der Host-Definition benutzt wird, kann kontrolliert werden, wann es Nagios erlaubt ist Benachrichtigungen über Probleme oder Wiederherstellungen für diesen Host zu versenden. Wenn eine Host-Benachrichtigung verschickt werden soll, überprüft Nagios ob der Zeitpunkt auch in dem gültigen <notification_period>-Zeitraum liegt. Ist der Zeitpunkt gültig, wird Nagios jeden dem Host zugeordneten Kontakt benachrichtigen. Einige Kontaktpersonen werden die Host-Benachrichtigung aber nicht erhalten, wenn deren <host_notification_period> zu diesem Zeitpunkt keinerlei Benachrichtigungen erlaubt. Ist der Zeitpunkt nicht in der für den Host definierten gültigen <notification_period>, sendet Nagios keinerlei Benachrichtigungen aus.
Die Benachrichtigungs-Zeiträume für Dienste können in einer sehr ähnlichen Art und Weise wie für Hosts kontrolliert werden. Indem die <notification_period>-Option in der Dienst-Definition benutzt wird, kann kontrolliert werden, wann es Nagios erlaubt ist Benachrichtigungen über Probleme oder Wiederherstellungen für diesen Dienst zu versenden. Wenn eine Dienst-Benachrichtigung verschickt werden soll, überprüft Nagios ob der Zeitpunkt auch in dem gültigen <notification_period>-Zeitraum liegt. Ist der Zeitpunkt gültig, wird Nagios jeden dem Dienst zugeordneten Kontakt benachrichtigen. Einige Kontaktpersonen werden die Dienst-Benachrichtigung aber nicht erhalten, wenn deren <host_notification_period> zu diesem Zeitpunkt keinerlei Benachrichtigungen erlaubt. Ist der Zeitpunkt nicht in der für den Dienst definierten gültigen <notification_period>, sendet Nagios keinerlei Benachrichtigungen aus.
Potentielle Probleme mit Kontakt-Benachrichtigungen
Es gibt keine schwerwiegenden Probleme in die man kommen kann, wenn man Zeiträume zur Kontrolle von Benachrichtigunsg- Zeitpunkten benutzt. Man sollte sich aber bewusst sein, das bei der Benutzung von selbstdefinierten Zeiträumen ein Kontakt evtl. nicht benachrichtigt wird, wenn ein Host oder Dienst ein Problem hat oder Wiederhergestellt wird.
Zeiträume erlauben eine grössere Kontrolle darüber, wie Nagios seine Überprüfungen und Benachrichtigungen einsetzt. Die Benutzung von Zeiträumen kann aber auch zu Problemen führen. Sollte man unsicher sein, welche Art von Zeiträumen man implementiert, oder man evtl. Probleme mit der aktuellen Implementation hat, sollte man einen "24x7"-Zeitraum (in dem alle Zeiten für jeden Tag der Woche gültig sind) benutzen. Bitte schreibt doch an die Liste, wenn es Fragen oder Probleme mit der Implementation von Zeiträumen gibt.