Archiv der Kategorie: Nagios

Check_MK vs Icinga?

Gestern auf dem Münchner Linux Stammtisch stand als Thema Monitoring auf dem Programm. Scheinbar so gut besucht wie nie, lauschten 62 Teilnehmer den Dozenten Mathias Kettner (mein Chef), der für Check_MK sprach, und Bernd Erk (von Netways), welcher Icinga 2 vorstellte.

Wie zu erwarten war, gab es natürlich eine Diskussion, welches Konzept das bessere ist. Einer der Diskussionspunkte war: “Ein Automatisches Discovery oder eine Manuelle bzw. CMDB gestützte Konfiguration?”

Klar, darüber kann man streiten. Discovery wurde als Argument für Check_MK gesehen, Manuelles Konfigurieren als Argument für Icinga. Was wohl aber gerne verdrängt wird: selbst der Manuelle Ansatz lässt sich mit Check_MK einfacher einrichten als mit Icinga. Statt mit dem Discovery zu arbeiten, kann man alle Checks auch manuell zuweisen. Ob man dies nun in Wato macht, in den Konfigurationsdateien, oder diese von einem externen Tool generieren lässt, kann man selbst entscheiden.

Link zu den Manual Checks
Link zu den Manual Checks in Wato

Einmal angeklickt, präsentieren sich die verschiedenen Check Typen:

Liste der Manual Checks in Wato
Unvollständige Liste der Manual Checks in Wato

Was ist nun aber der Vorteil, wenn man den manuellen Ansatz per Check_MK konfigurieren möchte? Die Regelbasierte Konfiguration:

Maske zum manuellen anlegen eines Checks
Maske zum manuellen Anlegen eines Checks

Statt einen Check “Explicit” einem Host zuweisen zu müssen, kann man alternativ dazu die frei definierbaren “Host Tags” verwenden, oder auch einen Regulären Ausdruck (bei Verwendung einer Tilde am Anfang des Hostnamens wird der folgende String als regulärer Ausdruck behandelt).

Das Ganze findet sich dann wie folgt in den Konfigurationsfiles wieder:

Da es sich hier um Python handelt, ist es ein Leichtes, dies extern generieren zu lassen. Die Verwendung von Schleifen ist dadurch hier auch möglich.

Meine Meinung ist: Der Wunsch einer Manuellen Konfiguration ist weder ein Argument gegen Check_MK noch eines für Icinga.

Und jetzt nicht böse sein Bernd, du hast gestern gesagt: Die durchschnittliche Icinga Umgebung sind 10-20 Hosts. Bei Check_MK liegt sie (meine Erfahrung beim Consulting) etwas höher: zwischen 500 und 1000. Warum das so ist, konnte sich gestern sicher jeder denken :-)

Parents mit check_mk Verwalten

In check_mk existieren zwei Möglichkeiten, Host Parents zu verwalten. Zum einen das manuelle Definieren (wobei man hier wieder mit Host Tags arbeiten kann), zum anderen das automatische Erkennen mittels einer Scan-Funktion.

Manuell Definieren

Nach dem typischen check_mk Muster wird in der Variable parents die Zuweisung vorgenommen.
Im Beispiel wird host1 sowie host2 dem switch1 zugewiesen, in der nächsten Zeile erfolgt dann wieder eine ähnliche Zuweisung, nur das hier gleich einer ganzen Gruppe in Form eines Hosttags zugewiesen wird.

Mehrere Parents zuweisen

Um nun einer Maschine mehrere Parents zuzuweisen, gibt es zwei Möglichkeiten: zum einen kann ich die Konfiguration einfach wiederholen:

oder gleich beide Parents mit einem Komma getrennt auf einmal schreiben:

Nach Hosts Scannen

Komfortabler ist der automatische Scan nach Parents.
Dieser setzt voraus, dass traceroute installiert ist und der Nagios Server in der main.mk als monitoring_host eingetragen ist.

