Thomas Kramer

IT-COW | Icinga - Webinterface und Notifications

Icinga - Webinterface und Notifications

By Administrator at Juni 01, 2010 19:30
Filed Under: Administration, Anleitungen, Linux, Windows

Es folgt mein Überblick der Funktionen des Webinterfaces und einer detaillierteren Beschreibung der Notifications von Icinga. Weil das System doch sehr umfangreich ist werde ich nicht alles im Detail beschreiben. Meine Installationsanleitung zu dem System ist über diesen Link erreichbar, die erweiterte Konfiguration habe ich hier beschrieben.

 

Überblick über das Webinterface

 

Die Menü-Bar von Icinga ist im Webinterface links angeordnet und grob unterteilt auf die Bereiche General, Monitoring, Reporting und Configuration. Generell werde ich nur die wichtigsten Menüpunkte auflisten. Erwähnenswert sind auf jeden Fall die kontextabhängigen Menüpunkte, die im mittleren Bereich des Fensters je nach ausgewähltem Hauptmenüpunkt aufgelistet werden.

 

General-Bereich

 

Der Home-Menüpunkt zeigt die Versionsnummer von Icinga, einen Link zu den Änderungen (seit der letzten Version) und einen Copyrightvermerk darunter an. Anders als man meinen könnte ist das _nicht_ die standardmäßig angezeigte Seite, wenn Icinga übers Webinterface aufgerufen wird. Interessanter ist der Documentation-Menüpunkt, über den die Dokumentation in deutsch und englisch aufgerufen werden kann. Darunter befindet sich der Search-Menüpunkt, über den nach Hosts, Hostgroups und Servicegroups gesucht werden kann.

 

Monitoring-Bereich

 

Über Tactical Overview, welches auch die Startseite bildet, wird eine Zusammenfassung der wichtigsten Daten angezeigt: Network Outages (Netzwerk-Ausfälle), Hosts (überwachte PCs), Services (Abfragen) und Monitoring Features. So kann man auf einen Blick (oberflächlich) sehen, wie es um die "Gesundheit" im Netzwerk bestellt ist. Monitoring Features verdient dabei eine weitere Ausführung (listet z. B. auf welche Funktionen aktiv sind), dort wird z. b. die Flap Detection von Icinga/Nagios erwähnt, die erkennt ob ein Abfrage häufig hintereinander zwischen mehreren Stati wechselt - wenn das der Fall ist werden die Benachrichtigungen temporär unterdrückt (einstellbar).

 

Icinga unterscheidet zwischen Checks, Notifications und Escalations. Checks sind einfach die Abfragen (der Service-Definitionen) an sich, Notifications sind die Rückgaben dieser Checks welche natürlich geloggt werden (egal ob Error, Info oder Warning) und über Escalations wird definiert ab der wievielten Notification (und/oder in welchem Zeitraum) eine Benachrichtigung verschickt (eskaliert) wird (natürlich nur bei Notifications vom Typ Warnung oder Fehler).

 

Als Benachrichtigungssystem ist wie bereits erwähnt per default eMail vorkonfiguriert. Gemäß der Quellen 1, 2 sollen sogar prinzipiell SMS-Benachrichtigungen verschickt werden können. Bei eMail-Benachrichtigungen werden grundsätzlich zuerst Problem-eMails und beim nächsten Check - wenn wieder alles in Ordnung ist - Recovery-eMails verschickt (wenn der lokale Mailserver korrekt konfiguriert wurde, siehe den ersten Teil meines Tutorials). Über Escalations kann ein mehrstufiges Alarmsystem realisiert werden, so das z. B. beim ersten Auftreten eines Fehlers eine eMail und nach einer bestimmten Häufigkeit eine SMS verschickt wird, damit der Admin sofort zur Firma eilt.

 

