Check Paramter in check_mk setzen und überschreiben.

Update: Diese Anleitungen gilt für ältere Versionen von Check_MK. Die Konfiguration kann in den neuen Versionen bequem in Wato, dem Webadministrationstool durchgeführt werden.

Auf den ersten Blick könnte es eventuell etwas kompliziert wirken für Checks in check_mk neue Parameter zu setzen. In der Praxis jedoch erweist es sich als überaus einfach und vorallem praktisch.

Anders als im klassischen Ansatz ist es erst einmal nicht nötig, in check_mk irgendwelche Parameter zu setzen, da das meiste bereits durch Standartparameter abgedeckt wird. Will ich diese jedoch ändern, habe ich wie immer die Möglichkeit, dies jeweils für Hosts oder Hosttags durchzuführen. Zu diesem Zweck steht die Variable check_parameters zur Verfügung. Vom Datentyp ist dies eine Liste, welche für jeden Eintrag aus einem Tupel mit je nachdem 3 oder 4 Werten besteht:

Wie im Beispiel zu sehen besteht der erste Wert wieder aus einem Tupel. In diesem stehen nun genau unsere Parameter. Diese sind im Beispiel genau 2 Werte. Das aber ist je nach Check unterschiedlich, dafür in der jeweiligen Dokumentation zum Check beschrieben.

Die Dokumentation zu Checks kann man sich auf der Konsole durch ein:

ganz einfach anzeigen lassen.

Nun zum zweiten Wert. Dieser ist eine Liste, die aus den Rechnernamen oder eben aus Hostags besteht. Nun ist es wieder so, dass, wenn es sich um eine Liste von Hosttags handelt, das als weiterer Parameter ALL_HOSTS
gesetzt werden muss.

Nun bleibt auch nur noch ein Parameter übrig. Mit diesem beschreibe ich dann für welche Services ich den überhaupt die neuen Werte setzen möchte. Der Parameter ist nun wieder eine Liste in der ich alle Service Descriptions einfach aufführe. Hier muss ich übrigens auch wieder nicht den ganzen Namen ausschreiben. Nach hinten wird automatisch aufgefüllt. So wirkt ein fs_ auf alle Services, die mit fs_ anfangen. Ausnahmen wie im Beispiel fs_C: müssen dann in der Reihenfolge einfach zuerst kommen.

Das war auch schon alles, nur den Restart nicht vergessen :)

Checks zuweisen die keine Inventur besitzen am Beispiel einer Prozessüberwachung

Update: Diese Anleitungen gilt für ältere Versionen von Check_MK. Die Konfiguration kann in den neuen Versionen bequem in Wato, dem Webadministrationstool durchgeführt werden.

Am Beispiel einer Prozessüberwachung erkläre ich in diesem Artikel, wie checks in der main.mk eingetragen werden können, welche nicht automatisch inventarisiert werden.

Einen Prozess mit check_mk zu überwachen, fordert mit check_mk keine weitere Konfiguration auf dem Zielrechner. Eine komplette Liste der laufenden Prozesse werden dem Nagios Server bereits durch den Agent geliefert.

Es muss also nur noch angegeben werden, welche Prozesse man überwachen will. Diese Konfiguration kann wie bereits in meinem Artikel Einstieg in den Benutzung von check_mk dann jeweils einem oder mehreren Hosts zugeordnet werden oder eben einem Hosttag. Um das Beispiel des anderen Artikels aufzugreifen, möchte ich nun auf srvweb1 den Dienst Apache überwachen. In der Konfiguration des Beispiels habe ich bereits einen Hosttag mit dem Namen apache eingetragen, um ggf. auch auf anderen Servern diesen Dienst durch einfaches zufügen des Hosttags überwachen zu können.