Nun muss nur noch check_mk mit dem parameter –scan-parents aufrufen.
Automatisch wird nun die Datei parents.mk ins check_mk conf.d Verzeichnis abgelegt, welche die Parents Beziehungen enthält. Nach einem Neustart mit check_mk -R stehen die Parents dann zur Verfügung.

Scan-Funktion nur für bestimmte Hosts nutzen

Sollte es nicht gewünscht sein, dass alle Hosts generell nach Parents gescannt werden, besteht die Möglichkeit, explizit festzulegen, welche Hosts gescannt werden dürfen:

In diesem Beispiel werden jetzt nur noch die Hosts mit dem Tag lnx, sowie der host srv1 gescannt.

Der Weg über ein Ausschlussverfahren ist natürlich auch möglich. Hierzu dient das Schlüsselwort NEGATE.

Hier wird jetzt jede Host gescannt, solange er nicht den Tag lnx hat, bzw nicht srv1 ist.

Wieder alles rückgängig machen

Sollten mir die Ergebnisse des Scans nicht passen, reicht einfach die Löschung der parents.mk und der Neustart mittels check_mk -R.

Die Arbeit mit Host Tags in check_mk

Update: Dieser Artikel beschreibt das vorgehen in der main.mk und gilt nicht für Wato.

Host Tags in check_mk sind eine einfache Möglichkeit, Konfigurationsparameter einem oder eine ganze Gruppe von Hosts zuzuordnen.

Ein Host Tag entsteht automatisch durch seine erste Zuordnung zu einem Host. Dabei bei wird dieser einfach durch eine Pipe getrennt und hinter den Hostnamen geschrieben:

Dabei können beliebig viele Host Tags verwenden werden.

In ziemlich jedem check_mk Parameter können diese Host Tags nun verwendet werden. So werden diese einfach anstelle der Angabe eines Hostnames in Kombination mit dem Schlüsselwort ALL_HOSTS benutzt. Am einfachsten sieht man das aber an einem Beispiel:

Während im Beispiel der Hostgruppe test1 noch statisch die Hosts srv1 und srv2 zugeordnet werden, werden der Hostgruppe test2 hingegen dynamisch alle Hosts mit beiden Tags tag1 und tag2 zugeordnet. Den Unterschied macht ALL_HOSTS nach der Liste. Durch ALL_HOSTS wird die Liste erst als Liste von Host Tags interpretiert.  Dynamisch ist die Host Tag-Lösung aus dem einfachen Grund, dass ich mich nun um nichts weiter kümmern muss als den Hosts das passente Tag zuzuordnen.

Es besteht jetzt aber auch noch die Möglichkeit Tags zu negieren. Das passiert durch ein einfaches Ausrufezeichen:

In der Hostgruppe test1 landen nun alle Hosts, die nicht mit tag1 markiert sind. In test2 landen alle Hosts, die mit tag2 aber nicht mit tag3 markiert sind.

Host mit einem Host Tag auflisten

Über den check_mk Parameter –list-tag TAGNAME lässt sich übrigens eine entsprechende Liste mit Hosts generieren. Es können mehrere Tags, welche durch Leerzeichen getrennt sind, angegeben werden und Negieren mit Ausrufezeichen ist hier auch möglich. Was man damit z.B. anfangen kann, habe ich bereits in einem anderen Beitrag beschrieben.

 

 

Checks oder Services bei einer check_mk Inventur ignorieren

Update: Anleitung betrifft die Konfiguration in der main.mk Alles kann jedoch auch in der Weboberfläche konfiguriert werden.

Wollen wir mal nicht alles, was check_mk findet, auch in den Inventur haben, stehen wir nun vor der Wahl, ob wir checks oder services ignorieren wollen.

Der Unterschied zwischen check und service?

Ich möchte es am Beispiel des checks df einmal versuchen zu erklären. Wie schon gesagt, ist df ein check. Dieser listet uns alle Dateisysteme eines Systems und deren Belegung auf. Check_mk generiert uns hier nun automatisch für jedes Dateisystem einen Service.

Um es so zu sagen: Hinter jedem Service muss ein check steht. Ein check kann jedoch mehrere Services hervorbringen.

