Check_MK für Nagios. Einführung und Vorteile

Da ich bereits beschrieben habe, wie man check_mk Plugins schreibt, fehlt natürlich noch, was check_mk eigentlich ist.

Einführung

check_mk ist ein von Mathias Kettner entwickeltes Plugin für Nagios. Ich würde sagen, es ist die beste Erweiterung, die für Nagios entwickelt wurde. Nach meiner Meinung hätte Nagios von Anfang an so funktionieren sollen, wie check_mk es erweitert. check_mk besteht aus seinem eigentlichen Kern sowie dem Event Broker Livestatus und der GUI Multisite.

Livestatus

Jeder kennt die Wege, die es zuvor gab, um an die Daten aus Nagios heranzukommen:

von Haus aus kann man die status.dat auslesen. Eine je nach Installation Riesendatei, die in einem vorgegeben Intervall immer und immerwieder neu auf die HDD geschrieben wird. Nicht wirklich optimal, um damit zu arbeiten. Effizient ist auch was anderes.

Die nächste bekannte Variante sind die NDO Tools, speziell jene, welche in die Datenbank schreiben. Davon abgesehen, dass die Tabellen völlig übernormalisiert sind, ist es doch eine ganz schöne Beschäftigungstherapie für den Server.
Gehen wir von einer Checkrate von 200 Checks/Sekunde aus, wären das Tausende Querys in der Minute, nur um in eine statische Datenbank zu schreiben,was der Stand der Dinge ist. Und die Daten muss man dann auch noch auslesen. So etwas erzeugt Disk I/O. Auch hier effizient ist wieder was anderes.

Livestatus hingegen geht einen anderen Weg. Die gesamten Daten von Nagios sind ja die ganze Zeit schon da. Denn sie liegen direkt im Speicher von Nagios. Sonst könnte Nagios auch nicht arbeiten. Livestatus speichert diese Daten nicht irgendwo zwischen, sonder liest sie direkt aus. Und zwar wirklich live. Realisiert wird dies über ein Event Broker Modul, welches einen Sockel erzeugt. Dieser kann über eine Query Language in Echtzeit abgefragt werden, kann Nagvis  befüttern und über ssh und xinted freigegeben werden. Neben aktuellen Daten kann über Livestatus auch auf Daten aus Nagios Logfiles zugegriffen werden. Commands an Nagios zu senden ist auch kein Problem. Dies ist effizient und der in meinen Augen logische Weg.

Multisite GUI

Gerade so nebenbei wird auch die GUI Multisite mitgeliefert. In diese wurde so alles integriert, was man in der Standard Nagios GUI vermisst. Vor allem anderen ist sie schnell, da sie direkt auf Livestatus aufsetzt. Filtern nach Events, Service Namen, Statuen geht so mit nur einem Klick. Acknowledgements können auf beliebig viele Service und Dienste gleichzeitig gesetzt und entfernt werden, ebenso wie Commands. Ansichten sind frei definierbar. Von den Tabellenspalten, Gruppierungen bishin zu Filtern kann man wirklich alles auf  Wunsch einstellen. PNP Graphen werden automatisch erkannt und angezeigt. Und noch ein Killerfeature: Multisite ist die erste GUI, welches ein verteiltes  Monitoring auf  mehrerer Server unterstützt. Livestatus macht es möglich, beliebige andere Server so zu bedienen, als wäre man direkt auf einer GUI auf dem Server. Ohne Kompromisse.

Die Multisite Sidebar darf auch nicht unerwähnt bleiben. Sie kann von jedem User für sich konfiguriert werden und durch sogenannte Snapins erweitert werden. Von Problem Host Übersichten bis Server Performance anzeigen stehen bereits viele Snapins mit der Grundinstallation bereit. Natürlich kann von Admins konfiguriert werden, welche Snapins für welche User sichtbar sind oder auch nicht.

check_mk

Nun dazu, was check_mk selbst tut: Es nimmt jede Menge Konfigurationsarbeit ab und optimiert gleichzeitig die Server Performance. Aber wie das?

Der Ansatz von check_mk ist eine Automatisierung der Überwachung, bei der so wenig wie möglich konfiguriert werden muss, sich alles erstmal selbst konfiguriert und bei Bedarf manuell optimiert werden kann.

Der Agent

