Nagios ohne Host Checks

Wie schon oft besprochen sind Host Checks ein Performanceproblem in großen Nagios Installationen. Diese HowTo soll eine Möglichkeit aufzeigen aus dieser Falle zu entgehen.

ACHTUNG: Dieses Howto ist wirklich nur für Anwender die wissen was sie damit erreichen wollen!

Nagios prüft normalerweise nur Services. Host Checks werden nur durchgeführt, wenn ein Service auf einem Host nicht OK ist. Nagios führt dann das Command aus das diesem Host zugewiesen wurde. In der Regel wird das ein Ping sein.

In der Zeit bis Nagios den Host geprüft hat, werden keine weiteren Services geprüft. Nagios muss so vorgehen um zu entscheiden ob das Problem beim Host oder beim service liegt. Hat man nun diesem Host noch Parents zugewiesen, so versucht Nagios die Quelle des Problems zu finden indem die Parents Kette bis zu dem Host verfolgt wird der wirklich ein Problem hat.

Dabei kann es aber zu Problemen kommen, wenn

1. das check_command des Hosts sehr lange braucht, oder sogar auf einen Timeout läuft.
2. die Kette der Parents sehr lang ist.
3. alles zusammen kommt.

Resultat ist eine sehr hohe „check latency“. Nagios ist so sehr damit beschäftigt die einzelnen Hosts zu prüfen, so das keine Zeit für Service Checks mehr bleibt.

Ein weiteres Problem ist das Nagios bei Host checks keinen retry_check_interval kennt. Setzt man max_check_attempts auf 3, so führt Nagios den Host Check 3 mal aus, jedoch im Abstand von nur wenigen Sekunden. Befindet sich der Host zusätzlich noch hinter einer Standleitung, kann es hierbei zusätzlich noch zu Fehlalarmen kommen.

Eigentlich wäre es besser Host Checks wie Service Checks zu behandeln.

Eine Lösung wird ja bereits hier beschrieben. Ich möchte aber mal eine Alternative dazu aufzeigen, die auch in anderen Bereichen einsetzbar ist.

Darunter versteht Ethan die Möglichkeit das Verhalten von Nagios zur Laufzeit zu verändern. Dabei sind auch die on-demand Makros inbegriffen.

on-demand Makros werden in der Nagios Doku bei der Prüfung von Clustern mit Hilfe von check_cluster beschrieben. darunter versteht man die Möglichkeit innerhalb der Nagios Config auf den Inhalt von Makros zuzugreifen, die nichts mit dem aktuellen Service zu tun haben.

In unserem Fall werden wir also den Host Check auf einen Service Check abbilden.

Jeder Host bekommt einen Service „CONN“ zugewiesen, der die Erreichbarkeit des Hosts als Service prüft. Normalerweise wird das Plugin check_icmp dafür benutzt, es kann aber auch jedes andere Plugin verwendet werden.

Diesen Service planen wir jetzt in etwas geringeren Intervallen als die normalen Service Checks ein, um sicherzustellen, das der Service CONN zuerst Critical/HARD wird.

Also beispielsweise normal_check_interval 2 , retry_check_interval 1 , max_check_attempts 2

Dazu benutzen benutzen wir ein Shell Script das den Status des Service als Option übergeben bekommt und demendsprechen eine Ausgabe für Nagios mit dem passenden Returncode erzeugt

#!/bin/bash
STATEID=$1
ATTEMPTS=$2

MAX=2 #Maximun check attempts before host is reportet as down
if [ "$STATEID" -eq 0 ];then
   echo "OK: adaptive host check returns UP" 
   exit $STATEID
else
   if [ "$ATTEMPTS" -ge "$MAX" ];then
      echo "CRITICAL: host problem detected. Max check_attempts ($MAX) reached"
      exit $STATEID
   else
      echo "OK: host problem detected but max check_attempts not reached"
      exit 0
   fi
fi

Nehmen wir das Plugin check-host-adaptive.sh und speichern es bei den anderen Plugins im Verzeichnis libexec.