Host Detail listet alle definierten Hosts auf, zusammen mit dem aktuellen generellen Verfügbarkeitsstatus samt Uptime. Über ein Icon können alle Services eines einzelnen Hosts aufgelistet werden - wenn man meinem Tutorial genau gefolgt ist gibt es an der Stelle sogar ein zweites Icon für einen Host-abhängigen Wiki-Eintrag. Service Detail listet alle Services (Abfragen) für jeden Host auf, zusammen mit dem jeweiligen Status des Services.

 

Host Problems und Service Problems sind mit die wichtigsten Menüpunkte bei der Fehlersuche, wobei nur der aktuelle Status (jeweils einer Abfrage) angezeigt wird (nicht historisch). Network Outages sind die aktuellen Netzwerkausfälle.

 

Über Process Info kann Icinga an sich neu gestartet oder die Checks, Notifications und die Flap Detection global deaktiviert werden. Performance Info liefert Performance-Statistiken und Scheduling Queue listet die zeitliche Abfolge der einzelnen Abfragen (Services) auf, wobei der Zeitplan direkt geändert werden kann (aber nur für den nächsten Aufruf).

 

Reporting-Bereich

 

Dort können Trendprognosen getroffen, die Verfügbarkeit für einen (einstellbaren) vergangenen Zeitraum eingesehen und die Fehler-Historie samt generellem Event-Log betrachtet werden. Es sind nicht nur Text-Statistiken verfügbar, sondern auch Diagramme (z. b. bei der Trendprognose).

 

Configuration-Bereich

 

Unter Configuration kann die aktuelle Konfiguration nur betrachtet, aber nicht geändert werden. Generell gilt, das dauerhafte Änderungen über einen Texteditor gemacht werden müssen. Das gilt auch für periodisch wiederkehrende (geplante) Down-Times eines Servers, z. b. Wochenenden.

 

Über die Kontext-Menüpunkte sind alle möglichen Quer-Sprünge zwischen den Funktionen möglich.

 

Weiterführende Informationen zu Notifications

 

Weil mein Windows-Server planmäßig nur zwölf Stunden am Tag läuft wollte ich natürlich nicht das mir nachts Fehler-eMails geschickt werden, wegen einer Nicht-Verfügbarkeit des Servers. Dafür wollte ich zuerst eine eigene Zeitperiode (timeperiod) in der Datei timeperiods.cfg im objects-Verzeichnis von Icinga definieren, bis ich festgestellt habe das die workhours-Zeitperiode für normale Arbeitszeiten bereits standardmäßig vorgegeben wird (kann natürlich geändert werden).

 

Diese Standard-Vorgabe wird in der template.cfg benutzt, welche Templates definiert. Diese Templates sind normale define ... -Befehle für Definitionen - die define host-Befehle bspw. in der windows.cfg oder localhost.cfg leiten von diesen mit der use-Direktive ab und sehen davon abgesehen in der Definition genauso aus. In diesem Zusammenhang empfehle ich die Anwendung des Befehls

 

sudo grep $Suchtext$ -R /usr/local/icinga

 

falls Ihr nach Textfolgen in Textdateien suchen müsst. In der Ausgabe dieses Befehls können übrigens Dateien mit einer Tilde im Namen (~) in der Regel ignoriert werden (temporäre Dateien). Auf diese Weise habe ich auch herausgefunden das die Zuweisung von contact_groups admins in der windows.cfg-Datei, wie im ersten Teil des Tutorials erwähnt, unnötig war weil das ebenfalls durch das Template vorgegeben wird.

 

Dem windows-server-Template wird nun per default als notification_period (legt fest, in welchem Zeitraum Notifications erstellt werden können, das betrifft indirekt somit auch die Escalations) die Zeitperiode 24x7 zugewiesen und dem linux-server-Template workhours. Als Kommentar heisst es dazu übrigens in der Datei: Linux admins hate to be woken up, so we only notify during the day. Diese Zuweisungen habe ich vertauscht und die workhours-Zeit auf die Betriebszeiten meines Windows-Servers angepasst. Ergänzung: an der Stelle muss auch die notification_period des Templates generic-service beachtet werden.

 