Wer jetzt die checks per SSH oder NRPE kennt, bei denen auf Client und Serverseite konfiguriert werden musste, wird sich gleich ärgern, wie viel Zeit und Nerven er dafür schon verschwendet hat. Der Agent ist ein Shell Script. Es liegt einfach da, wartet bis es mal aufgerufen wird und gibt dann was aus. Im Detail: Das Shellscript des Agent liegt unter /usr/bin/check_mk_agent und ruft einfach nur eine ganze Liste von Shell Kommandos aus. Von Prozesslisten, Mounts, df,  Mailques, Filesystemen, Ethernet Informationen bis hin zu Raid Devices ist alles dabei. Oder eben auch nicht, wenn es etwas auf der Kiste nicht gibt. Erzeugt wird nun einfach eine komplette Textausgabe. Das war es schon. Diese Textausgabe wird vom Nagios Server abgeholt. Und zwar auf einmal. Hatte man damals mit NRPE pro zu überwachenden Service einen Connect auf den Client, gibt es jetzt nur noch eine. Diese holt auch nur die Textausgabe ab, ohne dass aktiv ein Kommando übergeben werden kann. Der Nagios Server kann also keinerlei Befehle an den Client schleusen. Das nächste ist der Weg, wie diese Textausgabe zum Nagios Server kommen soll, spielt keine Rolle.
Von einem Livezugriff via xinetd oder ssh wäre ein cat auf eine von einem cronjob erzeugte Textdatei genauso denkbar wie eine Textdatei, die per FTP, Mail oder sonst wie dem Nagios Server in ein Verzeichnis übermittelt wird. Der Fantasie wird hier keine Grenzen gesetzt. Über alle mögliche Umwege kann also mit dem Agent überwacht werden. Fehlt übrigens was, kann der Agent einfach durch ein Plugin erweitert werden. Wie das geht, beschreib ich sogar schon hier.

Die Inventur

Jetzt wissen wir, dass der Nagios Server jede Menge Text geliefert bekommt. Was macht man damit? Eine Inventur. Und das macht check_mk für uns. Er schaut diese Textdatei in einer Inventur durch und erkennt automatisch alle Dienste, die überwacht werden können. Sinnvolle Standard-Schwellwerte werden bereits voreingestellt. Die komplette Nagios Konfiguration wird automatisch erzeugt und somit lässt sich in nicht mal einer Minute ganz dynamisch ein Client in die Überwachung mitaufnehmen.

Die Konfiguration

Bedenken, dass man die Kontrolle verliert, braucht man dabei aber nicht zu haben. Alles lässt sich bei Bedarf konfigurieren. Als Ansatz gilt: “Mit so wenig Konfiguration wie möglich so viele Fälle wie möglich abzudecken”. Meine Erfahrung zeigt, dass das recht gut funktioniert.

Hosts werden mit Ihrem Namen in eine Liste eingetragen. Besteht Bedarf, hinterlege ich in einer zweiten Liste die IP Adressen. Hinterlege ich keine IP Adressen, wird ein DNS Lookup automatisch mit einem Restart ausgelöst. Also keine Angst vor alten Adressen.

Einem Host kann ich dann wiederum direkt Tags, sogenannte Hosttags, zuordnen. Diese lassen sich dann nutzen, um Konfigurationen zu verteilen. Beispiele: Alle Rechner mit Hosttag Linux kommen in die Hostgruppe Linux. Oder alle Rechner mit Hosttag Apache sollen den Apache Service überwachen. Alle Rechner mit Hosttag Fileserver bekommen andere Schwellwerte für Filesystem checks. Anstelle Hosttags lässt sich natürlich auch immer der Rechnername selbst konfigurieren.

Will ich z.B. Services überwachen, trage ich diese einfach in eine Variable ein. Diese lassen sich dann wieder einem Hosttag zuordnen. Da man beim Service Namen auch mit RegEx arbeiten kann, lassen sich auch mit einer Zeile mehrere Service abfangen.

Clusterüberwachungen sind nun auch kein Problem. Man trägt alle Server des Clusters normal ein. Dann fasst man sie einfach unter einem virtuellen Namen zusammen und zuletzt (RegEx wieder erlaubt) definiert man noch, welche Services Ressourcen des Clusters sind. check_mk kümmert sich nun um den Rest. Die Cluster Ressourcen werden unter dem virtuellen Namen zusammengefasst und check_mk schaut, dass sie auf einem der Servers des Clusters zur Verfügung stehen.

Die Arbeit damit

Wie arbeite ich nun damit: Auf einem Client installiere ich nur den Agent. Auf dem Nagios Server trage ich den Clientnamen in die Konfiguration ein (eine Zeile) und führe auf der Shell die Inventur mit

durch. Alle Services werden erkannt. Mit einem

kann ich mir jetzt schon gleich auf der Shell anschauen, ob alles funktioniert (es werden alle Services und deren Ausgabe dargestellt). An Nagios wurde bis jetzt noch nichts gemacht. Jetzt folgt ein

dadurch werden automatisch die Nagios Konfigurationsfiles erstellt und Nagios neugestartet. Der Server befindet sich nun in der Überwachung.

Abschluss

Dieser Blog-Eintrag liefert erst mal einen nichttechnischen Überblick darüber, was check_mk ist. Alle Features und Funktionen decke ich hier jedoch weitaus nicht ab. Check_mk wird ständig verbessert und um sinnvolle Funktionen erweitert. Alle aktuellen Infos gibts auf check-mk.org.

 

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*