Das passiert hier: Ich erweitere die Liste checks um einen check,dazu muss ich ein sogenanntes Tuple eintragen. Pro Zeile kann ich für jeden Check jeweils ein Tuple eintragen. Innerhalb des Tuple erfolgt mit den ersten beiden Wertungen die Zuweisung an den Host. Im Beispiel sind dies Alle Hosts mit dem Tag apache. Will ich etwas direkt an einen Hostnamen zuordnen, schreibe ich den Hostnamen anstelle des Tags. , ALL_HOSTS fällt dabei weg. Mehrere Hosts oder Tags werden übrigens so zugeordnet: [“eintrag1”,”eintrag2].

Jetzt folgt die Angabe des checks, den ich benutzen will: Im Beispiel ps. Will ich übrigens die Prozesse auch Performance Graphen überwachen, hilft uns der check ps.perf.

Als vorletztes nun die Service Description für Nagios. Dies ist der Name, mit welchem der Service später in Nagios angezeigt wird.

Zuletzt ein Tuple mit den check-Parametern. Bis auf den Inhalt dieser inneren Tuple ist die Syntax zur Zuweisungen anderer checks immer gleich.

Bei den ps checks besteht dieser Tuple nun aus 5 oder 6 Werten. Der erste Wert ist hier nun der Name des Prozesses, wie er in der ps Liste des Systems auftaucht. Das Tolle hierbei ist, dass reguläre Ausdrücke möglich sind .

Im Beispiel wird jeder Prozess überwacht, welcher im Namen apache2 enthält. Möchte ich nicht auf den Prozessnamen gehen, sondern auf den Besitzer des Prozesses, muss ich anstelle “~.*apache2” ein None schreiben, dann ein Komma und den Benutzernamen in Anführungszeichen. Die folgenden 4 Ziffern sind die jetzt die Schwellwerte entsprechend der Zahl der laufenden Prozesse. Warnmin, OKmin, OKmax, Warnmax.

Im Beispiel bedeutet das nun: zwischen 5 und 50 erscheint Warning, zwischen 50 und 80 ist alles OK, zwischen 80 und 85 wieder Warning und alles kleiner 5 und größer 85 ist Critical.

Will ich das z.B. ein Prozess nur einmal läuft, wäre es 1,1,1,1.

Jetzt nur noch eine Inventur des Systems, und unser Prozess taucht in der Überwachung auf.

Mehrere ähnliche Prozesse automatisch generieren

Zum Abschluss noch ein kleines “Schmankerl”, wie uns check_mk auch hier wieder Arbeit abnehmen kann.

In manchen Fällen hat man mehrere Dienste, die man überwachen will, z.B. jeder Dienst mit dem Pfad /usr/bin/notes/. Jetzt muss ich nicht für jeden Prozess einen eigenen Eintrag schreiben, sondern kann dies automatisch machen lassen:

Wie im Beispiel zu sehen, erweitere ich die Service Description nur um ein %s. Wir erinnern uns, dass in der Konfiguration des Prozessnamens reguläre Ausdrücke erlaubt sind. Klammere ich nun hier was ein, wird %s automatisch durch den geklammerten Teil ersetzt. Hier klammere ich (.*) ein, das bedeutet eine beliebige Anzahl von Zeichen, eben alles was nach /usr/bin/notes/ kommt.

Also, viel Spass damit :)

Einbidung alter NRPE Checks in den check_mk_agent

Wie versprochen behandle ich nun das Thema NRPE checks in check_mk einbinden. Nicht selten liegen bei der Migration zu check_mk noch alte NRPE checks vor, die man natürlich gerne mit den check_mk-Vorteilen verheiraten will.

Dies ist nicht weiter schwer, denn dafür wurde MRPE geschaffen.

Wie funktioniert MRPE?

MRPE ermöglicht den lokalen Aufruf von Nagios checks direkt durch den Agent. Der Agent sorgt automatisch für die passende Umwandlung deren Ausgabe und hängt diese an seine Ausgabe an. Das praktische: der Agent unterstützt dieses bereits von Haus aus.

Wie konfiguriere ich MRPE

Konfiguriert wird es auf dem zu überwachenden Rechner unter /etc/check_mk/ in der mrpe.cfg. In dieser werden nun zeilenweise die Checks eingetragen. Die Form besteht dabei aus einem Servicenamen (ohne Leerzeichen, im Beispiel SERVICE_DESC1 +2), dem kompletten Pfad sowie allen Parametern des NRPE Plugins:

Führt man nun auf dem Nagios Server eine Inventur beim entsprechenden Zielhost durch, werden die MRPE checks automatisch erkannt.

Einstieg in die Benutzung von check_mk

Update: Diese Anleitungen gilt für ältere Versionen von Check_MK. Die Konfiguration kann in den neuen Versionen bequem in Wato, dem Webadministrationstool durchgeführt werden.

Nachdem ich in meinem letzten Artikel die Funktionen von check_mk beschrieben habe, möchte ich heute mehr ins Detail gehen, wie ich check_mk konkret konfiguriere.

Beispiel

Ich beschreibe es anhand eines fiktiven Beispiels dreier Rechner, die überwacht werden sollen. Rechner 1, srvfile1: Linux Fileserver. Normal erreichbar. Rechner 2, srvweb1: Ein Linux Web Server mit Apache und einem nrpe Check, der weiter benutzt werden soll. Rechner 3, srvdmz1: Ein Server in einer DMZ, der nur per SSH zu erreichen ist.

check_mk sollte bereits konfiguriert sein. Am einfachsten arbeiten wir wieder mit OMD, da ist schon alles dabei. Da die Pfade je nach Installation woanders sein können, bitte beachten, dass ich die Pfadangabe entsprechend OMD beschreibe. Lässt sich aber leicht ableiten.

Los gehts:

Pfade

OMD Nutzer wechseln als root durch su – sitename in ihre OMD site. In den Beispielen heisst meine site monitor. Alle Konfigurationen zu check_mk befinden sich unter ~/etc/check_mk .

main.mk

Für uns ist die main.mk interessant. Sie ist die Hauptkonfigurationsdatei. Es ist natürlich möglich, die Konfiguration auf mehrere Dateien aufzuteilen. Diese können mit der Endung .mk in den Ordner conf.d abgelegt werden. Beim Aufteilen auf mehrere Dateien muss nur beachtet werden, dass man die Konfigurationen in Python, also einer Programmiersprache schreibt. D.h. in Variablen, an die mehrfach etwas angehängt wird, also in der Regel mit +=. Ich erklär es gleich im Beispiel.

In der main.mk nehmen wir als ersten Schritt die drei Rechner auf, welche wir überwachen wollen:

Sie werden einfach in eine Liste mit dem Namen all_hosts gehängt. Teile ich die Konfiguration nun auf mehrere Datien auf, darf  ich in denen natürlich nicht wieder all_hosts = schreiben, sondern muss += verwenden.

Wichtig ist auch die korrekte Syntax beim schreiben. Die Klammern müssen wie ich es im Beispiel zeige gesetzt werden. Die erste nach dem =, die letze in eine neue Zeile. Dies liegt an Python, denn für Python ist normal newline das Zeilenende, außer ein Element ist eben noch offen. Dann ist das Zeilenende da, wenn das Element wieder geschlossen wird.

In unserem Beispiel gehen wir nun davon aus, das srvfile1 und srvweb1 im DNS aufgelöst werden. Hier muss ich also nichts weiter tun.

Extra IP Addressen

Anders sieht es aber nun mit dem srvdmz1 aus. Dieser steht nicht im DNS. Für diesen müssen wir die IP Adresse manuell zuweisen. Die funktioniert über ein Python Dict:

Wichtig wieder die Syntax und noch etwas: wenn man IP Adress-Zuweisung in mehreren Dateien durchführen will, geht dies nicht über +=. Man muss es mit

zusammenhängen.

Andere Datenquellen

Jetzt erinnern wir uns aber auch noch, das srvdmz1 nur über SSH zu erreichen war. Dazu müssen wir dem Rechner eine neue Datasource zuweisen.

In der main.mk schreiben wir dazu:

Wir konfigurieren damit, dass srvsdmz1 über ssh als root und einem bestimmten keyfile kontaktiert wird. Platzhalter hier ist

Konfigurationen an Hostags und mehrere Rechner zuweisen