Damit wäre also schon der Unterschied geklärt. Jetzt zur Praxis.

Check Ignorieren

Einen (oder mehrere)check(s) kann ich in der Variable ignored_checks ausschließen.
Diese basiert wieder durch das bereits mehrfach erklärte Muster:

Drei Beispiele, check1 und check2 werden überall ignoriert, 3+4 nur bei rechner 1+2, die checks 5+6 bei allen Rechnern mit hosttag1 und hosttag2. Die Arbeit mit Host Tags habe ich übrigens hier beschrieben.

Wie komme ich nun aber auf den Namen des checks? Dazu verschiedene Möglichkeiten. Ein check_mk -L listet uns alle checks, die es so gibt. Bei der Inventur ist der Name des checks der, welcher links in grün in der Liste steht und natürlich auch in der autocheck Datei ist der Check in der Liste noch mal zu finden. Sollte dazu eine Frage kommen, werde ich das noch einmal genauer erklären.

Service Ignorieren

Will ich nur einen Service ignorieren, gehen wir über die Variable ignored_services und hinterlegen, bei welchen Hosts wir welchen Service nicht sehen wollen.  Der Name des Services entspricht jeweils dem Namen des Checks wie er in Nagios steht.  Ich muss ihn wie immer nicht ganz ausschreiben, sondern kann mit z.B. fs_ jeden Service abfangen, der mit fs_ beginnt.

Am Beispiel:

Anstelle ALL_HOSTS kann natürlich jede Kombination aus dem ersten Beispiel benutzt werden. In die Liste nach ALL_HOST schreibe ich einfach alle Services mit Komma getrennt.

Wichtig

Das alles wirkt natürlich erst nach eine Re-inventur (-II), bzw muss vor der ersten Inventur gemacht werden. Diese info gilt nur für Versionen vor 1.2.4. Ab 1.2.4 ist keine Reinventur mehr nötig

Inventur in check_mk nur bei bestimmen Host Tag durchführen durch Kommandoersetzung

Update: Dieser Tipp ist veraltet:

In aktuellen Check_MK Versionen reicht bereits ein:

 

Heute nur ein schneller Tipp:

In check_mk ist es, wie bekannt, in der Konfiguration möglich, Hosts einen Tag zuzuordnen, um auf sie eine bestimme Konfiguration anzuwenden. Jetzt wäre es natürlich toll, nur bei Hosts mit einem bestimmten Tag auch eine Inventur bzw. Reinventur durchführen zu können.

Das kann jetzt check_mk nicht von alleine, dafür hilft uns aber die Shell. Diese bietet eine Kommandoersetzung. Schreibe ich hinter einen Befehl einen zweiten Befehl in die Form $(), werden die Ausgaben des zweiten Befehles dem ersten als Parameter übergeben.

Wollen wir jetzt alle Hosts mit dem Tag Linux inventarisieren, hängen wir nur den Inventurbefehl check_mk -I mit dem Befehl zusammen, welcher uns eine Liste mit Hosts zu einem Host Tag liefert: check_mk –list-tag

Da die Kommandoersetzung eine Funktion der Shell ist, kann diese natürlich auch mit anderen Programmen und bei ganz anderen Problemen benutzt werden.

SNMP Geräte mit check_mk überwachen

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.

Das Überwachen eines SNMP-Gerätes ist eine der vielen Stärken von check_mk.

Für meinen heutigen Artikel setze ich voraus, dass du den Artikel Einstieg in die Benutzung von check_mk bereits gelesen hast. Er beschreibt die Grundlagen, auf die ich hier nicht noch einmal genauer eingehe.

Wie nehme ich das SNMP Gerät in check_mk auf?

Die Aufnahme eines SNMP-Gerätes in check_mk läuft genau gleich über die all_hosts Variable ab.  Als Unterschied MUSS ich den Host Tag SNMP setzen:

Setze ich übrigens noch den Host Tag tcp, erfolgt die Überwachung gleichzeitig noch über den normalen Agenten weg.

SNMP Community

