Icinga

7.5. Service- und Host-Frische-Prüfungen

7.5.1. Einführung
7.5.2. Wie funktioniert die Frische-Prüfung?
7.5.3. Frische-Prüfungen aktivieren
7.5.4. Beispiel
7.5.5. "Check results ... are stale. Forcing an immediate check ...

7.5.1. Einführung

Icinga unterstützt ein Feature, das die "Frische" (Freshness) der Host- und Service-Prüfungen überprüft. Der Zweck der Frische-Prüfung ist es, bei passiven Host- und Service-Prüfungen sicherzustellen, dass diese regelmäßig von externen Applikationen zur Verfügung gestellt werden.

Frische-Prüfungen sind sinnvoll, wenn Sie sicherstellen wollen, dass passive Prüfungen so regelmäßig empfangen werden wie Sie das erwarten. Das kann in verteilten und Failover Überwachungsumgebungen sehr sinnvoll sein.

7.5.2. Wie funktioniert die Frische-Prüfung?

Icinga prüft periodisch die Frische der Ergebnisse für alle Hosts und Services, bei denen Frische-Prüfungen aktiviert sind.

Hinweis: Eine aktive Prüfung wird ausgeführt, selbst wenn aktive Prüfungen programmweit oder auf Host- bzw. Service-spezifischer Basis deaktiviert sind.

Wenn Sie beispielsweise einen Frische-Schwellwert von 60 für einen Ihrer Services haben, wird Icinga diesen Service als abgestanden ansehen, wenn das letzte Prüfergebnis älter als 60 Sekunden ist.

7.5.3. Frische-Prüfungen aktivieren

Was Sie tun müssen, um Frische-Prüfungen zu aktivieren...

Hinweis: Wenn Sie keinen Host- oder Service-spezifischen freshness_threshold-Wert angeben (oder ihn auf Null setzen), wird Icinga automatisch einen Schwellwert berechnen, der darauf basiert, wie oft Sie den jeweiligen Host- oder Service überwachen. Wir würden empfehlen, dass Sie explizit einen Frische-Schwellwert angeben, statt dass Icinga einen für Sie auswählt.

7.5.4. Beispiel

Ein Beispiel für einen Service, der eine Frische-Prüfung benötigen könnte, wäre einer, der den Status Ihrer nächtlichen Backups meldet. Vielleicht haben Sie ein externes Script, welches das Ergebnis des Backup-Jobs an Icinga meldet, sobald das Backup beendet ist. In diesem Fall werden alle Prüfungen/Ergebnisse für diesen Service durch eine externe Applikation mit Hilfe von passiven Prüfungen zur Verfügung gestellt. Um sicherzustellen, dass der Status des Backup-Jobs täglich gemeldet wird, können Sie die Frische-Prüfung für diesen Service aktivieren. Falls das externe Script das Ergebnis des Backup-Jobs nicht meldet, kann Icinga ein kritisches Ergebnis imitieren, indem man folgendes tut...

Nachfolgend, wie die Definition für den Service aussehen könnte (einige benötigte Optionen fehlen...)

 define service{
        host_name               backup-server
        service_description     ArcServe Backup Job
        active_checks_enabled   0               ; aktive Prüfungen sind NICHT aktiviert
        passive_checks_enabled  1               ; passive Prüfungen sind aktiviert (dadurch werden Ergebnisse gemeldet)
        check_freshness         1
        freshness_threshold     93600           ; 26 Stunden Schwellwert, nachdem Backups nicht immer zur gleichen Zeit beendet sind
        check_command           no-backup-report        ; dieses Kommando wird nur ausgeführt, wenn der Service als "abgestanden" angesehen wird
        ...andere Optionen...
        }

Beachten Sie, dass aktive Prüfungen für den Service deaktiviert sind. Das ist so, weil die Ergebnisse für den Service nur durch eine externe Applikation geliefert werden. Die Frische-Prüfung ist aktiviert und der Frische-Schwellwert ist auf 26 Stunden gesetzt. Das ist ein bisschen mehr als 24 Stunden, weil Backup-Jobs ab und zu länger dauern (abhängig davon, wie viele Daten zu sichern sind, wie viel Netzwerkverkehr herrscht, usw.). Das no-backup-report-Kommando wird nur ausgeführt, wenn die Ergebnisse des Service als abgestanden angesehen werden. Die Definition des no-backup-report-Kommandos könnte wie folgt aussehen...

 define command{
        command_name    no-backup-report
        command_line    /usr/local/icinga/libexec/check_dummy 2 "CRITICAL: Results of backup job were not reported!"
        }

Falls Icinga erkennt, dass das Service-Ergebnis abgestanden ist, wird es das no-backup-report-Kommando als eine aktive Service-Prüfung ausführen. Das führt dazu, dass das check_dummy-Plugin ausgeführt wird, das einen kritischen Status an Icinga meldet. Der Service wird dann in einen kritischen Zustand gehen (falls das nicht bereits der Fall ist) und wahrscheinlich wird jemand über das Problem informiert.

7.5.5. "Check results ... are stale. Forcing an immediate check ...

Manchmal finden Sie vielleicht Meldungen wie die folgende in icinga.log:

 Check results for service x on host y are stale by 0d 0h 0m 10s (threshold=0d 0h 10m 0s).
 Forcing an immediate check of the service...

Das bedeutet, dass der Service in der Vergangenheit geprüft wurde und die als Schwellwert definierte Zeit (z.B. 10min) vergangen ist, ohne dass ein neues Prüfergebnis geliefert wurde, so dass eine Prüfung durch den Core erzwungen wird.

Die Meldung kommt aus dem Code-Fragment in base/checks.c (Zeilen wurden umgebrochen, um die Lesbarkeit zu verbessern)

 /* the results for the last check of this service are stale */
    if (expiration_time < current_time) {

       get_time_breakdown((current_time - expiration_time), &days, &hours, &minutes, &seconds);
       get_time_breakdown(freshness_threshold, &tdays, &thours, &tminutes, &tseconds);

       /* log a warning */ 
       if (log_this == TRUE)
          logit(NSLOG_RUNTIME_WARNING, TRUE,
             "Warning: The results of service '%s' on host '%s' are stale by %dd %dh %dm %ds (threshold=%dd %dh %dm %ds).
             I'm forcing an immediate check of the service.\n",
             temp_service->description, temp_service->host_name,
             days, hours, minutes, seconds, tdays, thours, tminutes, tseconds
          );

       log_debug_info(DEBUGL_CHECKS, 1,
          "Check results for service '%s' on host '%s' are stale by %dd %dh %dm %ds (threshold=%dd %dh %dm %ds).
          Forcing an immediate check of the service...\n",
          temp_service->description, temp_service->host_name,
          days, hours, minutes, seconds, tdays, thours, tminutes, tseconds
       );

       return FALSE;
    }

Normalerweise trifft folgendes zu

Falls der Service nicht jetzt, aber bereits in der Vergangenheit geprüft wurde (event_start > last_check) und der Schwellwert 0 ist, wird max_service_check_spread multipliziert mit dem Intervall als zusätzlicher Offset addiert (das passiert während der Startphase, um festzustellen, wann die erste Prüfung (und Status + Ausgabe) erfolgen muss).