Einleitung
Status "stalking" (engl. "heranpirschen") ist ein Feature, das womöglich von den meisten Usern nicht benutzt wird. Wenn aktiviert, erlaubt es Veränderungen in Dienst- und Host-Überprüfungen zu protokollieren, auch wenn sich der Status des Hosts oder Dienstes nicht direkt ändert. Wenn "stalking" für einen einzelnen Host oder Dienst aktiviert ist, wird Nagios diesen Dienst wesentlich vorsichtiger beobachten und alle Veränderungen protokollieren, die es erkennt. Wie man sieht kann dieses Feature für spätere Analysen der Log-Dateien sehr nützlich sein.
Wie funktioniert es?
Unter normalen Umständen werden die Ergebnisse von Host- und Dienst-Überprüfungen nur protokolliert, wenn sich der Status des Hosts oder Dienstes seit der letzten Überprüfungen geändert hat. Es gibt hierfür wenige Ausnahmen, in den meisten Fällen sollte dies aber die Regel sein.
Falls "stalking" für einen oder mehrere Stati eines einzelnen Hosts oder Dienstes aktivieren, wird Nagios die Ergebnisse der Host- oder Dienst-Überprüfungen protokollieren, wenn sich der Output seit der letzten Überprüfung geändert hat. Nehmen wir das folgende Beispiel von acht aufeinander folgenden Überprüfungen eines Dienstes:
Nr. d. Überprüfung: | Dienst-Status: | Ausgabe des Ergebnisses: |
x | OK | RAID array optimal |
x+1 | OK | RAID array optimal |
x+2 | WARNING | RAID array degraded (1 drive bad, 1 hot spare rebuilding) |
x+3 | CRITICAL | RAID array degraded (2 drives bad, 1 host spare online, 1 hot spare rebuilding) |
x+4 | CRIICAL | RAID array degraded (3 drives bad, 2 hot spares online) |
x+5 | CRITICAL | RAID array failed |
x+6 | CRITICAL | RAID array failed |
x+7 | CRITICAL | RAID array failed |
Bei der gegebenen Reihenfolge der Überprüfungen würde man eigentlich nur zwei Log-Einträge zu dieser Katastrophe finden. Der erste Eintrag würde bei Überprüfung "x+2" geschrieben werden, als sich der Status des Dienstes von OK auf WARNING verändert hat. Der zweite Eintrag würde bei der Überprüfung x+3 passieren, als sich der Status des Dienstes von WARNING auf CRITICAL geändert hat.
Aus welchen Gründen auch immer wird evtl. die komplette Historie dieser Katastrophe benötigt. Vielleicht weil dem Vorgesetzten später erklärt werden muss, wie schnell die gesamte Situation ausser Kontrolle geriet. Vielleicht lachen Sie zwar schon bald in Ihrer Kneipe beim nächsten Bier drüber, aber trotzdem...
Falls Sie "stalking" f+r diesen Dienst für kritische Stati aktiviert hätten, wären die Ereignisse x+4 und x+5 zusätzlich zu den Ereignissen x+2 und x+3 mitprotokolliert worden. Warum dies? Mit aktivierten Dienst-"stalking" würde Nagios die Ausgaben jeder einzelnen Überprüfung analysieren um zu sehen, ob sich die Ausgabe seit der letzten Überprüfung geändert hat. Falls sich die Ausgabe, anders als der Status, seit der letzten Überprüfung verändert hat, würde diese Ausgabe des mitgeschrieben werden.
Ein ähnliches Beispiel des "stalkings" kann auch an einem Webserver gezeigt werden. Falls das check_http-Plugin zuerst einen WARNING-Status eines 404-Fehlers und später bei folgenden Überprüfungen einen WARNING-Status aufgrund eines unerwarteten Antwort-Schemas zurückgibt, will man das vielleicht wissen. Falls "stalking" für WARNING-Stati nicht aktiviert wurde, würde nur das Event des ersten WARNING-Status (der 404-Fehler) protokolliert werden und Sie würden nicht sehen, dass die folgenden Probleme nicht aufgrund einer 404-Seite zustande kamen und evtl. in die falsche Richtung analysieren.
Sollte ich "stalking" aktiveren?
Als erste muss man entscheiden, ob man wirklich die archivierten Log-Daten analysieren muss um den exakten Grund
für ein Problem zu finden. Man kann sich aber auch nur für einzelne Dienst oder Hosts für dieses Feature entscheiden,
und nicht für alle Dienste oder Hosts.
Z.B. kann man sich auch dafür entscheiden "stalking" nur für WARNING- und CRITICAL-Stati für einen Dienst aktiviert,
aber nicht für OK- und UNKNOWN-Stati.
Die Entscheidung Status-"stalking" für einen bestimmten Host oder Dienst zu aktivieren, hängt aber auch von dem Plugin ab, dass für die Überprüfung des Hosts oder Dienstes eingesetzt wird. Falls das Plugin für einen Status immer die gleiche Text-Ausgabe an Nagios zurückgibt, macht es keinen Sinn "stalking" für diesen Status zu aktivieren.
Wie aktiviere ich "stalking"?
Man kann Status-"stalking" für Hosts und Dienste durch die stalking_options-Directive in der Host- und Dienst-Definition aktiveren. Diese Direktive wird nur in dem template-basierten Konfigurations- Dateiformat unterstützt.
Vorbehalte
Man sollte sich einiger Stolperfallen bei der Aktivierung von "stalking" bewusst sein. Diese beziehen sich alle auf die Report-Funktionen, die in vielen CGIs (Histogramm, Alarm-Zusammenfassung, etc.). Da Status-"stalking" die Protokollierung zusätzlicher Alarm-Einträge verursacht, zeigen die Berichte eine fälchlicherweise erhöhte Anzahle von Alarmen.
Als eine generelle Regel würden wir Vorschlagen, dass sie "stalking" für Dienst und Hosts nicht aktiveren, ohne das man sich Gedanken über diese Themen macht. Das Feature ist immernoch da, wenn Sie sich dafür entscheiden es zu nutzen.