Ergänzung 08.06.2010: Ich habe zuerst gedacht mit dem notification_period-Parameter in der host-Definition (oder dem übergeordneten Template) würde ich _alle_ Benachrichtigungen für diesen Rechner zeitlich einschränken, aber das betrifft an der Stelle auch nur die Host-Notifications (Rechner Down/Recovery). Für die Service-Notifications muss derselbe Parameter analog in den Service-Definitionen angegeben werden, wenn wirklich alle Benachrichtungen zeitlich eingeschränkt werden sollen. Besser aber man regelt das über die übergeordneten Templates, denn so kann man sich Tipparbeit ersparen (wie bereits erwähnt unterstützt Icinga/Nagios Objektvererbung). Außerdem besteht die Möglichkeit kontaktseitig Zeitfilter einzuführen, aber ein Filter sollte im Allgemeinen reichen.

 

Bei mir hat es nun funktioniert und für den Windows-Server werden nachts keine eMails mehr verschickt.

 

Ergänzung 14.06.2010: Für private Einsatzzwecke sind die standardmäßig vorgegebenen 10-Minuten-Intervalle bei Service-Checks eigentlich zuviel, das Event-Log wird dann regelrecht mit Meldungen überschüttet - daher empfiehlt es sich die Direktive normal_check_interval bei den Service-Definitionen auf mindestens 60 (Minuten) zu setzen - das passt auch besser ins stündliche Raster des Event-Logs (im Webinterface), wo alle 60 Minuten ein neuer Abschnitt beginnt. Eine Ausnahme gilt aber bei Windows-Logs, bei denen sollte man das nicht machen damit keine Fehler-Meldungen verschluckt werden - richtig verschluckt werden sie zwar nicht, aber sie werden dann nur als (3 Errors) bspw. gelistet - nur der letzte Fehler wird detailliert aufgelistet. Die Abfragen für Windows-Logs habe ich bei mir zusätzlich auf notification_interval 0 und is_volatile 1 gesetzt, damit ich für jeden Fehler-Eintrag genau eine eMail erhalte.

 

Es besteht die Möglichkeit, einen Service als is_volatile (flüchtig) zu kennzeichnen (0=nicht flüchtig, 1=flüchtig). Normalerweise wird nur mit einem Zustandswechsel eine Notification erzeugt, bei einem flüchtigen Service dagegen mit jedem Fehler der auftritt - das kann für selbstdefinierte Services wichtig sein, wenn z. b. der erste Fehler der gemeldet wird irrelevant ist und eigentlich erst der zweite gemeldet werden muss (Link). Für Tests sollten die Services der besseren Nachvollziehbarkeit wegen auf is_volatile=1 gesetzt werden, das gilt vor allem für Windows-Log-Abfragen - damit man für jeden Fehler-Log-Eintrag auch eine eMail erhält.

 

Worüber man sich auch im Klaren sein sollte ist das Icinga sich bereits abgeholte Meldungen merkt - und welche Auswirkungen das in Bezug auf die Notifications hat. Wenn also z. b. ein Fehler um 7:00 aufgetreten ist, die notification_period des Services aber erst ab 8:00 beginnt, wird keine Notification für diesen Fehler mehr versandt - es sei denn, der Fehler wird nach 8:00 erneut geloggt (und der Service ist als flüchtig gekennzeichnet) oder es ist zumindest ein Notification-Intervall definiert das in diesen Zeitraum reicht. Insofern wird man in Firmen wahrscheinlich keine zeitliche Einschränkung (direkt) für die Notifications definieren und die Meldungen stattdessen durchgängig an die Firmen-eMail-Adresse verschicken - und bei erneutem Auftreten des Fehlers über Eskalationen SMS an das private Handy versenden. Oder alternativ - je nach Zeit - einen anderen Kontakt informieren.

 

Weil ich das öfter nachschlagen musste hier auch ein Überblick über die möglichen Stati der Notifications: bei den Host-Notifications wird unterschieden zwischen d(own), u(nreachable), r(ecovery), f(lapping) und s(cheduled downtime), bei den Service-Notifications zwischen c(ritical), w(arning), u(nknown), r(ecovery), f(lapping) und s(cheduled downtime) (Link).

 