Würden wir nun eine Inventur probieren, würde check_mk einen SNMP-Bulkwalk versuchen und dazu die Community public verwenden. Deswegen habe ich nun schon einmal die Tags muenchen und berlin gesetzt. Diese will ich nun dazu verwenden, andere SNMP-Communitys zuzuordnen.

Hast du meine anderen Artikel aufmerksam gelesen, solltest du schon verstehen was hier passiert. Allen Rechnern mit Host Tag muenchen wird die Community smpcom1 zugewiesen, snmpcom2 geht an alle Rechner mit Host Tag Berlin.

SNMP v3

Jetzt gibt es natürlich noch das sicherere SNMP v3. Um dieses zu benutzen muss dem Host noch zusätzlich der Tag v3 zugewiesen werden.

In den snmp_communities Variable setzt ich nun keinen String mit einem Communitynamen, sondern eine Tupel mit 4 Werten:

Inventur

Bei der Inventur ist nun nichts weiter zu beachten. Sie kann gleich einer normalen Inventur durchgeführt werden. Es sollte entsprechend deiner installierten checks alles gefunden werden, was du überwachen willst.

SNMP Plugin für check_mk entwickeln

Nachdem ich schon die Grundzüge erklärt habe, wie man ein Agent basierendes check_mk Plugin entwickelt (siehe hier) folgt nun ein kleines Update mit der Frage vorweg:  Wie entwickelt man einen SNMP basierenden check?

Nun, die gute Nachricht ist, dass ich nicht viel schreiben muss. Es funktioniert genau so wie in meiner ersten Anleitung, Teil 2 und Teil 3. Lediglich Teil 1 muss ich hier neu schreiben, denn die Daten kommen nun natürlich nicht von einem Agent, sondern vom einem SNMP Walk. Also spare ich mir sogar einige Arbeit und muss nur noch angeben was ich denn aus dem Tree haben möchte.
Und das funktioniert über snmp_info

Aber nun mal langsam was hier passiert: Die Basis OID, die ich angebe, ist der Hauptzweig unter dem alle meine OIDs zu finden sind, die ich brauche. Die unteren Zweige sind die Daten, bei denen ausgehend vom Hauptzweig ein SNMP Walk gemacht wird. Lassen wir mal die noch tiefere Ebene weg, würden folgende OIDs in unserem Beispiel gezogen:

Nehme ich nun noch die tiefere Ebene hinzu, wird jeweils gezogen:

Sprich, es wird verschachtelt.

Und nun gehts einfach weiter. In der info Variable, welche meine Inventur und meine Check-Funktion bekommt, bekomme ich nun eine Liste geliefert, in der alle Werte zu finden sind, welche unter den OIDs gefunden wurden. Geht also weiter wie in Teil 2 und Teil 3 beschrieben. Eben nur mit anderen Daten.

Viel Spass damit… aber nein, da war noch was.

Eine automatische Inventur wäre noch eine schöne Sache. Dazu benötige ich nur eine kleine Funktion, lässt sich meist als lambda Funktion regeln, die ich in snmp_scan_functions[“checkname”] registriere. Dieser wird einfach nur das Objekt oid übergeben und sie muss True oder False zurückliefern. Mit dem Objekt oid kann man nun nämlich eine OID abfragen (wer hätte es für möglich gehalten) und mit der Ausgabe alle möglichen Vergleiche anstellen. Ein Beispiel:

Steht nun in der OID ‘1.3.6.1.2606.1.2.3.4.5 das Wort Test , wird automatisch die Inventurfunktion aufgerufen.

Ohne die scan_function müsste ich bei der Inventur explizit den Checknamen mitgeben, damit der check erkannt wird. Dies geht übrigens mit check_mk –checks checkname -I rechnername .

Das soweit zu SNMP Checks. Jetzt aber wirklich viel Spass! :)

Monitoring mit OMD Einführung und Vorteile

Aufgrund einiger Nachfragen nach dem, was die OMD eigentlich ist, nun eine kleine Einführung. OMD steht wie bereits mehrfach beschrieben für Open Monitoring Distribution. OMD ist jedoch kein neues Programm, sondern wie der Name schon sagt, eine Distribution, man kann sagen, eine Zusammenstellung.

