Checkmk Schritt für Schritt: Business-Intelligence-Logik aufbauen
Mit Checkmk könnt Ihr nicht nur einzelne Hosts und Services überwachen, sondern auch ganze Geschäftsanwendungen abbilden. Beispielsweise könnte die Anwendung „Backup“ aus mehreren redundanten Services auf mehreren redundanten Hosts bestehen. Fällt dort ein Service oder gar ein Host aus, interessiert das den Admin – nicht aber unbedingt die Anzugträger. Schließlich funktionieren Backups ja noch. Im Folgenden seht Ihr Schritt für Schritt, wie Ihr ein solches BI-Objekt aufsetzt.
Vorbereitung und Ziel
Wie immer in unserer Checkmk-Serie: Ihr findet hier keine tiefgehenden Erklärungen zu jeder erdenklichen Option oder der Gesamtsystematik, sondern schlicht die nötigen Schritte, um das Ziel zu erreichen. Das Ziel: Zwei Backupserver mit jeweils mehreren Backupdiensten sollen als eine Anwendung überwacht werden.
Wenn Ihr das Beispiel 1:1 nachbauen wollt, benötigt Ihr dazu vorab den Host backup1 mit den Services backupdienst1 und backupdienst2 sowie den Host backup2 mit den Services backupdienst1 und backupdienst3. Klont einfach Euren localhost und benennt die Klone entsprechend.
Die Dienste könnt Ihr ganz einfach über Local Checks realisieren: Die Anleitung dazu gibt’s hier. Die Kurzversion: Legt auf Eurem localhost ein Skript beliebigen Namens unter /usr/lib/check_mk_agent/local beziehungsweise C:\Program Files (x86)\check_mk\local mit folgendem Inhalt an:
echo 0 backupdienst1 - Backup1 ist in Ordnung.
echo 1 backupdienst2 - Backup2 ist in Ordnung.
echo 0 backupdienst3 - Backup3 ist in Ordnung.
Dadurch werden auf den localhost-Klonen neue Services verfügbar. Fügt bei backup1 die ersten beiden und bei backup2 ersten und dritten Service dem Monitoring hinzu. Der backupdienst2 taucht dank der 1 mit dem Status WARN im Monitoring auf – hier nur zur Verdeutlichung.
Wichtig: Immer wenn Ihr etwas an Hosts und Services ändert, müsst Ihr die Änderungen via Activate Changes übernehmen – nur dann werden BI-Bäume neu berechnet!
1. Regelpaket anlegen
Zunächst müsst Ihr im BI-Bereich ein BI Pack anlegen. Diese Pakete dienen erst mal nur der Ordnung und haben keinerlei Funktion. Los geht’s mit New BI Pack von der BI-Startseite.
Vergebt als ID backupsystem und als Titel Redundantes Backup-System. Bestätigt mit Create.
2. Hosts und Services anlegen
In der BI-Pack-Übersicht klickt Ihr auf das rechte Symbol mit der angedeuteten Liste, um Inhalte im Pack zu erstellen.
Erstellt nun eine eine erste Aggregationsregel über Create aggregation rule. Fertige BI-Anwendungen wie das Backup-System heißen intern Aggregate – hier geht es aber erst mal um Regeln im Aggregat, das Aggregat folgt später.
Sinn dieser ersten Regel: Es sollen die gewünschten Hosts und Services aufgenommen werden – ohne aber jeden Host und Service einzeln anzugeben. Unter Rule Properties vergebt Ihr als ID backupserver (weil hier die einzelnen, untersten Knoten, also die einzelnen Hosts und Services erzeugt werden). Als Titel kommt Backup-Server $instanz$ ins Feld und auch unter Parameter kommt ein instanz (hier wird die Variable eingeführt, daher keine $$ davor und dahinter). Das ist einfach eine beliebig benannte Variable, so dass diese Regel später für die Hosts backup1 und backup2 funktioniert – über den Aufruf backup$instanz$. Das Verständnis kommt in ein paar Schritten – versprochen ;)
Nun kommt der wichtigst Bereich der Regel: Unter Child Node Generation baut Ihr nun die Logik, nach der die Nodes/Knoten des BI-Baums erstellt werden. Beginnt ganz einfach mit State of a host und gebt als Host backup$instanz$ an. Fügt über den gelben Button einen weiteren Generator hinzu, dieses Mal mit State of a Service. Als Host kommt auch hier wieder – etwas gedoppelt – das backup$instanz$ hin und als Service backupdienst. Das .* im Bild steht für beliebige weitere Zeichen dahinter und ist nur zur Verdeutlichung im Bild: Check_MK versteht diesen Eintrag als regulären Ausdruck mit offenem Ende, sprich es werden eh alle Services gefunden, die mit backupdienst anfangen.
Unter Aggregation Function lasst Ihr einfach alles auf Default: Take worst state of all nodes heißt nichts weiter, als dass ein übergeordneter Knoten den schlimmsten Status eines darunter liegenden Hosts/Services annimmt. Ist auch nur ein Service CRIT, ist auch der Knoten darüber CRIT. Stellt die Regel nun fertig.
3. Backup-System anlegen
Die Hosts und Services Eures Backup-Universums habt Ihr nun adressiert, bringt aber noch nichts. Ihr braucht nun eine weitere Regel (Aggregatin Rule), die als übergeordneter Knoten agiert und die eben angelegte Regel für beide Backup-Hosts aufruft – schließlich will die Variable $instanz$ auch noch mit Werten versorgt werden. Legt also eine neue Regel an und vergebt bei Rule Properties die ID backupsystem und als Titel Redundantes Backup-System. (Ja, sorry – das BI-Pack hieß auch schon so, ist halt redundant … Aber nicht verwirren lassen: Der Name vom BI-Pack aus Schritt 1 ist völlig irrelevant.)
Weiter geht’s wieder mit Child Node Generation: Dieses Mal wählt Ihr als Generator Call a rule und dann als aufzurufende Regel Backup-Server $instanz$ aus Eurem Regelpaket. Und bei Arguments gebt Ihr nun eine 1 ein – so wird die oben erstellte Regel zum Einfügen eines Hosts/Services für den Host backup1 aufgerufen. Und somit wird dann eben ein Knoten für diesen Host erstellt. Entsprechend fügt Ihr denselben Generator noch mal hinzu, nur eben mit einer 2 als Argument.
Unter Aggregation Function wählt Ihr diese Mal die Funktion Count the number of nodes in state OK. Oben wurde dem Knoten mit der worst-Option der schlimmste Zustand eines darunter liegenden Objekts zugeteilt. Bei dieser Variante könnt Ihr einfach selbst festlegen, bei wie vielen OK-Objekten der Knoten auch OK ist. Schließt wieder mit Create ab.
4. Logik bewundern
Eure Logik ist im Grunde schon fertig – im Hauptmenü Eures BI-Packs seht Ihr Eure beiden Regeln. Die oberste Regel, also die Wurzel des Baums, erkennt Ihr an dem kleinen Baumsymbol und einer fehlende Ziffer in der Level-Spalte.
Klickt auf das Baumsymbol, um Euch das Baumskelett anzuschauen.
5. Aggregat anlegen
Leider seht Ihr in der GUI noch immer nichts: Ihr habt ein BI-Pack als eine Art Ordner und darin zwei Regel, die die Logik abbilden. Da sich Regeln aber wie Ihr gesehen habt kombinieren lassen, muss jetzt noch das eigentliche Aggregat erstellt werden, das dann endlich als hübsche Ansicht in der GUI auftaucht. Klickt also auf Aggregations und erstellt dann eine neue Aggregation.
Unter Properties könnt Ihr oben Gruppennamen wie Wichtiges eintragen, müsst Ihr aber nicht. Das heißt nur, dass in der Übersicht aller Aggregationen eine oder mehrere Gruppen existieren werden, unter denen dieses Aggregat dann auftaucht (Gruppe heißt hier eigentlich nur so viel wie Überschrift). Zudem gibt es wieder den Punkt Call a rule, wo Ihr zunächst das BI-Paket Redundantes Backup-System (backupsystem) und daraus die Wurzel-Regel Redundantes Backup-System (backupsystem) (nochmal sorry …) auswählt. Und das war’s für’s Erste!
6. Aggregat anschauen
Ruft nun im Views-Element in der Navigation Business Intelligence/All Aggregations auf – hier findet Ihr nun Euer Aggregat in der angegebenen Gruppe. Ihr seht nun als Wurzel Redundantes Backup-System und darunter die beiden per Variable ($instanz$) eingebundenen Hosts und darunter alle per regulärem Ausdruck eingebundenen Services (backupdienst*).
Das Coole: Fügt Ihr nun weitere Backup-Services nach diesem Namensschema ins Monitoring hinzu, landen sie automatisch in dem Aggregat. Das Uncoole: Wenn Ihr einen weiteren Backup-Host (backup3) hinzufügt, müsstet Ihr diesen samt des Parameters 3 der Regel hinzufügen. Aber das geht ebenfalls automatisch – falls Ihr noch Lust habt …
7. Extra: Hosts dynamischer einbinden
Erstellt also spaßeshalber noch ein letztes Mal eine Regel in Eurem BI-Pack. Vergebt in den Eigenschaften wieder Namen und ID nach Belieben und schaut dann in den Kasten Child Node Generation: Nun wählt Ihr Create nodes based on a service search. Statt also die unterste Regel zweimal aufzurufen und die Parameter 1 und 2 manuell zu übergeben, wird hier nun eine Suche durchgeführt, die die Regel eben für alle Hosts aufruft, die zum Suchmuster passen.
Wählt über Host name den Eintrag Regex for host name. Als Hostnamen selbst gebt Ihr hier backup(.*) an – es werden also wieder Server/Hosts wie backup1 oder backup44 gefunden. Die Klammerung hat hier nur den Zweck, dass der dort gefundene Text – also zum Beispiel 1 oder 44 – in der Variablen $1$ gespeichert wird (das ist so’n Regex-Ding, kennt man auch von awk & Co.).
Da auch die Servicenamen mit backup beginnen, könnt Ihr den Ausrduck auch bei Service Regex eintragen, auch wenn die Klammer hier gerade nicht nötig ist. Und wie schon bei der vorigen Regel, wählt Ihr bei Call a rule wieder das BI-Pack Redundantes Backup-System (backupsystem) und daraus die unterste Regel für Hosts/Services namens Backup-Server $instanz$ (backupserver) und setzt bei Arguments die Variable $1$ ein, die hier denselben Zweck erfüllt, wie oben $instanz$.
Schlussendlich müsst Ihr natürlich wieder ein Aggregat anlegen – wie unter Schritt 5, nur wird nun eben diese Regel aufgerufen. Packt das Aggregat wieder in die Gruppe Wichtiges.
8. Das Ergebnis
Ihr seht nun abermals den Baum von eben. Zwar wird hier das ganze Konstrukt WARN, weil eben nur mit der worst-Option gearbeitet wurde, aber ansonsten ist es derselbe Baum.
9. Das Wunder der Suche
Klont jetzt zum Testen einen Eurer Backup-Hosts, nennt ihn zum Beispiel backup44 und übernehmt die Änderungen via Activate Changes. Und siehe da: In der unteren Variante mit den per Suche eingefügten Hosts/Knoten, ist nun auch der neue geklonte Server zu sehen.
Es gibt noch massenhaft „Kleinkram“ (Wartungszeiten, Verfügbarkeit, Rechte etc.) zum Thema BI in Check_MK, im Handbuch werden es später vermutlich über 40 große Seiten sein. Aber zum Schluss noch ein Tipp zum Spielen: Vor den Hosts und Services im Baum seht Ihr kleine Zahnradsymbole. Per Klick könnt Ihr die Elemente darüber testweise in einen anderen Zustand versetzen und so feststellen, wie sich der Ausfall dieser Komponente auf das gesamte BI-Konstrukt auswirkt. Und genau das ist eigentlich schon ein tolles, praktische Szenario: Ihr wollt einen Service oder einen Host kurzzeitig abstellen, um etwa eine Aktualisierung durchzuführen, und könnt so vorab prüfen, ob das geht, ohne die Anwendung Backup-System damit ebenfalls zu gefährden.
Natürlich lässt sich das obige Beispiel auch massiv ausbauen! Nur mal als Beispiel: Ihr könnt statt einem, auch gleich mehrere Services für die Suche angeben – ein simples backupdienste|foobar würde alle Services finden, die mit einem der beiden Suchwörter beginnen. Auch vertragen Services mehrere Match-Gruppen: Mit service-(.)-(.)-test könntet Ihr Dienste wie service-mirco-backup-test oder service-jochen-backup-test oder service-peter-media-test direkt ansprechen. Die Match-Gruppen sind über $1 und *$2** und so weiter zu verwenden.
Ansonsten gilt wie so oft: Die Werkzeuge habt Ihr nun an der Hand, der Rest liegt eher in Eurer Fantasie und Eurem Abstraktionsvermögen. Insofern: Viel Spaß!
Übrigens: Ihr könnt auch Philips-Hue-Leuchten mit Checkmk überwachen.