Recovery-Notifications für Services sind eigentlich auch eher belanglos, in der Regel treten einzelne Fehler nicht so schnell wieder auf und die meisten Meldungen können auch einen Server nicht zum Stillstand bringen. Eine Ausnahme kann man für das System-Log machen, aber ansonsten sollten diese Benachrichtigungen im Allgemeinen (zumindest für privat) deaktiviert werden.

 

Ergänzung 15.06.2010: Bei einer Zeitdefinition bei mir habe ich den Fehler gemacht saturday 14:00-02:00 einzugeben, nur gehört die Zeit von 00:00-02:00 logischerweise nicht mehr zum Samstag, stattdessen muss man dann angeben: saturday 14:00-24:00 und sunday 00:00-02:00. Hier wurde das als das Videorecorder-Problem bezeichnet :) Weiterhin ist mir noch aufgefallen das die Abfragen auf freien Speicherplatz von Laufwerk C per default prozentual angegeben werden und damit bei heutigen Festplattengrößen eher unsinnig sind - stattdessen kann man diese Abfrage auch auf absolute freie Megabyte-Werte umgestalten: Link.

 

Da der Intel Hardware Monitor bei mir ständig abstürzt (obwohl es die neueste Version ist) habe ich nun auch die erste Ausnahme definiert: criticalexception => '7034' (das ist die EventID).

 

Fazit

 

Mir gefällt Icinga sehr gut und es läuft auch stabil. Mein Ersteindruck von Nagios war dagegen nicht gut, weil ich es partout nicht zum Starten habe bewegen können (wie im ersten Teil erwähnt). Das System ist sehr umfangreich und man kann problemlos ganze Bücher zu dem Thema füllen.

 

Durch die intensive Nutzung von Kontextmenüs konnte eine leicht zu verstehende, stringente Oberfläche realisiert werden. Im Gegensatz zu Nagios ist das Interface auch angenehm anzuschauen. Im Laufe der Zeit werde ich sicher noch einige der verfügbaren PlugIns testen.

 

Ein kleiner Verbesserungspunkt wäre vielleicht das man mit weniger Klicks den Notification-Überblick auf einen einzelnen Host begrenzt auflisten könnte, aber es gibt immerhin den Service Problems-Menüpunkt mit dem die Status-Meldungen (auf Einträge mit Warnungen/Fehlern begrenzt) nach Hosts gruppiert angezeigt werden können.

 

Wenn man im Webbrowser auf aktualisieren klickt landet man wieder im Tactical Overview-Menüpunkt, das ist auch nicht ganz optimal gelöst aber ein absolut vernachlässigbarer Kritikpunkt. Positiv hervorzuheben ist natürlich, das die gesamte Software kostenfrei erhältlich ist. Zu beiden Systemen ist eine gute deutsche Dokumentation verfügbar, wobei diese in einzelnen Punkten noch etwas verbessert werden könnte.

 

Weitere Links:

 

  • Nagios - Das Praxisbuch: Link
  • Nagios V3.x Dokumentation: Link
  • heise-Anleitung zu Nagios: Link
  • Eintrag zu Nagios im Ubuntu-Wiki: Link
  • Wikipedia-Eintrag zu Nagios und NRPE: Link
  • Definition von Zeitperioden: Link
  • Notifications von Icinga: Link
  • Definition von Escalations: Link
  • Bezugsquellen für weitere Nagios/Icinga-PlugIns: 123
  • Download-Quelle für NRPE: Link
  • Tipps zu NRPE: Link
  • NRPE oder NSClient++: Link
  • NSClient++ hat offenbar auch eine eigene CheckEventLog-Funktion: Link
  • auch interessant: das check_oracle_health-Plugin von ConSol: Link

 

Kommentar schreiben




  Country flag
biuquote
  • Kommentar
  • Live Vorschau
Loading


Tag-Wolke

Monats-Liste