Die Rechner-Liste kann auch mehrere Rechner enthalten:

oder gar einen (oder mehrere) Hosttags enthalten:

Den Hosttag ordne ich einach mit einem | dem Rechner zu:

Hosttags können für alle Konfigurationen verwendet werden. Erkannt werden sie durch das Schlüsselwort ALL_HOSTS. Würde das hier fehlen, würde dmz als Rechnername gesucht und nicht als Hosttag Name.

Für unser Beispiel habe ich dem srvweb1 auch gleich apache zugeordnet. Das bentzten wir später. Das Tag lnx habe ich nur zugeordnet, um zu zeigen, dass man auch mehrere Tags zuordnen kann.

Agents einrichten

Jetzt machen wir aber erst mal den dmz Rechner zu Ende: damit wir ihn kontakten können muss mit ssh-keygen ein Schlüsselpaar erzeugt werden. Dafür schreibe ich aber auch noch einen eigenen Beitrag. Ich setzte nun mal das ssh-Wissen vorraus.

Auf srvdmz1 muss nun einfach in /root/.ssh/authorized_keys der passende public_key zum privatekeyfile aus unsere Datesource liegen. Da wir natürlich nicht wollen, dass man sich vom Nagios Server einfach als root auf srvdmz1 verbindet, hinterlegen wir in authorized_keys für Keyfile noch einen command. command=”/usr/bin/check_mk_agent”. Dann wird bei einer Verbindung mit dem Key immer nur der Agent ausgeführt. Ein interaktiver Login mit dem Key findet nicht statt. Der Agent muss natürlich noch nach /usr/bin kopiert werden.

Auf srvfile1 und srvweb2 haben wir es etwas einfacher. Auf diesen beiden Server können wir einfach das normale Agent Paket installieren. Dieses legt automatisch einen Eintrag in xinted an, welches den Agent über TCP Post 6556 erreichbar macht.

Damit wäre die Grundkonfiguration und die Agent-Installation geschafft.

Inventur

Nun können wir auch schon eine Iventur machen:

Ohne jedes weitere Parameter wird jetzt eine Iventur über alle Rechner durchgeführt, welche in der Konfiguration eingetragen wurden. Es wird ermittelt, was für jeden Rechner überwacht werden könnte.

Natürlich lässt sich auch eine mit Leerzeichen getrennte Liste angeben, wenn ich nur bestimmte Rechner inventurisieren will. Beispielhaft sieht das nun so aus:

Dabei werden aber immer nur checks angezeigt, welche noch nicht bei einer früheren Iventur entdeckt wurden. Das funktioniert, da jede Inventur im Order ~/var/check_mk/autochecks abgelegt wird.

Das ist wichtig zu wissen, denn überwache ich z.B. ein Filesystem, welches später entfernt wird oder durch einen Fehler nicht mehr gefunden wird, merkt sich dies check_mk, um es melden zu können. Will ich bewusst dafür sorgen, dass es nicht mehr dazu gehört, muss es aus autochecks gelöscht werden. Dies geht mit check_mk -II rechnername. Zweimal II sorgt dafür, dass die autochecks zu den angegeben Rechnern vor der Iventur gelöscht werden.

Will ich übrigens nur einzelne Dienste inventurisieren, hilft der Parameter –checks checkname.

Alles im Nagios

Ist die Inventur geschafft, können wir uns das Ergebnis auch schon gleich mal in Nagios anschauen. Dazu muss aber check_mk die Nagios-Konfiguration erstellen und Nagios neu gestartet werden.

Dies kann nun mit einem Rutsch passieren, in dem man check_mk -R macht oder man kann Nagios nach einem check_mk -U auch selbst neu starten.

Abschluss

Wenn wir jetzt ins Nagios schauen, werden wir sehen, dass unser srvfile1 bereits fertig ist. Alle Dateisysteme, seine SAN Paths und seine lokalen Raids wurden erkannt. Festplattenbelegung wird alles bereits automatisch überwacht.

srvdmz1 ist mittlerweile auch perfekt.

