Ep. 8 (Teil II): Intelligente Regeln mit Host-Tags

Name: checkmk
Rating: 4.7 (114 reviews)

Hinweis: Alle Videos sind im deutschen Originalton und verfügen über englische Untertitel. Zudem stellen wir für alle Inhalte die Transkripte auf Englisch zur Verfügung.

[0:00:10]	Weiter geht es beim zweiten Teil unserer Trilogie über Regeln und Service Parameter.
[0:00:15]	Und jetzt kommen wir zu dem Thema, was ich euch schon versprochen hatte, und zwar den sogenannten Host-Tags und auch den Labels. Und zwar geht es hier darum, dass ich jetzt Regeln formulieren will, nach der Art. Auf allen meinen produktiven Datenbankservern habe ich ganz bestimmte Schwellenwerte für die CPU-Auslastung. Um so eine Regel zu formulieren, muss ich erstmal sagen: Was heißt eigentlich ein Server ist produktiv.html? Und dazu verpassen ich dem Server entweder ein Host-Tag oder ein Label. Die Unterschiede werden wir dann gleich noch sehen. Labels ist ein Feature, das erst ab der Version 1.6 eingeführt wurde.
[0:00:50]	Wir fangen mal mit den Host-Tags an. Idee ist, dass ich beim Anlegen eines Hosts in der Konfiguration bei jedem Host dazu sage, welche Tags hat er, und dann kann ich mich später auf diese Tags beziehen. Ich kann zum Beispiel bei jedem Server sagen: Ist der produktiv oder ist ein Testsystem. Und später kann ich dann sagen: Diese Regel gilt für alle Testsysteme. Ja, wie das geht schauen wir uns jetzt einfach mal an. Wie ihr seht, habe ich inzwischen vier weitere Hosts ins Monitoring aufgenommen: Nämlich dbserver01, dbserver02, 03 und 04.
[0:01:23]	Was ich jetzt mache ist: Ich sage der Server 1 und 2 sollen produktive Server sein, 3 und 4 sollen Testsysteme werden.
[0:01:32]	Dazu gehe ich jetzt in die Verwaltung der Hosts und fange jetzt mal an mit dem dbserver01, und gehe in die Eigenschaften rein.
[0:01:42]	Ich klappe jetzt mal die Basics Settings und Network Adress zu, Data Sources. Was mich interessiert sind die Custom Attributes und da findet ihr jetzt die Host-Tags, die schon vordefiniert von Checkmk sind. Das sind allerdings nur Beispiele.
[0:01:59]	Ich nehme mal Criticality und da gibt's eben verschiedene Auswahlmöglichkeiten.
[0:02:06]	Ich kann sagen sei ein Produktive system oder ein Test system. Das ist also eine Tag- Auswahl, die ist schon vordefiniert, ihr seht ein Tag funktioniert so, ich habe einen Namen der sogenannten Tag-Gruppe, wie Kritikalität und da gibt es dann einfach verschiedene Auswahlen, und jeder Host hat einfach einen dieser Werte.
[0:02:24]	Ich nehme jetzt hier Produktive system dann gehe ich zum Zweiten, sage auch Produktive system. Übrigens ist das hier der Default-Wert, wie man hier in Klammern sieht, also müsste ich eigentlich gar nichts machen für die Produktivsysteme.
[0:02:40]	Ich setze sich jetzt trotzdem einfach mal explizit, dann gehe ich zum Dritten, und da sage ich jetzt: das ist ein Testsystem.
[0:02:51]	Und das Gleiche mache ich beim Vierten auch - so. Es gibt übrigens auch, wo wir gerade dabei sind, hier die Möglichkeit, eine Aktion in mehreren Hosts gleichzeitig zu machen. Ich kann zum Beispiel hier die Checkboxen aktivieren und hätte sagen können, hier, bei drei und vier, die möchte ich jetzt gleichzeitig editieren, und kann eben jetzt hier sagen, die sollen jetzt Testsystem ist sein - beide. Da hätte ich mir ein bisschen Arbeit gespart. Gut, sobald ich die Änderung aktiviert habe, sind diese Hosts markiert mit diesen Eigenschaften, aber das hätte ich mir auch sparen können, denn aus diesen Host-Tags folgt erstmal keine weitere Aktion.
[0:03:43]	Das Monitoring läuft genauso wie bisher, aber was wir jetzt machen können ist eben auf Basis von diesen Host-Tags neue Regeln definieren. Und das machen wir jetzt. Der nächste Schritt, den wir machen ist, dass wir jetzt eine Regel anlegen, oder genauer gesagt, mehrere Regeln, weil ich möchte nämlich jetzt festlegen, das die CPU-Auslastung auf dem Testsystem eigentlich egal ist, oder ich setze auf 100%, was erlaubt ist. Bei Produktivsystemen setze ich die Schwelle auf 80%, weil ich da sage: Da will ich einfach noch ein bisschen Puffer mehr haben.
[0:04:14]	Gut, ich wähle den Einstieg, wie in der letzten Episode gesehen zum Beispiel über einen der Datenbankserver, und geh einfach zu dem Service direkt hin, das ist am Einfachsten, hehen wir hier CPU utilization, das ist das eine prozentuale Auslastung.
[0:04:29]	Das hat mit der Load überhaupt nichts zu tun, und geh jetzt hier wieder über die Parameter.
[0:04:36]	Und sehe, es gibt noch keinen Schwellwert, es gibt überhaupt keinen Parameter, und ich lege eine Regel an, gehe jetzt wieder auf Create host specific rule, aber bei den Conditions räume ich jetzt gleich noch ein bisschen auf. So, was wir haben ist die Explicit hosts, das kann ich gleich wieder rausnehmen und anstelle dessen gehe ich bei Host tags rein und wähle jetzt die Tag-Gruppe aus Criticality, und füge eine Bedingung hinzu. Diese Maske schaut übrigens jetzt ab der Version 1.6 ein bisschen anders aus, also wer doch mit 1.5 arbeitet, wundert euch bitte nicht dabei. Bei der 1.5 ist es noch bisschen einfacher, allerdings ist die Version 1,6 deutlich flexibler.
[0:05:27]	Ich wähle also Criticality aus und sage: Ich will dafür eine Bedingung hinzufügen.
[0:05:32]	Und jetzt kommt eben diese neue Zeile, und hier steht Criticality is Productive system. Und da könnte ich jetzt eben die anderen auswählen. Ich lasse jetzt mal productive, und legen mal für die Produktivsysteme jetzt die Schwellen fest. Dazu gehe jetzt wieder nach Value, und gehe auf total CPU utilization. Ihr seht jetzt auch da wahnsinnig viele verschiedene Möglichkeiten.
[0:06:00]	Ich mache einfach mal Fixed Levels auf 80% und 90%. Das waren jetzt Schwellwerte für meine Produktivsysteme.
[0:06:13]	Und jetzt lege ich gleich noch eine zweite Regel an. Ich kann es zum Beispiel machen, indem ich einfach diese Regel hier kopiere, ändere die Schwellen ab auf, sagen wir, 101%, was nie erreicht werden kann, und bei der Bedingung ändere ich jetzt einfach das im Test system. Speichern.
[0:06:35]	Jetzt, die Frage der Reihenfolge der Regeln.
[0:06:37]	Nun, die spielt hier keine Rolle, denn die Bedingungen schließen sich gegenseitig aus. Ein Host kann nur entweder ein Testsystem oder ein Produktivsystem sein.
[0:06:47]	Deswegen ist es völlig egal, welche Reihenfolge ich das hier mache, übrigens wir sind in dem Regel-Editor immer noch drin über den Host dbserver01, er ist, wie wir von festgelegt haben, ein Produktivsystem und deswegen ist die erste Regel als grün gekennzeichnet. Man sieht auch noch die Bedingungen hier: Host: Criticality is Productive system.
[0:07:05]	Und daraus folgen eben die Schwellwerte 80%, 90%. Und der Rest ist wie gehabt, ich aktiviere die Änderungen, und damit habe ich jetzt die Konfiguration gemacht und zum ersten Mal Host-Tags verwendet. Ja, wir haben jetzt eine vordefinierte Host-Tag-Gruppe verwendet mit dem namen Criticality.
[0:07:25]	Die ist eigentlich auch nur als Beispiel da drinnen. Wir empfehlen diese Beispielgruppen nicht zu verwenden, sondern sich eigene Gruppen anzulegen, und dazu gibt es das Wato-Modul Tags.
[0:07:40]	In diesem Modul seht ihr jetzt die vordefinierten Tag-Gruppen. Die sind auch klassifiziert als buildin. Diese ersten Beiden, wie gesagt sind nur Beispiele. Die kann man auch löschen, deswegen sind die jetzt nicht als eingebaut deklariert. Ich mache jetzt eine komplett neue Tag-Gruppe und jede Gruppe hat eine interne ID, die muss eindeutig sein, die darf auch keine Leerzeichen enthalten, also ein typisches ID-Feld und das Zweite ist der Titel, den könnt ihr beliebig benennen.
[0:08:11]	Ich will jetzt eine Gruppe anlegen für die Art der Anwendung. Ich möchte einfach sagen: Es gibt Web Server, Datenbank-Server und sonstiges. Das ist nicht ein ganz realistisches Beispiel, aber es illustriert glaube ich ausreichend, um was es geht.
[0:08:25]	Deswegen sage ich jetzt hier bei der Tag-Gruppen-ID application. Titel: Application, ich mach mal mit großem A, dann kann man de Unterschied erkennen.
[0:08:38]	Das Topic ist eigentlich nur dafür da, wo dieses Tag, diese Tag-Gruppe dann später sichtbar werden soll, bei den Eigenschaften vom Host. Wenn ihr wollt, könnt ihr eigenes Tag, also ein eigenes Topic anlegen, wo ich sag My Own Tags, zum Beispiel, dann erkennen wir, dass die von uns eben definiert wurden. So, und jede Tag-Gruppe braucht mindestens ein oder halt mehrere mögliche Auswahlen.
[0:09:11]	Und dazu sage ich hier add tag choice, dass mache ich gleich dreimal, auch die Tags selber müssen IDs bekommen, die müssen auch eindeutig sein über die Tag-Gruppen hinweg. Also, ich sage hier zum Beispiel Tag ID web, Tag ID db, Tag ID other, und sage Titel Webserver, Database Server und als Dritte sage ich Other. Die Auxillary tags: vergesst die einfach, die braucht ihr höchstwahrscheinlich nicht, und ihr könnt auch die Reihenfolge festlegen durch diese Kreuze hier, aber das soll uns jetzt erstmal egal sein. Ich speichere das Ganze und habe jetzt eine eigene Tag-Gruppe definiert.
[0:10:03]	Es gibt noch eine folgende Regel, dass ein Host aus jeder Tag-Gruppe, wenn man es nicht explizit fest legt, immer den ersten Eintrag bekommt. Das heißt: Alle Hosts, die jetzt da sind, sind als Webserver deklariert, und das gilt so lange, bis ich ihnen ein anderes Tag zuweise. Es wäre natürlich ein Grund zu sagen, dass wir Other nach oben schieben, damit haben wir festgelegt, dass wenn wir nicht Webserver oder Database Server auswählen, das immer das aber gilt, das macht in dem Fall jetzt hier tatsächlich noch etwas mehr Sinn.
[0:10:41]	Die Tag-Gruppe ist jetzt da, jeder Host hat aus jeder Gruppe einen Tag, aber weitere Auswirkungen hat es bis jetzt noch nicht. Das können wir dann erreichen, indem wir wieder Regeln anliegen. Der nächste Schritt ist jetzt, dass wir unser Hostnummer anschauen und Host das richtige Tag zuordnen.
[0:11:00]	Dazu gehe ich jetzt wieder in meine Host-Verwaltung und will jetzt einfach zu diesen vier Servern, das sind alles vier Datenbankserver, da möchte ich jetzt eben das Tag Database Server zuordnen.
[0:11:13]	Am Einfachsten geht es natürlich wieder mit dem Checkboxen. Dann muss ich nämlich nicht jeden einzeln auswählen. Ich wähle also diese vier Stück aus. 1-2-3-4, gehe jetzt hier auf Edit und sehe jetzt hier unten das Topic My Own Tags, ich habe ja gesagt, ich habe mein eigenes Topic angelegt.
[0:11:38]	Topics sind hier in dem Fall diese Kästen, und sage: ich möchte Application festlegen, und zwar nicht als Other, sondern ich sage: das sind Datenbankserver.
[0:11:49]	Damit habe ich diese vier Hosts gleichzeitig editiert. Der nächste Schritt ist jetzt, dass ich wieder meine Regeln anschaue, wir machen einfach Folgendes: Die Regel, die wir vorhin gerade angelegt haben, oder die beiden Regeln die werden wir so ändern, dass sie nur noch auf Datenbankserver greifen.
[0:12:07]	Ich zeige euch jetzt noch mal einen anderen Weg, wie ihr regeln finden könnt. Und zwar, wenn ihr direkt auf das Modul Host & Service Parameters geht, gibt es hier oben einen Knopf, der heißt Used rulesets.
[0:12:18]	Da sind alle Regelsätze drin, wo es mindestens eine Regel gibt. Ein paar von denen werden schon beim neuen Checkmk-System ausgefüllt, deswegen sind ein paar mehr Einträge drin, aber wir finden so relativ schnell auch unsere beiden Regeln zur CPU-Utilization. Wenn ihr ungefähr wisst, wie die Regel heißt, geht es natürlich noch einfacher. Dann könnt ihr auch auf der Seite einfach suchen.
[0:12:44]	Zum Beispiel Utilization oder util, ich meine, da kann es natürlich auch einen ganzen Haufen Treffer geben, aber ich sehe auch relativ schnell hier, dass ich der einzige Regelsatz, wo ich zwei Regeln drin habe, und dann komme ich zu den Regeln definiert hat anderer Weg wäre natürlich jetzt wieder über den Service zu gehen, wie wir das die ganze Zeit vorher gemacht haben. So, jetzt editiere ich die beiden Regeln so, dass ich einfach bei jeder Regel eine weitere Bedingung hinzufüge, und zwar wähle ich jetzt hier die Tag-Gruppe aus, die ist jetzt hier My Own Tags / Application und mache eine Bedingung dazu, und sage Application ist Database Server. Speichern. In der Übersicht sehe ich bei den Conditions ist hier eine Zeile dazu gekommen.
[0:13:34]	Zweiten Regel mache ich das auch. Application ist Database Server. Speichern.
[0:13:49]	Und jetzt sehen wir diese beiden Regeln, Die eine Regel auf Produktivsysteme, die andere Regel auf Testsysteme.
[0:13:54]	Und damit haben wir eine sehr elegante Methode gefunden für eine große Zahl von Hosts allgemeingültige Regeln festzulegen, und wenn ihr jetzt einen neuen Host ins Monitoring aufnehmt und eben die richtigen Tags zuweist, der kriegt ihr automatisch seine richtige Konfiguration. Das ist eben der Vorteil von den Host-Tags. Ein sehr ähnliches Konzept zu den Host-Tags sind die Labels.
[0:14:18]	Die Labels sind in Version 1.6 dazugekommen und erfüllen eine ähnliche Funktion, aber im Gegensatz zu den Host-Tags haben die Labels eine Freiform, ihr müsst nichts vordefinieren, könnt einfach jedem Host beliebige Labels anfügen und darüber dann später Bedingungen definieren, es ist also, man kann sagen ein bisschen quick and dirty, es ist einfach, nur fehlt dann natürlich die Kontrolle, ob man sich nicht zum Beispiel vertippt hat beim Anlegen eines Hosts. Labels können auch automatisch erzeugt werden, wenn ihr zum Beispiel Docker überwacht oder bestimmte Cloud-Dienste werden Labels, die Hosts dort haben, automatischen mit in Checkmk übernommen.
[0:14:56]	Schauen wir uns mal an, wie man manuell Labels vergeben kann.
[0:15:00]	Um den Hosts Labels zu geben, muss man auch überhaupt nichts vordefinieren, dass ist eben das Schöne an den Labels - ist sehr einfach, ich geh einfach wieder zu meinem Hosts und kann jetzt zum Beispiel einfach sagen beim Datenbankserver 1 hier bei Custom Attributes, Labels, Checkbox an und sage zum Beispiel app:web. Wichtig bei den Labels zu wissen ist: Es muss immer ein Doppelpunkt sein.
[0:15:27]	Das, was bei den Host-Tags die Gruppe ist und der Wert, ist bei den Labels einfach das Wort vor dem Doppelpunkt, ist quasi die Gruppe und aus jeder Gruppe kann es dann nur einen Wert geben, und im dem Fall ist es ja app:web, und wenn ich Enter drücken, kann ich noch ein zweites Label hinzufügen
[0:15:45]	Zum Beispiel test:123, was auch immer ich Lust habe. Wenn ich jetzt hier speichere, seht ihr auch in der Liste der Hosts, dass diese Labels hier sichtbar sind als sogenannte explizite Labels, dass heißt, die habe ich von Hand vergeben. Und jetzt kann ich darüber natürlich Bedingungen formulieren.
[0:16:07]	Ich sag jetzt zum Beispiel, wenn das Label test:123 existiert, dann soll irgendwas Spezielles gelten. Gehe ich also wieder rein in meine Regeln von vorhin, die wir schon mehrfach editiert haben und nehmen zum Beispiel die Erste und sehe, hier ich kann bei den Host labels jetzt eine Label Condition hinzufügen und sage jetzt hier dieser hat das Label test:123. Wenn ihr das habt, dann gilt eben diese Regeln, oder ich kann sagen: Er hat hat es nicht.
[0:16:51]	Wichtig zu wissen ist, wenn ihr mehrere Bedingungen hier vergebt, dann gilt immer die sogenannten Unverknüpfung, also die Regel greift nur dann, wenn wirklich auch alle dieser Bedingungen gleichzeitig erfüllt sind.
[0:17:04]	So, ihr seht schon den Unterschied zwischen Labels und Tags. Labels sind sehr einfach, ich muss nicht deklarieren, ich kann sie einfach direkt verwenden, haben aber den Nachteil, dass es keinen Schutz gibt, dass ich mich irgendwo vertippe.
[0:17:16]	Das heißt, wenn ihr eine sehr genaue Kontrolle braucht, jeder Host darf nur genau eine der folgenden Auswahlen haben, ihr wollt es quasi erzwingen, ihr wollt auch, wenn Kollegen Hosts aufnehmen, dass sie nichts falsch machen können, wenn ihr sehr klare Struktur braucht, sind Host-Tags dann das richtige Mittel, wenn ihr entweder schnell und einfach arbeiten wollt, oder die automatische Labels verwenden wollt, die von Checkmk automatisch erkannt werden, dann sind die Labels natürlich auch eine interessante Alternative.
[0:17:44]	Und natürlich kann man selbstverständlich beide Methoden gleichzeitig verwenden. So, und jetzt sind wir fertig im zweiten Teil.
[0:17:51]	Im dritten Teil zeige ich euch dann, wie ihr eure Hosts in Ordnern verwaltet.