Zusammengestellt wurden bei OMD verschiedene bekannte Monitoring Produkte wie Nagios, pnp4nagios, nagvis, check_mk und auch nützliche Tools wie z.B.dokuwiki. Alles in allem steht eine stetig wachsende Anzahl von Programmen zu Verfügung.

Das Besondere dabei ist, dass bereits alles von Experten aufeinander abgestimmt wurde. Es ist also nicht weiter nötig, alles einzeln zu installieren, sondern man installiert nur noch das OMD Packet als eine ganze Einheit. Anschließend an die Installation kann man mit einem Kommando (omd create SITENAME) eine Monitoring Umgebung, genannt Site, erzeugen. Es lassen sich sogar beliebig viele (natürlich durch die Ressourcen des Servers begrenzt) parallele Sites erstellen und nutzen.

Jede dieser Sites läuft dann unter einem eigenen User und kann unabhängig von den anderen Sites gestoppt und gestartet werden. Nun aber zurück zu einer Site: Nach einem Kommando kann ich nun eine Site anlegen, in welche ich mit su – Sitename wechseln kann.

Bin ich in der Site, steht mir bereits alles fix und fertig eingerichtet zur Verfügung. Wir erinnern uns, es war nicht mehr nötig, als das OMD Packet zu installieren. In einem lokalen etc Verzeichnis finde ich nun die Unterordner meiner Monitoring Tools, in welche ich meine Konfigurationsdateien ablegen kann.

Mit dem Befehl omd config kann ich bequem Grundlegendes einstellen und mit omd start wird die Site dann gestartet. Unter der http://servername/sitename/ steht anschließend ein Startbildschirm bereit, in dem ich auch schon gleich die GUI auswählen kann, mit der ich arbeiten will. Neben der klassischen Nagios GUI gibt es hier zur Zeit die Multisite GUI sowie die Thrunk GUI. Links in die Dokuwiki und nach pnp4nagios wurden natürlich auch nicht vergessen.

Schon einmal so einfach ein komplettes Nagios mit Plugins aufgesetzt? Ich glaube nicht :)!

Jetzt ist hier aber noch nicht Schluss. Auch an ein Update-Konzept wurde gedacht. Die Zeiten, bei dem alles einzeln getestet und geupdatet werden musste, sind mit OMD auch vorbei.

Man installiert für ein Update nun erst einmal eine neue OMD Version. Dabei werden aber meine bestehenden Sites wieder nicht beeinflusst. Diese laufen so weiter, wie sie zuvor eingerichtet waren. In der Site kann ich dann mit omd update auf Wunsch Up- oder sogar Downgraden. Zur Auswahl stehen alle Installierten OMD-Versionen. Geupdatet wird automatisch alles. Die Freiheit, innerhalb der Site selbst andere Versionen von z.B. Nagios oder check_mk zum Testen zu installieren, bleibt natürlich. Man installiert einfach in die lokalen Pfade der Site.

Apropos Testen. Natürlich möchte ich erst einmal in Ruhe testen, bevor ich ein OMD-Update durchführe. Nichts ist leichter als das und zwar als root: Mit omd cp ProdSite TestSite kopiere ich einfach komplett meine Produktiv Site in die neue Site, hier mit Namen TestSite. In TestSite kann ich nun das Update ausführlich testen, bevor ich dann ProdSite update und TestSite einfach wieder lösche.

Zusammenfassung

Also nochmal in Kurzform:

  • OMD ist kein neues Programm, sondern fasst alle nötigen Monitoring-Tools zusammen
  • Das Konzept sieht unabhängige Sites vor, die parallel laufen
  • Jede Site hat ihre eigene Umgebung
  • Jede Site kann ihre eigenen Programmversionen benutzen
  • Sites kann man klonen
  • Alle Tools sind optimal aufeinander abgestimmt
  • Sie werden die Zeit bereuen, die Sie in Vergangenheit in Installation und Update Ihrer Nagios Umgebung gesteckt haben

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 :)