Bei srvweb1 schaut es zwar auch schon sehr gut aus, jedoch fehlt noch die Überwachung unseres Webservers und unser alter NRPE-Check. Dies werde ich in weiteren Artikeln beschreiben. Den Dienst des Apachen werden wir über die Prozessüberwachung überwachen.  Seine Erreichbarkeit überwachen wir über einen klassischen check_http, welchen wir mit Legacy Checks einbinden. Seinen alten NRPE check werden wir einfach in die MRPE Konfiguration des check_mk Agents übernehmen.

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.

 

Verteiltes Nagios Monitoring mit Livestatus und Multisite

Update: Diese Anleitungen gilt für ältere Versionen von Check_MK. Die Konfiguration kann in den neuen Versionen bequem in Wato, dem Webadministrationstool durchgeführt werden.

Thema heute ist das Einrichten eines Verteilten Nagios Monitorings. In der Vergangenheit war dies immer mit viel Konfiguration und ein paar Einschränkungen verbunden. Durch das in check_mk enthaltene Livestatus wird dies zusammen mit der check_mk Multisite GUI aber fast zum Kinderspiel.

Zur Begriffsklärung: wenn ich ab hier von Monitoring Site spreche, meine ich damit jeweils die Rechner mit Nagios Instanz die überwachen, bzw die OMD Sites, welche überwachen. Wenn ich von Viewing Site spreche, meine ich damit den Rechner oder die Site mit der Multisite GUI, welche alles anzeigen sollen.

Ich erkläre hier die Einrichtung mit und ohne OMD. Ich persönlich bevorzuge OMD.

Zuerst die Vorbereitung der Monitoring Sites:

Bei der Verwendung von OMD:
mit omd config bei jeder Instanz bei Distributed Monitoring den Livestatus TCP Socket aktivieren. Liegen mehrere Sites auf der gleichen Maschine, muss für jeden Socket einen eigener Port festgelegt werden. Unter ~/etc/apache/conf.d sollte für jede Site die auth.conf angepasst werden. Und zwar muss der Wert AuthName auf jeder Monitoring Site gleich gesetzt sein. Soweit die Vorbereitung OMD.

Vorbereitungen nur mit Nagios:
Hier ist etwas mehr zu tun. Dabei setze ich hier noch voraus, dass check_mk mit Livestatus installiert wurde. Nutzt man pnp4nagios, muss in dessen Apache Konfiguration bei Alias jeweils ein Prefix hinzugefügt werden. Der Prefix muss für jede Site unterschiedlich sein.

Als Beispiel:

Bei allen Monitoring Sites darauf achten, dass der AuthName auch auf ein und denselben Wert eingestellt wurde.

Der nächste Schritt ist es, den Livestatus Socket durch xinetd auf einen TCP-Port zu legen, damit die Viewing Site später darauf zugreifen kann. In das Verzeichnis /etc/xinetd.d muss eine Datei mit folgendem Inhalt abgelegt werden:

Der Name der Datei spielt keine Rolle. Wichtig hier sind nur die server_args, welche auf den Livestatus Socket zeigen müssen (wie beim check_mk Setup festgelegt) und user, welchem man einen lokalen User angibt, der auf dem Socket Zugriff hat (idr. den Nagios User). Mit only_from lässt sich der Zugriff noch auf eine mit Leerzeichen getrennte Liste von IPs einschränken.

Zum Abschluss nicht vergessen, Apache und xinetd neu zu starten.

Einrichten der Viewing Site

Dies läuft nun mit und ohne OMD fast gleich. Auch hier setze ich voraus, das die Multisite GUi bereits aufgesetzt ist. Auch in der Apache Config zu der GUI sollte der gleiche AuthName wie bei den Monitoring sites gesetzt werden.
Bei einer normalen Installation liegt die Config dafür unter /etc/apache/conf.d/zzz_check_mk.conf, bei OMD wie bereits beschrieben in der entsprechenden auth.conf Datei.

In der multisite.mk setze ich nun noch meine Monitoring Site. Gehen wir hier mal von zwei Sites aus:

Um die Werte mal kurz zu erklären:  Socket sollte klar sei, Adresse des Servers und Port wie in xinted festgelegt bzw. wie mit omd config eingestellt. url_prefix ist nun wichtig. Hier kommt bei OMD jeweils der Sitename der Monitoring Site rein, bei einer normalen Installation der besagte Prefix, welchen wir bei der Voreinrichtung gesetzt haben. Wie gesagt, der Prefix muss immer unterschiedlich sein. Sommit dürfen auch die Monitoring Sites im OMD nicht gleich benannt sein.

Und nun kommt der Trick, damit wir Daten (pnp Graphen) in der Viewing Site sehen können, obwohl sie auf der Monitoring Site liegen. Wir sagen dem Apachen auf der Viewing Site: bekommst du eine Anfrage auf den Pfad http://viewingsite/path2, leite das im Hintergrund auf http://monitoringsite/path2 um. Spätestens jetzt ist verständlich, warum wir zuvor auf den Monitoring Sites, den Alias um einen Prefix erweitert haben (path2 im Beispiel).

Und wie funktioniert das nun? Mit folgenden zusätzlichen Einträgen in der Apache Config (z.B. als multisite.conf in /etc/apache2/conf.d)

Apache restart nicht vergessen.

Die Multisite GUI auf der Viewing Site sollte nun alle Nagios-Objekte der Monitoring Sites sehen. Vor allem pnp Graphen sollten ohne Error 404 angezeigt werden. Auch darf dabei nicht wieder ein Passwort abgefragt werden (die htpasswd Dateien müssten natürlich synchron sein).

Ist die Doku unklar oder lässt Fragen, einfach melden.

Grafiken mit TypoScript zusammenbauen und in Marker legen

Wer schon mal versucht hat, eine Homepage zu bauen, welche z.B. unterschiedliche Header-Grafiken, aber immer das Logo an derselben Stelle und dazu noch einen beliebigen Text an einer anderen haben sollte, kennt das Problem. Man braucht ein Bildbearbeitungsprogramm, ein Script oder sonst etwas, um diese Grafik immer sauber zusammenzubauen.

Einfacher ginge es natürlich, wenn uns das das Typo3 abnähme. Und das ist leichter als man denkt. In meinem Beispiel arbeite ich mit dem Marker GRAFIK Das Besondere daran, durch ein Extension Template kann ich diesen für Zweige der Homepage wieder überschreiben. Unterschiedliche Hintergrundbilder sind so nämlich auch kein Problem:

Beginnen wir damit, den Marker als Bild anzulegen:

Gleich zum Anfang legen wir seine Größe fest: Breite, Höhe. Jetzt beginnen wir ihn schichtweise zu belegen (10,20,30..)

Erste Schicht: das Hintergrundbild:

Etwas länger ist die Textschicht. Als Text wird das Element subtitle von der Page mit der ID 79 gezogen, es folgt die Ausrichtung, der Pfad zum Fonts File, die Schriftgröße, Farbe, niceText für schönere Darstellung und dann das Wichtige,
der offset, welcher die Position angibt.

Jetzt können wir z.B. auch ein Logo an immer gleicher Stelle einbauen:

Hier noch mal das Ganze am Stück:

Check Plugin Entwicklung für check_mk Teil 3

UPDATE:  02.02.2014 – Anpassung an aktuellen Stand der Dinge.

In Teil 1 haben wir nun das Agent Plugin gebaut, in Teil 2 die Inventur geschrieben. Jetzt fehlt nur noch der Rest: die check Funktion.

Die check Funktion wird von check_mk nun für jedes Item einmal aufgerufen, übergeben wird eben dieses Item, Parameter und wieder die Agent Ausgabe als info. Hat man mal keine Parameter, kennzeichnet man dies mit _no_params als Variablenname.

Das Item ist nun jetzt hier jeweils den Variablenname der MySQL Status Variable, in params, dann jeweils unser Tuple  mit den warn oder crit schwellen die für dieses Item gelten. D.h. wurde über check_parameters oder Wato nichts gegenteiliges festgelegt, sind es die Default levels.