check-host-adaptive.sh wird mit 2 Argumenten aufgerufen $ARG1$ wird später den Returncode übernehmen und $ARG2$ wie oft der Service Check bereits ausgeführt wurde.

 define command{
        command_name    check-host-adaptive
        command_line    $USER1$/check-host-adaptive.sh $ARG1$ "$ARG2$"
        }

Der ein oder andere wird sich hier fragen was das bringen soll.
Dafür kommen jetzt die on-demand Makros ins Spiel.

define host{
        ....
        check_command           check-host-adaptive!$SERVICESTATEID:server1:CONN$!$SERVICEATTEMPT:server1:CONN$
        host_name               server1
        alias                   Mein erster Server
        address                 127.0.0.1
        ....
}

Mit diesem check_command wird sozusagen der Status des Services „CONN“ auf Host „Server1“ auf den Hostcheck abgebildet.

Wobei man zusätzlich noch bestimmen kann nach wie vielen ausgeführten Service Checks der Host wirklich als DOWN gekennzeichnet werden soll.

Dabei wird zuerst das Makro $SERVICESTATEID$ verwendet. Durch Angabe zweier zusätzlicher Werte (:hostname:servicedesc) wird allerdings nicht der Wert für den aktuellen Host/Service ausgegeben, stattdessen wird der Wert des angefrageten Host/Service geliefert. Also der Status von Service „CONN“ auf Host „server1“.

Ist der Service OK, wird dieses Makro den Wert 0 ( für OK ) enthalten und dementsprechend wird 0 als erstes Argument ( $ARG1$ ) an check-host-adaptive übergeben. Genauso verhällt es sich bei $SERVICEATTEMPT:server1:CONN$ , nur das dort die Anzahl der check_attempts ausgegeben wird.

Der Host Status ist also der gleiche wie der Status des Service „CONN“. Dabei können keine Timeouts mehr auftreten. Check-host-adaptive läuft nur wenige Millisekunden und man hat die Möglichkeit die Host Checks feiner zu steuern.

Setzt man im Script check-host-adaptive.sh die Variable $MAX auf 1, so wird schon der Host als Down gekennzeichnet wenn sich der Service noch im Soft State befindet. Das wäre das gleiche Verhalten als wenn man ganz normal ein check-host-alive mit dem Plugin check_icmp absetzen würde. Jedoch kann sich keine check_latency aufbauen, da der Host Check nicht in einen Timeout laufen kann und somit Nagios sofort mit den Service Checks weiter macht.

Dies ist denke ich eine guter Ansatz um die Performance in Verteilten Nagios Umgebungen zu verbessern.

Weiterhin kann man auf diesem Weg Fehlalarme der Host Checks vermeiden.

Angenommen man kann einige Server nur über WAN Strecken erreichen. Auf diesen WAN werden ICMP Pakete nicht vorrangig behandelt. Es kann also vorkommen das Pakete verloren gehen, oder die Leitung kurzfristig nicht zur Verfügung stand.

Über den oben aufgezeigten Weg kann man nun über die den Service Check den Host Status beeinflussen indem man die Variable MAX in check-host-adaptive erhöht.

Nun muss die Leitung schon 2 Minuten nicht zur Verfügung stehen bis eine Notification erzeugt wird und der Host als Down gekennzeichnet wird.

Allerdings darf auch nicht unerwähnt bleiben das sich daraus auch wiederum Fehlalarme ergeben können. Dies kann Hauptsächlich beim Prüfen der Parents geschehen. Die Wahrscheinlichkeit ist aber geringer als die Fehlalarme bei einem kurzzeitigen „Leitungswackler“.

Ethan hat sich mit den on-demand Makros mal wieder selbst übertroffen. Die Möglichkeiten die sich daraus ergeben sind komplex. Leider ist diese Funktion nur nebenbei unter "Monitoring Clusters" erklärt.

Auf meinem Testsystem läuft das jetzt soweit sehr gut.

In Produktion werde ich das in den nächsten 2 Wochen ausgiebig testen und berichten.

— pitchfork 23.05.2006 19:21