Ep. 8 (Teil I): Mit Regeln arbeiten und Schwellwerte festlegen

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:00]	Willkommen zurück im Checkmk Channel.
[0:00:03]	Heute wollen wir ein etwas komplexeres Thema angehen, nämlich wie ihr eure Hosted Services parametrieren könnt, wie ihr zum Beispiel Schwellwerte festlegen könnt.
[0:00:11]	Hier hat Checkmk ein ganz besonderes System, was es auch von den anderen Produkten unterscheidet, und zwar ist bei uns die Konfiguration regelbasiert und weil es etwas umfangreicher ist, das ganze Thema haben wir gesagt, wir machen drei Videos draus.
[0:00:24]	Im Ersten zeigen wir euch, wie ihr mit Regeln arbeitet und Schwellwerte festlegen könnt. Im Zweiten befassen wir uns dann mit den sogenannten Host-Tags, das sind die Merkmale von Hosts, die ihr verwenden könnt, um die Regeln noch intelligenter aufzubauen, und im dritten Teil schauen wir uns dann an, wie ihr Hosts in Ordnern verwalten könnt, und auch das macht dann wieder die Konfiguration noch etwas eleganter.
[0:00:56]	Heute soll es also darum gehen, wie ihr Parameter von Services festlegen könnt.
[0:01:01]	Was sind Parameter?
[0:01:02]	Und das Wichtigste ist erstmal die Frage, wann der Service überhaupt WARN & CRIT gehen soll, also, wann ihr eigentlich ein Problem erkennen wollt. Checkmk hat ja ganz sinnvolle Default-Einstellungen, aber es wird immer so sein, dass ihr einzelne Fälle habt, wo ihr die ändern wollt, also allein zum Beispiel bei einem Dateisystem: Ab welcher Belegung soll der Service auf WARNING gehen? Es gibt noch ein paar andere Parameter, die man auch festlegen kann, zum Beispiel: wie oft soll ein Service geprüft werden?
[0:01:26]	Also, alle wie viele Minuten? Hier ist er die Default-Wert 1 oder zum Beispiel in welchem Zeitfenster soll alarmiert werden? Und solche Dinge.
[0:01:33]	Wir befassen uns erstmal mit den Schwellwerten, also mit der Frage, wann ein Service auf WARN & CRIT geht. Und dazu nehmen wir jetzt einfach mal als Beispiel den Service CPU-Load auf unserem Monitoring-Server selbst.
[0:01:45]	So, ich bin jetzt wieder auf dem kleinen Monitoring-System, das wir in den letzten Folgen aufgebaut haben, gehe auf diese beiden Hosts und finde ich hier meinen Monitoring-Server und da gibt es eben den Service CPU load, der die momentane CPU-Auslastung misst.
[0:02:04]	Die Auslastung ist nicht das Gleiche wie die Utilization, also keine prozentuale Auslastung. Da sage ich später noch ein paar Worte mehr dazu.
[0:02:11]	Und hier möchte ich jetzt eben die Schwellwerte festlegen ab wann dieser Service auf WARN und CRIT gehen soll, und dazu gibt es verschiedene Wege, der Einfachste ist, dass ich hier auf dieses Menü gehe und hierauf 'Parameters for this service' da komme ich jetzt zu einer Liste von allen möglichen Parametern, interessant ist der erste Kasten, und da seht ihr die zweite Zeile CPU load (not utilization).
[0:02:38]	Das ist anklickbar, man sieht auch hier das steht momentan auf dem Default-Wert und zwar auf dem Wert WARNING bei 5, eine Auslastung von 5 pro CPU-Kern und kritisch bei 10, ist sind also relativ hohe Werte.
[0:02:51]	Um das Ganze zu ändern, gehe ich jetzt hier auf CPU load und komme zu einer sogenannten Regelkette.
[0:02:59]	Diese Regelkette ist jetzt leer, das heißt, es gibt noch keine Regel für CPU load und ich kann jetzt entweder eine Regel speziell für diesen Host anlegen oder ich kann eine Regel anlegen, die allgemein gilt.
[0:03:13]	Ich nehme jetzt mal diesen Schritt, dass ich eine Regel nur für den Host mycmkserver anlege.
[0:03:21]	Jede Regel hat erstmal allgemeine Eigenschaften, das sind die Rule Properties. Hier gibt es eine Beschreibung, ein Kommentar das sind alles optionale Felder.
[0:03:31]	Aber ich kann hier einfach mal eintragen, die Auslastung vom Monitoring-Server wenn ich das möchte, und klappt den einfach jetzt mal zu. Und das Wichtigste ist jetzt bei jeder Regel gibt es immer eine Bedingung und einen Wert.
[0:03:48]	Fangen wir mal mit dem Wert an. Dieser legt nämlich jetzt die Schwellwerte fest.
[0:03:52]	Man sieht hier ist Warnung per Default auf 5 eingestellt und kritisch ab 10.
[0:03:57]	Jetzt machen wir einfach zum Test, dass ich sage bei einer Load von 1 möchte ich schon eine Warnung haben und ab 3 pro CPU-Kern soll es kritisch werden.
[0:04:06]	Das heißt pro Kern. Wenn ihr ein System habt, mit 4 Kernen, wäre dann die warnung ab 4.
[0:04:16]	Die Bedingungen sieht es erstmal sehr komplex aus.
[0:04:19]	Was hier bereits vorausgefüllt ist, dass ist das diese Regel nur für den Host mycmkserver gilt.
[0:04:25]	Weitere Bedingungen sind noch nicht gesetzt, und das lasse ich jetzt auch einfach mal, und tue einfach nur speichern.
[0:04:31]	So, wir haben jetzt eine Änderung, das kennt ihr schon mit dem Activate Changes, ich gehe jetzt hier auf diesen 1 change, aktiviere den und in dem Moment wird diese Änderung und damit der neue Schwellwert aktiv.
[0:04:44]	Zur Kontrolle mache ich das Gleiche jetzt nochmal wie vorhin, ich gehe noch mal ganz den gleichen Weg, zu diesem Server, zur CPU load, zu den Schwellwerten und gehen auf die Parameter, und jetzt seht ihr, dass sich was geändert hat. Es steht nämlich jetzt hier Rule 1 in Main directory, also die erste Regel in diesem Main directory und hier den Schwellwert, der jetzt herauskommt.
[0:05:06]	Das ist eigentlich genau das, was ich wollte, das es ab 1 bzw. 3 auf WARN beziehungsweise auf CRIT geht. Jetzt kann man natürlich fragen: Wie kann ich das jetzt hervorrufen?
[0:05:17]	Ich mal einfach einen kleinen Trick, ich gehe mal auf die Konsole.
[0:05:21]	Ich bin jetzt auf meine Monitoring-Server angemeldet und mache jetzt was, was ihr vielleicht nur machen solltet, wenn ihr wisst, was ihr tut. Nämlich, ich mache hier eine Endlosschleife mit der Shell. Das bewirkt, dass ein Prozess jetzt die ganze Zeit rechnet, und damit steigt eben die Load genau um 1. Die Load heißt nämlich die Anzahl der Prozesse, die momentan gerade rechnen, und damit ich die mal bisschen hoch krieg, mache ich das einfach ein paar mehr und habe jetzt wahnsinnig viele Prozesse, die im Hintergrund laufen und rechnen.
[0:05:50]	Mit top kann ich mir das anschauen, und ihr seht, dass hier ein Haufen Shell-Prozesse laufen, und hier oben seht ihr schon, dass diese load average eben beginnt zu steigen.
[0:05:59]	Wie ist hier jetzt schon auf 1,9 auf 2,6 - sind ja Durchschnittswerte, deswegen dauert es ein bisschen bis sie nach oben laufen. Übrigens gibts hier den Durchschnitt der letzte Minute, über die letzten fünf Minuten, über die letzten 15 Minuten.
[0:06:13]	Ich gehe jetzt zurück zum Monitoring-System und schaue mir mal diesen Service CPU load an, der ist jetzt noch immer noch auf OK, der wird auch nur einmal pro Minute ausgeführt, aber was ich jetzt machen kann, um das zu beschleunigen, wenn mir langweilig ist, gehe ich wieder in dieses Menü rein und sage 'Reschedule Check_MK service', das führt dazu, dass auch dieser Service neu berechnet wird.
[0:06:37]	Und, wenn alles richtig läuft, sollte der jetzt auf WARNING gehen oder vielleicht sogar schon CRIT, je nachdem wie weit die CPU-Load inzwischen gestiegen ist.
[0:06:50]	So, wie wir sehen ist es jetzt inzwischen auf WARNING. Wir haben eine 15 minuten CPU-Auslastung 1,7.
[0:06:57]	Ich kann nochmal in die Details reingehen zu diesem Service, und wenn ich mir den Graphen anschaue, dann sehe ich auch hier dass die CPU-Auslastung langsam beginnt zu steigen.
[0:07:10]	Man sieht übrigens auch die Schwellwerte jetzt eingezeichnet im Graphen, dass ist eigentlich ganz praktisch, dass man jetzt sieht, das bei 1 bzw. 3 neben eben der Schwellwert für WARN und CRIT ist.
[0:07:21]	Also, es verhält sich genauso, wie wir es haben wollen und damit sind wir an dieser Stelle erstmal fertig.
[0:07:28]	Damit mein armer Monitorings-Server wieder Luft zum Atmen bekommt, sollte ich natürlich jetzt diese Testprozesse alle wieder beenden. Das mache ich jetzt noch mal eben kurz, indem ich einfach hier top beende und mir die mit fg wieder im Vordergrund hole, und der Reihe nach einfach mit Str+C beende, und dann sollte es - gut.
[0:07:57]	Das war der Letzte, ich mache nochmal top, die Prozessen sind verschwunden und die Load wird langsam wieder ganz nach unten gehen.
[0:08:06]	Machen wir noch eine zweite Regel und zwar diesmal eine für ein Dateisystem.
[0:08:10]	Da gibt es jetzt einen kleinen Unterschied, nämlich die CPU-Load ist ja eine Sache, die es pro Server nur ein einziges Mal gibt.
[0:08:17]	Bei Dateisystemen ist aber so, dass auf einem Rechner natürlich mehrere Dateisysteme sein können und deswegen muss ich bei der Regel auch angeben, welches der Dateisysteme ich meine - wenn es denn ein Spezifisches sein soll.
[0:08:29]	Und das machen wir jetzt mal am Beispiel von dem Rootfile-System von dem Monitoring-Server.
[0:08:34]	Ich gehe jetzt wieder zu meinem Monitoring-Server und diesmal nehme ich mir den Service Filesystem / das ist in dem Fall das Rootfile-System von dem Monitoring-Server.
[0:08:44]	Auch hier gehe ich wieder den gleichen Weg. Ich gehe auf die Parameters for this service, jetzt seht ihr hier oben, dass diese zweite Zeile schon wahnsinnig komplex ist. Filesystems (used space and growth) so heißt der Regelsatz, mit dem ihr Schwellwerte für Dateisysteme festlegt.
[0:09:02]	Wenn ich jetzt auf den drauf gehe, dann sehe ich wieder das Gleiche wie vorhin, allerdings gibt es jetzt hier eine kleine Besonderheit: hier steht 'Create Mount points specific rule for'.
[0:09:12]	Nun, was heißt das jetzt?
[0:09:15]	Diese Regel würde gelten für den Host mycmkserver und für den Service, mit dem Filesystem, der den Mount point / überwacht. Bei Filsystem ist es so, die werden unterschieden bei Unix und Linux am Mount-Punkt und das Rootfile-System ist der /, das heißt, wenn ich jetzt hier eine Regel anlege, wird die genau für diesen einen Service gelten.
[0:09:39]	So, ich klicke jetzt also auf 'Create Mount point specific rule for'.
[0:09:46]	Und jetzt sehe ich wieder das Gleiche, ich habe Rule Properties, die lasse ich jetzt mal leer, weil die sind optional, und ich habe eben ein Wert und eine Bedingung.
[0:09:54]	Schauen wir uns zuerst die Bedingungen an.
[0:09:57]	Bei der Bedingung ist jetzt eingetragen Explicit host, also es soll nur ganz explizit für diesen Host gelten.
[0:10:04]	Und hier steht Mount Point angekreuzt, nur für den Mount Point. Das besondere ist jetzt hier steht / und ein $ dahinter.
[0:10:11]	Warum ist das so?
[0:10:13]	Es handelt sich hier um sogenannte reguläre Ausdrücke.
[0:10:16]	Zu regulären Ausdrücken machen wir vielleicht mal eigenes Video, es gibt auch im Handbuch eine Beschreibung dazu.
[0:10:22]	Meistens reicht es zu wissen, dass diese Beschreibung, die man hier eingibt einen Match macht auf den Anfang vom Service-Namen.
[0:10:30]	Würde ich dieses Dollarzeichen weglassen, würde es auf alle Mount-Punkte gelten, die mit / beginnen, das sind in diesem Fall alle Mount-Punkte die überhaupt gibt, es ist also wenig sinnvoll.
[0:10:39]	Dollar ist eine Abkürzung für das Ende vom Service-Namen hier.
[0:10:43]	Das heißt, diese Regel wird gelten nur für das Dateisystem, das genau / heißt.
[0:10:50]	Schauen wir uns den Wert an, bitte erschreckt jetzt nicht, es gibt wahnsinnig viele Möglichkeiten bei der Übewachung von File Systemen in Checkmk. Das ist ein sehr komplexer, mächtiger Check, und da könnt ihr wahnsinnig viele Sachen machen, bis hin zur Trend-Computation, wo ihr zum Beispiel erkennen könnt, ob das File System mit der Zeit anwächst.
[0:11:13]	In den meisten Fällen braucht man einfach erstmal diesen ersten Punkt, den kreuze ich jetzt an und kann damit eben Schwellwerte festlegen.
[0:11:23]	Das Einfachste, was es gibt, sind einfach Levels for filesystem used space. Das heißt Schwellwerte für den prozentual belegten Platz. Und hier werden 80% und 90% vorgeschlagen, das sind auch die Default-Schwellwerte, wenn man nichts eingestellt hat.
[0:11:36]	Umgekehrt könnte ihr sagen, ich will die Schwellwerte auf den freien Platz, dann würdet ihr die zweite Option auswählen.
[0:11:42]	Ich bleibe jetzt mal bei der Ersten, und setze jetzt mal ein sehr, sehr kleinen Wert, damit ich einfach mal sehen kann, ob das ganze Ding dann auf WARNING geht.
[0:11:50]	In dem Fall setzt ich zum Beispiel WARNING auf 5 % und kritisch auf 10%.
[0:11:55]	Das ist natürlich sehr gering, die Schwellen, aber ich mache das ja nur, um das Ganze auszuprobieren.
[0:12:03]	Ich speichere das, aktivere die Änderung und wenn es durch gelaufen ist, kann ich mir wieder diesen Service raussuchen.
[0:12:12]	Mache ich sich über Quicksearch: Filesystem /.
[0:12:16]	Nachdem ich nur ein Host drin habe, finde ich hier auch nur einen Service. Ich bin wieder ungeduldig und mache hier einen Reschedule, damit der nächste Check ausgeführt wird, und wie seht, dass er sofort auf kritisch geht.
[0:12:27]	Übrigens zeigt dieser Service auch an, dass die Schwellwerte hier auf 5% beziehungsweise 10% sind.
[0:12:35]	Gut, machen wir noch eine dritte Regel. Diesmal geht es um Network Interfaces, also Netzwerkkarten auf Servern und Switch Ports, also die Netzwerkanschlüsse von Routern und Switchen.
[0:12:45]	Die gehen nämlich in Checkmk über den gleichen Check.
[0:12:48]	Der heißt Interface und dann kommt eben der Name von dem Interface oder dem Port.
[0:12:53]	Und jetzt möchte ich mal eine Regel anlegen, die nicht nur auf einen Service gilt, sondern gleich für mehrere.
[0:12:58]	Und wie das geht zeigt ich euch. Das ist nämlich auch nicht sehr schwierig.
[0:13:02]	Ich beginne damit, dass ich meinen Switch aufrufe, und sehe, der hat ganz viele Ports. Jetzt nehmen wir einfach irgendeinen, zum Beispiel den 17. gehe wieder auf Parameter for this service.
[0:13:15]	Diesmal heißt die Regel Network Interface and switch ports. Und ich gehe hier drauf und komme wieder zu der Seite, die ihr schon kennt.
[0:13:24]	Hier heißt jetzt 'Create ports specific rule for', eben eine Regel nur für einen ganz bestimmten Switch Port.
[0:13:35]	Wenn ich jetzt hier die Regel anlege, seht ihr auch unten das bereits der Host-Name ausgefüllt ist und dieser Port 17 hier eingetragen ist. Wieder mit dem Dollarzeichen am Ende, damit es nicht nur für den Präfix gilt.
[0:13:49]	So, jetzt kann ich einfach das Kreuz rausnehmen.
[0:13:51]	In dem Moment gilt es für alle Interfaces von switch1, oder ich kann dieses Kreuz auch noch rausnehmen, dann gilt es eben für alle Switches, alle Ports, auf allen Hosts.
[0:14:04]	Bei dem Wert seht ihr auch hier wieder, dass dieses ganze Ding extrem komplex ist.
[0:14:08]	Ihr könnt da wahnsinnig viel machen, ich mache jetzt einfach mal die Used bandwith, das heißt, ich will Schwellwerte festlegen dafür, wenn auf dem Port eine bestimmte Menge an Verkehr läuft.
[0:14:21]	Und ihr seht auch hier, ich kann hier gleich mehrere Einträge machen und bei jedem festlegen, ob ich zum Beispiel nur den ein- oder ausgehenden Verkehr haben will. Ich nehme jetzt den Hinausgehenden.
[0:14:32]	Und ihr könnt zum Beispiel nicht nur eine Obergrenze festlegen, sondern auch eine Untergrenze, dass ihr zum Beispiel eine Warnung kriegt, wenn auf diesem Port kein Verkehr mehr ist.
[0:14:41]	Ich lege hier einfach mal prozentuale Schwellwerte fest von 10% und 20 der Bandbreite, ihr könntet auch Schwellwerte in Bits pro Sekunde anlegen und ganz viele andere Dinge.
[0:14:55]	Dinge. So, wenn ich jetzt hier wieder speichere, und die Änderung aktiviere, dann habe ich von allen Switch Ports eben diese Schwellwerte festgelegt.
[0:15:07]	Was passiert eigentlich, wenn hierfür ein Service zwei Regeln anlegt.
[0:15:09]	Welche gilt nun hier. Dazu gibt es in Checkmk ein ganz einfaches Prinzip: Die erste Regel, deren Bedingungen erfüllt ist, gilt und legt den Wert fest.
[0:15:17]	Wenn danach weitere kommen, werden die einfach ignoriert und diesem Prinzip kann man sich zunutze machen, um ein Konzept von allgemeinen Prinzip und Ausnahme zu machen. Ich kann nämlich zwei Regeln anlegen: Eine für den allgemeinen Wert, und eine für spezifische Ausnahmen.
[0:15:32]	Da muss ich nur darauf achten, dass diese Regel vor den anderen kommen.
[0:15:35]	Machen wir Beispiel: Ich gehe zu meinem Switch und mache eine Regel für einen ganz bestimmten Port.
[0:15:44]	Also, nehmen wir an zum Beispiel ich will für Port 18 was anderes festlegen als wie für die anderen Ports.
[0:15:50]	Dann gehe ich also hier wieder auf den Regelsatz.
[0:15:53]	Ihr seht, es gibt bereits eine Regel, die hatten wir vorhin angelegt und ich lege jetzt eine weitere Regel an, bei der Bedingung lasse ich jetzt Port 18 drin stehen und switch1, das heißt, sie soll auch nur für diesen einen Port gelten.
[0:16:11]	Und lege jetzt zum Beispiel eine Used bandwidth fest, die von der anderen abweicht, indem ich obere Schwellen von 80% und 90% festlege.
[0:16:23]	Wenn ich diese Regel jetzt speichere, werdet ihr sehen, dass wir jetzt zwei Regeln haben.
[0:16:28]	Dieser farbige Punkt hier zeigt euch an, ob für diesen Host switch1 und diesen Port 18, wo wir gerade sind, welche Regel greift.
[0:16:37]	Wir sehen zum Beispiel, diese erste Regel greift, die Bedingung erfüllt und sie definiert Parameter.
[0:16:44]	Die zweite Regel ist gelb, das bedeutet die Bedingung wäre zwar erfüllt, aber die Parameter sind schon von der ersten Regel festgelegt. Damit ist sie wirkungslos.
[0:16:52]	Das ist natürlich jetzt ganz blöd, weil das sollte ja die Ausnahme sein, und die Ausnahme sollte natürlich immer Vorrang haben vor der allgemeinen Regel.
[0:16:58]	Also, nehme ich jetzt hier dieses Verschiebekreuz und schiebe die an erste Stelle.
[0:17:04]	Und jetzt seht ihr es ist wieder grün oben, aber dass jetzt die andere Regel, das heißt: Zuerst kommt die Ausnahme, die definiert jetzt hier den Wert, und die allgemeine Regel greift in dem Fall nicht.
[0:17:16]	Ich gehe es nochmals zu einem Switch zurück und schaue mir irgendeinen anderen Port an zum Beispiel Interface 5, gehe wieder zu dem Regelsatz.
[0:17:27]	Jetzt seht ihr das für diesen Port Regel zwei gilt, wenn mich das interessiert, gehe ich wieder auf den Regelsatz drauf und sehe jetzt, dass die erste Regel grau ist, ist auch klar, weil jede Bedingung nicht greift, weil ich eben be Port 5 bin und diese Regel nur für Port 18 gilt.
[0:17:45]	Das heißt er fällt durch zur zweiten Regel, und das ist eben diese allgemeine Regel, die meine allgemeinen Schwellwerte festlegt.
[0:17:51]	Und so kann ich eben sehr einfach auch komplexe Umgebungen in Griff bekommen, weil ich eben nur die Ausnahmen explizit definieren muss und für alle anderen Default-Einstellungen machen kann.
[0:18:01]	Es gibt noch einen anderen Weg zu den Regeln, den ich euch jetzt zeigen möchte und er nicht über einen bestimmten Host einsteigt, sondern über ein Konfigurationsmodul, was alle verfügbaren Regelsätze, die es überhaupt gibt, auflistet.
[0:18:14]	Ihr findet es hier bei Host & Service Parameters.
[0:18:17]	Da gibt's jetzt zuerst mal eine Einteilung in ganz viele verschiedene Kategorien und in jeder Kategorie gibt es dann wieder Regelsätze. Was ich jetzt machen will, ist in der Monitoring Configuration, da findet ihr eine Regel und zwar das Host Check Command. Ich möchte es mal für folgenden Fall eine Lösung finden: Nehmen wir an, ihr wollt einen Host prüfen, eine Firewall -irgend sowas, aber die lässt sich nicht anpingen und ich möchte jetzt sagen, dass der Check mit der Host geprüft wird, der normalerweise ein Ping ist, geändert wird auf ein TCP-Connect zu Port 80.
[0:18:51]	Dazu gehe ich in diese Host Check Command Regelkette rein.
[0:18:56]	Ihr findet hier schon eine vordefinierte Regel, die sich mit Docker befasst, da möchte ich jetzt nicht näher darauf eingehen, ich erzeuge jetzt hier eine Regel, und Conditions lasse ich jetzt leer.
[0:19:08]	Ihr könntet jetzt explizit bestimmte Hosts eintragen, dass kennt ihr oder wir machen es mit den Host-Tags, was ich dann in der nächsten Folge beschreiben werde, aber ich lege jetzt als Host Check Command fest, dass ich nicht ein Ping haben will, sondern ich will ein TCP-Connection-Test auf Port 80, das heißt um zu testen, ob der Host lebt, wird versucht eine Verbindung zum Port 80, also zudem HTTP-Service aufgemacht, der vielleicht auf diesem Host gerade läuft und auch hier kann ich die Regel speichern.
[0:19:35]	Und der Rest ist eigentlich wie gehabt.
[0:19:39]	Generell kann man sagen, dass alles was in Checkmk für Host und Services konfiguriert wird über Regeln läuft, und wie ihr das einrichten könnt, habt ihr jetzt gesehen.
[0:19:49]	In dem zweiten Teil von dieser Folge befassen wir uns damit den sogenannten Host-Tags, wo man dann sehr einfach Bedingungen formulieren kann, wie zum Beispiel auf allen meinen produktiven Linux-Servern soll folgende Bedingungen gelten.
[0:20:01]	Bleibt dran, wir sehen uns in Kürze zum zweiten Teil.