Jetzt erst mal wieder das selbe Spiel wie in der Inventur Funktion. In Info wird erst zeilenweise nach unserem Item gesucht. Wird es gefunden, legen wir der Lesbarkeit halber den aktuellen Status aus line[1] nach current_stat.

Nun haben wir auch alle Daten um die Tuple perf der Performancedaten vorzubereiten.

Es reicht uns eine Variable, somit auch nur eine Tuple in perf. Das Liste besteht aus

  • Einem Variablen Name
  • Dem Aktuellen Wert
  • Dem Warning level des checks
  • Dem Critical level
  • Dem Maximal möglichen Wert
  • Dem Minimal möglichen Wert

Alle nicht benötigen Werte werden durch ” ” übersprungen, oder können gleich (wenn man ende) weggelassen werden. Nur der Variablenname und der aktuelle Wert sind Pflicht. Einen Teil der Ausgabe können wir nun auch schon vorbereiten und in output speichern. Die Schwellwerte schreiben wir in einen levels String, damit wir diese nur im Fehlerfall als Information für den Benutzer zurückgeben müssen.

Jetzt kommt das eigentliche Prüfen. Wie ihr seht werden jeweils nur der Statuscode, unser Ausgabe Text sowie die Performance Daten zurückgegeben. Der Status als Zahl orientiert sich hier an Nagios, 0 = OK, 1 = Warning, 2 = Critical, 3 = Unknown.

Wichtig ist auch der Return 3, der kommt nämlich immer dann, wenn das Item in der Agent Ausgabe nicht mehr gefunden wird. Dann stimmt was nicht.

So, das war auch schon die check Funktion.

Aber Achtung: damit allein passiert noch nichts, der Check muss nun noch registriert werden.  In den aktuellen Check_MK Versionen passiert dieses über in Dictionary in check_info:

Interessant ist hier das %s in der service_description, dieses wird von Check_MK automatisch mit dem Namen des Items versehen.

Demnächst nun noch der Teil 4: Wie kann ich Schwellwerte über Wato festelgen.

 

Check Plugin Entwicklung für check_mk Teil 2

UPDATE:  02.02.2014 – Anpassung an aktuellen Stand der Dinge.

So, ausgehend von Teil 1 gehts nun weiter mit der Entwicklung eines check_mk Plugins, am Beispiel eines MySQL check.

Wenn in Teil 1 nun alles geklappt hat, liefert uns der Agent des Servers nun die Sektion mysql_status mit aus. Dies lässt sich einfach mit cmk -d Hostname prüfen. Die Ausgabe sollte nun einen Abschnitt ähnlich diesem:

enthalten. Ist das der Fall, sind wir nun fertig für Schritt zwei. Pfadangaben die nun folgen, gehen von einer  Installation mit OMD aus. Solltest du OMD (Open Monitoring Distribution) noch nicht kennen, schau sie dir unbedingt mal an. Einen einfachen Weg, ein perfekt konfiguriertes Nagios/ Icinga inklusive verschiedener Plugins und Guis aufzusetzen, gibt es nicht. Also los: Wir legen nun unter ~/local/share/check_mk/checks/ das eigentliche check Skript mit dem Namen mysql_status an. Hier ist nun Python nötig.

Ein normaler Agent basierender Check besteht primär aus zwei Funktionen. Zum einen aus einer Inventory Funktion zum anderen aus der Check Funktion. Beginnen wir mit der Inventory Funktion:

Der Name der Funktion sollte immer inventory_check_name entsprechen. Übergeben wird ein Wert: Die sogenannte info . Diese enthält eine Liste bestehen aller Zeilen unserer Agenten Sektion. Praktischerweise sind die Zeilen auch gleich an den Leerzeichen/ Tabs gesplittet. An diesem Beispiel seht ihr was ich meine:

Und damit können wir jetzt arbeiten. Gerade bei der Ausgabe des SHOW STATUS; querys gibt es nun ziemlich viele Werte die uns gar nicht interessieren. Und jeder hat natürlich andere Interessen. Somit sollte es für jeden konfigurierbar sein, welche Werte er überwachen will. Hier kommt nun die Variable mysq_status_inventory ins Spiel. Diese ist am  Anfang des Checkes einmal leer definiert:

Sollen nun bestimmte Variablen Inventurisiert werden, passen wir aber nicht die Liste im Check an, sondern überschreiben diese in der main.mk (Eine Beschreibung für WATO folgt)

Weiter nun in der Inventory Funktion. Nach der Definition legen wir uns zuerst eine leere Liste als Hilfsvariable an. Wir nennen sie inv,  da wir in ihr später alle Übereinstimmungen ablegen.

Wir beginnen nun jeden Wert, der uns vom Agent geliefert wird, zu durchlaufen.

Und für jeden Wert müssen wir natürlich auch schon gleich nachsehen, ob eine Inventur gewünscht wird.  Wenn ja:

In line[0] steht nun der Name der SQL Variable, so wie wir ihn auch in unserer mysq_status_inventory liste vermerkt haben und als Schwellwerte werden die Default Levels übergeben.

Die Default Level Variable ist auch im Kopf des Checks festgelegt. Aber auch diese ändern wir nicht mehr im Check, sondern Überschreiben sie in der main.mk.
Durch iventory.append((item,(params)) können wir nun Item und Parameter in check_mk Form zusammenstellen. Aber erst mal landet es natürlich in der Liste inv. Ist die for Schleife durch info durch, geben wir nun unsere Liste im inv endgültig zurück an check_mk.

bei einem check_mk -I Rechnername werden nun alle unsere Werte gefunden und in die Autochecks aufgenommen. Was bedeutet, jetzt sind sie im Monitoring. Nun können wir zur check Funktion weiter. Aber das dann erst in Teil 3.

Check Plugin Entwicklung für check_mk Teil 1

UPDATE:  02.02.2014 – Anpassung an aktuellen Stand der Dinge.

Heute der erste Teil zur Step by Step Check Plugin Entwicklung für check_mk.

Der Ablauf in Kürze: der check_mk Agent wird um eine Sektion erweitert,  Check_MK  um ein Plugin, welches diese auswertet. In diesem Artikel geht es um die Erweiterung des Agents durch eine Sektion.

Eine Sektion im Agent ist nichts weiter als ein Textabschnitt, welcher mit <<<NAME>>> eingeleitet wird und bis zur nächsten Sektion führt. Erreichen lässt sich das am einfachsten durch ein Shell Script, welches in den Plugin Order des check_mk_agents abgelegt wird. Normalerweise befindet sich dieser unter /usr/lib/check_mk_agents/plugins. Er kann aber auch relativ einfach ermittelt werden. Er ist als PluginsDirectory direkt in der Agents Ausgabe hinterlegt:
Einfach mal check_mk_agent | head eingeben:

Der Name der Datei spielt keine Rolle. Wichtig ist nur, das sie ausführbar ist. Als Beispiel bauen wir nun einen Check, der den Status eines MySQL Servers überprüft.

Hier eigentlich Plugin, welches ich mysql nenne.
Inhalt:

Das ist schon alles:

<<<mysql>>> leitet nun die Sektion ein und direkt darauf folgt der mysql Befehl. Ich übergebe ihm das root Passwort (es kann natürlich auch ein Extrauser ohne Passwort angelegt werden). Der Passwort Problematik und deren Lösung beschreibe ich noch in einem eigenen Artikel. Mit dem IF wird schlicht nur gepüft, ob der MySQL befehlt verfügbar ist. Wenn nicht, bleibt die Ausgabe leer.

Jetzt nicht vergessen mit chmod +x mysql datei ausführbar zu machen.

Ein check_mk -d vom Nagios Server aus, solltet nun schon die neue Sektionen mit der Ausgabe des MySQL Statusbefehls enthalten.

Wie ich nun das Gegenstück zum Plugin auf dem Monitor Server entwickle
folgt in Teil 2.