Business Intelligence (BI)

Bevor Sie Schritt für Schritt mit der Praxis anfangen, benötigen Sie zunächst ein paar Begriffe:

Jede mit BI formalisierte Anwendung wird als Aggregation bezeichnet, da hier aus vielen Einzelzuständen ein Gesamtzustand aggregiert wird.

Eine Aggregation ist ein Baum von Objekten. Diese werden Knoten genannt. Die untersten Knoten — also die Blätter des Baums — sind Hosts und Services aus Ihren Checkmk-Instanzen. Die übrigen Knoten sind künstlich erzeugte BI-Objekte.

Jeder Knoten wird durch eine Regel erzeugt. Das gilt auch für die Wurzel des Baums — also den obersten Knoten. Die Regeln legen fest, welche Knoten unter einem Knoten hängen und wie aus deren Zuständen der Zustand des Knotens berechnet werden soll.

Auch der oberste Knoten einer Aggregation (die Wurzel des Baums) wird mit einer Regel erzeugt. Dabei kann eine Regel mehrere Aggregationen erzeugen.

Am einfachsten geht alles mit einem konkreten Beispiel. Dafür haben wir uns für diesen Artikel die „Mystery Application“ ausgedacht. Nehmen Sie an, dass dies eine wichtige Anwendung in einem nicht näher genannten Unternehmen ist. Dabei spielen unter anderem fünf Server und zwei Netzwerkswitche eine wichtige Rolle. Damit Sie das Beispiel besser nachvollziehen können, bekommen diese einfache Namen wie srv-mys-1 oder switch-1. Folgendes Schaubild gibt den Aufbau grob wieder:

Wenn Sie die nachfolgenden Schritte eins zu eins durchspielen möchten, können Sie die aufgeführten Monitoring-Objekte kurz nachbauen. Zum Testen genügt es dabei, wenn Sie einen vorhandenen Host mehrfach klonen und die Klone entsprechend benennen. Später kommen noch einige wenige Services ins Spiel, die Sie dann bei Zeit für die betroffenen Hosts ins Monitoring aufnehmen können. Auch da können Sie wieder schummeln: Mit simplen Dummy-Local-Checks bekommen Sie schnell passende Services zum Spielen.

Die Hosts im Monitoring sehen in etwa so aus:

Beginnen Sie mit etwas Einfachem — quasi der einfachst möglichen sinnvollen Aggregation überhaupt: einer Aggregation mit nur zwei Knoten. Dabei möchten Sie den Zustand bei beiden Hosts switch-1 und switch-2 zusammenfassen. Die Aggregation soll Netzwerk heißen und OK sein, wenn beide Switche erreichbar sind. Bei einem Teilausfall soll sie auf WARN gehen und wenn beide Switche weg sind auf CRIT.

Legen Sie los: Das BI-Modul erreichen Sie über Setup > Business Intelligence > Business Intelligence. Die Konfiguration der Regeln und Aggregationen geschieht innerhalb von Konfigurationspaketen: den BI Packs. Die Pakete sind nicht nur deswegen praktisch, weil Sie komplexere Konfigurationen damit besser verwalten können. Sie können auch für ein Paket Berechtigungen für bestimmte Kontaktgruppen vergeben und somit Benutzern ohne Adminrechte das Editieren von Teilen der Konfiguration erlauben. Doch dazu später mehr …​

Wenn Sie das BI-Modul zum ersten Mal aufrufen, sieht das etwa so aus:

Dort ist bereits ein Paket mit dem Titel Default Pack vorhanden. Es enthält eine Demo für eine Aggregation, die Daten eines einzelnen Hosts zusammenfasst.

Für das aktuelle Beispiel legen Sie am besten ein neues Paket an (Knopf Add BI pack), welches Sie Mystery nennen. Wie immer in Checkmk, vergeben Sie eine interne ID (mystery), welche sich später nicht ändern lässt, und einen beschreibenden Titel. Die Option Public brauchen andere Benutzer, wenn sie Regeln in diesem Paket für ihre eigenen Regeln oder Aggregationen verwenden möchten. Da Sie Ihre Experimente vermutlich erst mal in Ruhe alleine durchführen wollen, lassen Sie das deaktiviert:

Nach dem Anlegen finden Sie in der Hauptliste jetzt natürlich zwei Pakete:

Vor jedem Eintrag steht ein Symbol zum Editieren der Eigenschaften () und eines, um zum eigentlichen Inhalt des Pakets zu kommen (), wo Sie jetzt auch hin wollen. Dort angelangt, legen Sie gleich Ihre erste Regel über Add rule an.

Wie immer in Checkmk, will auch diese Regel eine eindeutige ID und einen Titel haben. Der Titel der Regel hat hier allerdings nicht nur Dokumentationscharakter, sondern wird später auch als Name desjenigen Knotens sichtbar, den diese Regel erzeugt:

Der darunter folgende Kasten hat den Namen Child Node Generation und ist der wichtigste. Hier legen Sie fest, welche Objekte in diesem Knoten zusammengefasst werden sollen. Das können entweder andere BI-Knoten sein; dazu würden Sie eine andere BI-Regel auswählen. Oder es sind Monitoringobjekte — also Hosts oder Services.

Für das erste Beispiel wählen Sie die zweite Variante (State of a host) und legen zwei Objekte als Kinder an, nämlich die beiden Hosts switch-1 und switch-2. Das geschieht jeweils mit dem Knopf Add child node generator. Hier wählen Sie dann logischerweise State of a host und tragen jeweils den Namen des Hosts ein:

Im dritten und letzten Kasten, Aggregation Function, geben Sie an, wie der Monitoringstatus des Knotens berechnet werden soll. Grundlage dafür ist immer die Liste der Zustände der Unterknoten. Verschiedene logische Verknüpfungen sind möglich.

Vorausgewählt ist Best — take best of all node states. Das würde bedeuten, dass der Knoten erst dann CRIT wird, wenn auch alle Unterknoten CRIT bzw. DOWN sind. Wie oben erwähnt, soll das hier aber nicht der Fall sein. Wählen Sie stattdessen Count the number of nodes in state OK, um die Anzahl der Unterknoten mit Status OK als Maßstab heranzuziehen. Hier werden als Schwellwerte die beiden Zahlen 2 und 1 vorgeschlagen. Das ist prima, denn es ist genau das was Sie brauchen:

Und so sieht die Maske ausgefüllt aus:

Ein Klick auf Create, und schon haben Sie Ihre erste Regel:

Nun ist es wichtig, dass Sie verstehen, dass eine Regel noch keine Aggregation ist. Checkmk kann ja noch nicht wissen, ob das hier alles ist oder nur Teil eines größeren Baums! Wirkliche BI-Objekte werden erst dann erzeugt und in der Statusoberfläche sichtbar, wenn Sie eine Aggregation anlegen. Dazu wechseln Sie in die Liste der Aggregationen.

Der Knopf bringt Sie zu einer Maske zum Anlegen einer neuen Aggregation. Bei den Aggregation groups können Sie beliebige Namen angeben. Diese erscheinen dann in der Statusoberfläche als Gruppen, unter denen all diejenigen Aggregationen sichtbar werden, welche eben diese Gruppenbezeichnung teilen. Das ist eigentlich das gleiche Konzept wie bei Hashtags oder Schlagworten. Auch die Aggregation ID können Sie wie gewohnt frei vergeben, später aber nicht mehr ändern.

Den Inhalt der Aggregation legen Sie über Add new element fest. Wählen Sie hier die Einstellung Call a rule und bei Rule: die Regel, die Sie gerade angelegt haben (und davor das Regelpaket, in dem diese sich befindet).

Wenn Sie die Aggregation jetzt mit speichern, sind Sie fertig! Ihre erste Aggregation sollte jetzt in der Statusoberfläche auftauchen — vorausgesetzt, Sie haben auch tatsächlich mindestens einen der Hosts switch-1 oder switch-2 im System!

Wenn Sie alles richtig gemacht haben, können Sie jetzt Ihr erstes Aggregat über die Statusoberfläche aufrufen. Das geht am einfachsten über Monitor > Business Intelligence > All Aggregations:

Sehen Sie sich die Darstellung des BI-Baums etwas näher an. Folgendes Beispiel zeigt Ihr Miniaggregat in einer Situation, in der einer der beiden Switches DOWN ist und der andere UP. Wie gewollt, geht das Aggregat dabei in den Zustand WARN:

Dabei sehen Sie auch, dass zur Vereinheitlichung von Hosts und Services ein Host, der DOWN ist, quasi wie ein Service gewertet wird, der CRIT ist. Aus UP wird entsprechend OK.

Die Blätter des Baums zeigen die Zustände von Hosts und Services. Der Hostname — und bei Services auch der Servicename — ist anklickbar und führt Sie zum aktuellen Status des entsprechenden Objekts. Außerdem sehen Sie die letzte Ausgabe des Check-Plugins.

Ganz links neben jedem Aggregat finden Sie zwei Symbole: und . Mit dem ersten Symbol —  — kommen Sie zu einer Seite, die nur genau dieses eine Aggregat anzeigt. Das ist natürlich hauptsächlich dann nützlich, wenn Sie mehr als ein Aggregat angelegt haben. Es eignet sich z.B. gut für ein Lesezeichen. bringt Sie zur Berechnung der Verfügbarkeit. Dazu später mehr.

Links vom Hostnamen finden Sie noch ein interessantes Symbol: . Dies ermöglicht eine „Was wäre wenn“-Analyse. Die Idee dahinter ist einfach: Durch einen Klick auf das Symbol schalten Sie das Objekt testweise auf einen anderen Zustand — allerdings nur für die BI-Oberfläche, nicht in echt! Durch mehrfache Klicks gelangen Sie von (OK) über (WARN), (CRIT) und (UNKNOWN) wieder zu zurück.

BI berechnet dann den kompletten Baum anhand des angenommenen Status. Folgende Abbildung zeigt das Minimalaggregat unter der Annahme, dass neben switch-1, der tatsächlich ausgefallen ist, auch switch-2 DOWN wäre:

Der Gesamtzustand des Aggregats geht dadurch von WARN auf CRIT. Dabei wird dessen Farbe mit einem Karomuster hinterlegt. Dieses Muster zeigt Ihnen an, dass der tatsächliche Zustand eigentlich anders ist. Das ist keineswegs immer der Fall, denn manche Änderungen bei einem Host oder Service sind für den Gesamtzustand nicht mehr relevant, z. B. weil dieser sowieso schon CRIT ist (wie hier im Bild switch-1).

Sie können diese „Was wäre wenn“-Analyse auf verschiedene Arten nutzen, z. B.:

Bei letzterem Szenario setzen Sie das zu wartende Gerät bzw. dessen Services testweise auf . Wenn das Gesamtaggregat dann OK bleibt, muss das bedeuten, dass der Ausfall aktuell durch Redundanz kompensiert werden kann.

Es gibt noch eine zweite Möglichkeit, die BI-Aggregate zu testen: Das direkte Ändern des tatsächlichen Zustands von Objekten. Das bietet sich vor allem in einem Testsystem an.

Zu diesem Zweck gibt es bei den Kommandos ein Host-/Servicekommando mit dem Namen Fake check results. Es ist per Default nur in der Rolle Administrator verfügbar. Diese Methode wurde z. B. bei der Erstellung der Screenshots für diesen Artikel genutzt, um switch-1 auf DOWN zu setzen. Daher kommt der verräterische Text Manually set to Down by cmkadmin.

Hier noch ein kleiner Tipp: Wenn Sie mit dieser Methode arbeiten, schalten Sie am besten die aktiven Checks für die betroffenen Hosts und Services aus, denn sonst gehen diese beim nächsten Checkintervall sofort wieder auf den eigentlichen Zustand zurück. Wenn Sie faul sind, machen Sie das einfach global über das Seitenleistenelement Master Control. Bitte vergessen Sie nie, das später wieder zu aktivieren!

Beim Anlegen des Aggregats haben wir die Eingabemöglichkeit der Aggregation Groups kurz angesprochen. Im Beispiel hatten Sie das vorgeschlagene Main hier einfach bestätigt. Sie sind aber bei der Vergabe der Namen völlig frei und können ein Aggregat auch mehreren Gruppen zuweisen.

Gruppen werden dann wichtig, wenn die Anzahl der Aggregate das übersteigt, was Sie vielleicht auf einem Bildschirm sehen möchten. Sie gelangen zu einer Gruppe, indem Sie bei der Seite All Aggregations auf die angezeigten Namen der Gruppen klicken — also in unserem obigen Beispiel einfach auf die Überschrift Main. Wenn Sie bisher nur dieses eine Aggregat haben, ändert sich natürlich nicht viel. Nur wenn man genau hinsieht merkt man:

Wenn Sie diese Ansicht öfter besuchen wollen, legen Sie doch einfach ein Lesezeichen davon an — am besten mit dem Bookmarks-Element in der Seitenleiste.

Sobald Sie BI-Aggregate eingerichtet haben, werden Sie bei Ihren Hosts und Services im Kontextmenü ein neues Symbol finden:

Mit diesem Symbol gelangen Sie zur Liste aller Aggregationen, in denen der betroffene Host oder Service enthalten ist.

Jetzt da Sie einen etwas interessanteren Baum haben, können Sie sich etwas genauer mit den verschiedenen Darstellungsmöglichkeiten befassen, die Checkmk bietet. Ausgangspunkt dafür ist die Funktion Modify display options, welche Sie im Menü Display finden. Diese öffnet einen Kasten mit Optionen. Der Inhalt des Kastens ist immer angepasst auf die Elemente, die auf der Seite dargestellt werden. Im Falle von BI finden Sie aktuell sechs Optionen:

Letztlich können Sie ein Refresh interval von 30, 60 oder 90 Sekunden setzen und die Anzahl der Spalten über Number of columns bestimmen.

Checkmk beherrscht neben tabellarischen Darstellungen auch die Visualisierung von BI-Aggregaten. So können Sie Aggregate aus neuer Perspektive und bisweilen übersichtlicher darstellen. Sie finden die BI visualization über in der regulären Aggregatsansicht.

Sie können den Baum frei per Klick auf den Hintergrund bewegen und die gesamte Darstellung per Mausrad skalieren. Sobald der Mauszeiger über den einzelnen Knoten landet, bekommen Sie die zugehörigen Statusinformationen via Hover-Fenster. Per Mausrad skalieren Sie nun die Länge der Zweige des Baums.

Per Klick auf die Blatt-Knoten gelangen Sie direkt zu den Detailansichten der Hosts oder Services. Per Rechtsklick auf die sonstigen Knoten erhalten Sie, je nach Art des Knotens, Zugriff auf Darstellungsoptionen und beispielsweise die verantwortliche Regel selbst; im Bild über Edit rule.

Weiter geht’s mit der Konfiguration. Und jetzt wird es Zeit, dass es wirklich zur Sache geht. Bisher war das Beispiel nämlich so einfach, dass es ohne Schwierigkeit möglich war, die Objekte in der Aggregation alle einzeln aufzulisten. Aber was, wenn die Dinge komplexer werden? Wenn Sie viele immer wiederkehrende gleiche oder ähnliche Abhängigkeiten formulieren wollen? Wenn es von einer Anwendung nicht nur eine, sondern mehrere Instanzen gibt? Oder wenn Sie mal eben hundert Einzelservices einer Datenbank zu einem BI-Knoten zusammenfassen wollen?

Nun, dann brauchen Sie mächtigere Methoden der Konfiguration. Und die sind genau das, was Checkmk BI gegenüber anderen Tools auszeichnet — und leider auch die Lernkurve etwas steiler gestaltet. Es ist auch der Grund, warum Checkmk BI sich nicht per „Drag-and-Drop“ konfigurieren lässt. Aber wenn Sie die Möglichkeiten erst einmal kennengelernt haben, werden Sie sie sicher nicht mehr missen wollen.

Beginnen Sie mit den Parametern. Nehmen Sie folgende Situation: Sie möchten bei den beiden Switches nicht nur feststellen, ob sie UP sind, sondern auch den Zustand von zwei Ports wissen, die für den Uplink zuständig sind. Insgesamt geht es um folgende vier Services:

Nun soll der Knoten Switch 1 & 2 so erweitert werden, dass es anstelle der beiden Hostzustände für Switch 1 und 2 jeweils einen Unterknoten gibt, der den Hoststatus und die beiden Uplink-Interfaces zeigt. Diese beiden Unterknoten sollen Switch 1 bzw. Switch 2 heißen.

Eigentlich bräuchten Sie jetzt also zwei neue Regeln — für jeden Switch eine. Besser geht das, indem Sie eine neue Regel switch erstellen, diese aber mit einem Parameter ausstatten. Dieser Parameter ist eine Variable, die man beim Aufruf der Regel aus dem übergeordneten Knoten, hier die alte Regel Switch 1 & 2, mitgeben kann. Im Beispiel können Sie einfach entweder 1 oder 2 übergeben. Der Parameter bekommt einen Namen, den Sie frei wählen können. Nehmen Sie hier z. B. den Namen NUMBER. Die Schreibweise mit Großbuchstaben ist rein willkürlich. Wenn Sie Kleinbuchstaben schöner finden, können Sie gerne auch diese verwenden.

Und so sieht der Kopf der Regel aus:

Als ID für die neue Regel können Sie hier switch wählen. Bei Parameter tragen Sie einfach den Namen der Variablen ein: NUMBER. Wichtig ist jetzt, dass auch im Rule Title der Regel die Variable eingesetzt wird, damit nicht beide Knoten einfach nur Switch heißen und so den gleichen Namen hätten. Beim Verwenden der Variable wird (wie an vielen Stellen in Checkmk üblich) vorne und hinten ein Dollarzeichen gesetzt. Als Ergebnis werden die beiden Knoten dann Switch 1 und Switch 2 heißen.

Die Sache mit den regulären Ausdrücken ist nochmal einen genaueren Blick wert. Beim Matching der Servicenamen haben wir nämlich am Anfang stillschweigend unterschlagen, dass es sich eben grundsätzlich um reguläre Ausdrücke handelt. Wie gerade erwähnt, findet dabei ein Präfix-Match statt.

Wenn Sie also in einem BI-Knoten beim Servicenamen z. B. Disk angeben, werden alle Services des betreffenden Hosts eingefangen, die mit Disk beginnen.

Dabei gelten generell folgende Prinzipien:

Vielleicht klingt das für Sie erst einmal etwas verwegen. Ist es nicht gefährlich, einfach Dinge, die da sein sollten, stillschweigend wegzulassen, wenn sie fehlen?

Nun — mit der Zeit werden Sie feststellen, wie praktisch dieses Konzept ist. Denn dadurch können Sie „intelligente“ Regeln schreiben, die auf sehr unterschiedliche Situationen reagieren können. Gibt es einen Service, der nicht bei jeder Instanz einer Anwendung vorhanden ist? Kein Problem — er wird einfach nur dann berücksichtigt, wenn er auch da ist. Oder werden Hosts oder Services vorübergehend aus dem Monitoring genommen? Dann verschwinden diese einfach aus BI, ohne dass es zu Fehlern oder dergleichen kommt. BI ist nicht dafür da, um festzustellen, ob Ihre Monitoringkonfiguration vollständig ist!

Dieses Prinzip gilt übrigens auch bei explizit definierten Services. Denn eigentlich gibt es diese ja nicht, weil die Servicenamen ja immer als reguläre Ausdrücke gesehen werden, auch wenn sie keine speziellen Sonderzeichen wie .* enthalten. Es handelt sich immer automatisch um ein Suchmuster.

Sie können aber noch weiter automatisieren und vor allem flexibel auf Veränderungen reagieren. Weiter geht es mit dem Beispiel der beiden Anwendungsserver srv-mys-1 und srv-mys-2 aus dem Beispiel. Ihr Baum soll weiter wachsen. Der Knoten Infrastructure soll auf Ebene 2 rutschen. Und als endgültige Wurzel soll eine Regel mit dem Titel The Mystery Application dienen, unter der alles hängen wird. Neben Infrastructure soll es einen Knoten mit dem Namen Mystery Servers geben. Unter diesem sollen die (aktuell) zwei Mystery-Server hängen. Von jedem kommen ein paar exemplarische Services in das Aggregat. Das Ergebnis soll so aussehen:

Analog zu der Hostsuche gibt es auch einen Child-Generator-Typ der Create nodes based on a service search heißt. Hier sehen Sie ein Beispiel:

Sie können hier sowohl beim Host als auch beim Service mit () Teilausdrücke einklammern. Hierbei gilt:

Und bitte vergessen Sie nie, dass Sie mit stets die Onlinehilfe aufrufen können.

Vielleicht sind Sie bei Ihren Versuchen über den Child-Node-Generator State of remaining services gestolpert. Dieser erzeugt für jeden Service eines Hosts, der in Ihrem BI-Aggregat noch nirgends einsortiert ist, einen Knoten. Dies ist nützlich, wenn Sie BI dazu verwenden, um den Zustand aller Services eines Hosts übersichtlich zu gruppieren — so wie dies im mitgelieferten Beispiel gemacht wird.

Nochmal zurück zu den Regelpaketen. Normalerweise benötigt man für alle Editieraktionen in BI die Rolle Administrator. Genauer gesagt gibt es für BI zwei Berechtigungen, zu finden unter Setup > Users > Roles & permissions:

In der Rolle User ist standardmäßig nur die erste der beiden Berechtigungen aktiv. Normale Benutzer können also nur in solchen Regelpaketen arbeiten, in denen sie als Kontakt hinterlegt sind. Dies erledigen Sie in den Details des Regelpakets.

Im folgenden Beispiel ist bei Permitted Contact Groups die Kontaktgruppe The Mystery Admins hinterlegt. Alle Mitglieder dieser Gruppe dürfen jetzt in diesem Paket Regeln editieren:

Übrigens können Sie mit Public > Allow all users to refer to rules contained in this pack anderen Benutzern zumindest erlauben, die hier enthaltenen Regeln zu verwenden — also (woanders) eigene Regeln zu definieren, welche diese Regeln als Unterknoten aufrufen.

Und wie ist es eigentlich mit der Sichtbarkeit der Aggregationen in der Statusoberfläche? Welcher Kontakt darf was sehen?

Nun — in BI-Aggregaten selbst können Sie keine Rechte vergeben. Das geschieht indirekt über die Sichtbarkeit der Hosts und Services und wird geregelt über die Berechtigung See all hosts and services einzelner Rollen unter Setup > Roles & Permissions:

In der Rolle User ist dieses Recht per Default ausgeknipst. Normale Benutzer können nur für sie freigegebene Hosts und Services sehen. Und das drückt sich bei BI so aus, dass sie genau alle BI-Aggregationen sehen, welche mindestens einen freigegebenen Host oder Service enthalten. Diese Aggregate enthalten aber auch nur diese berechtigten Objekte und sind daher eventuell ausgedünnt. Und das wiederum bedeutet, dass sie für unterschiedliche Benutzer einen unterschiedlichen Status haben können!

Ob das jetzt gut oder schlecht ist, hängt davon ab, was Sie möchten. Im Zweifel können Sie die Berechtigung umschalten und manchen oder allen Benutzern erlauben, über den Umweg von BI auch Hosts und Services zu sehen, für die sie kein Kontakt sind — und damit sicherstellen, dass der Status eines Aggregats immer für alle gleich ist.

Das ganze Thema spielt natürlich nur dann eine Rolle, wenn es überhaupt Aggregate gibt, die so bunt zusammengewürfelt sind, dass eben manche Benutzer nur für Teile davon Kontakte sind.

Wie hält es BI eigentlich mit Wartungszeiten? Nun, hier haben wir lange nachgedacht und mit vielen Anwendern diskutiert. Das Ergebnis ist wie folgt:

Um zu verstehen, nach welcher Regel BI den Status „in Wartung“ berechnet, hilft es, wenn Sie sich zurückerinnern, was die eigentliche Idee hinter Wartungszeiten ist: Am betreffenden Objekt wird gerade gearbeitet. Mit Ausfällen ist zu rechnen. Auch wenn das Objekt gerade OK ist, sollte man sich nicht darauf verlassen. Es kann jederzeit CRIT werden. Dies ist bekannt und dokumentiert. Es soll nicht benachrichtigt werden.

Diese Idee kann man 1:1 auf BI übertragen: Im Aggregat gibt es vielleicht ein paar Hosts und Services, welche gerade in Wartung sind. Ob diese gerade OK oder CRIT sind, spielt keine Rolle, denn es ist ja eigentlich Zufall, ob die Objekte während der Wartungsarbeiten ab und zu mal wieder funktionieren oder nicht. Bloß weil im Aggregat aber ein Wartungsobjekt steckt, bedeutet das aber auch nicht gleich, dass die Anwendung, die das Aggregat abbildet, selbst „bedroht“ ist und als „in Wartung“ markiert sein muss. Denn es kann ja Redundanz eingebaut sein, welche den Ausfall der Wartungsobjekte kompensiert. Nur wenn so ein Ausfall tatsächlich zum CRIT-Zustand des Aggregats führen würde — es also eben nicht genug Redundanz gibt und das Aggregat wirklich bedroht ist — genau dann wird es von Checkmk als „in Wartung“ markiert. Wobei auch hier der aktuelle Zustand der Objekte generell keine Rolle spielt.

Knapper formuliert ist die genaue Regel wie folgt:

Wenn ein CRIT-Status eines Hosts/Services zu einem CRIT-Status der Aggregation führen würde, führt ein „in Wartung“-Status dieses Hosts/Services zu einem „in Wartung“-Status der Aggregation.

Wichtig: der wirkliche aktuelle Status der Hosts/Services spielt bei der Berechnung keine Rolle - was in Wartung ist, wird in der BI-Logik als CRIT angenommen. Warum? Weil ein UP- oder OK-Status während einer Wartungszeit reiner Zufall ist, etwa, wenn ein Host zwischen mehreren Neustarts zwischenzeitlich für wenige Sekunden UP meldet.

Und hier haben wir jetzt noch ein Beispiel: Um Platz zu sparen ist dies eine Variante mit nur einem Mystery-Server anstelle von zweien:

Hier ist zunächst der Host switch-1 in Wartung. Für den Knoten Infrastructure hat das aber keine Auswirkung. Denn switch-2 ist ja nicht in Wartung. Also ist Infrastructure auch nicht in Wartung. Dort fehlt das Symbol für abgeleitete Wartungszeiten.

Aber: Auch der Service Memory auf srv-mys-1 ist in Wartung. Dieser ist nicht redundant. Die Wartung vererbt sich daher auf den Vaterknoten Mystery Server 1, dann weiter auf Mystery Servers und schließlich auf den obersten Knoten The Mystery Application. Also ist dieser auch in Wartung.

Haben wir oben geschrieben, dass Sie ein BI-Aggregat nicht manuell in eine Wartungszeit versetzen können? Das stimmt eigentlich nur halb. Denn Sie werden in der Tat bei BI-Aggregaten ein Kommando zum Setzen von Wartungszeiten finden. Aber das macht nichts anderes, als auf auf jeden einzelnen Host und Service des Aggregats eine Wartung einzutragen. Das führt dann natürlich in der Regel dazu, dass das Aggregat selbst auch als in Wartung gilt. Aber das ist nur indirekt.

Oben haben Sie gesehen, dass die Wartungszeitberechnung auf Basis eines angenommenen CRIT-Zustands läuft. In den Eigenschaften eines Aggregats können Sie den Algorithmus so anpassen, dass ein Knoten bereits bei einem angenommenen WARN-Zustand als in Wartung gilt. Die Option hierzu heißt Escalate downtimes based on aggregated WARN state:

Die Grundannahme, dass die in Wartung befindlichen Objekte CRIT sind, bleibt bestehen. Einen Unterschied gibt es nur dort, wo aufgrund der Aggregatsfunktion aus CRIT ein WARN werden kann — so wie das z. B. beim allerersten Beispiel mit Count the number of nodes in state OK der Fall war. Hier würde eine Wartungszeit bereits dann angenommen werden, wenn auch nur einer der beiden Switche in Wartung wäre.

Ganz ähnlich zu den Wartungszeiten wird auch die Information, ob ein Problem quittiert ist, von BI automatisch berechnet. Diesmal spielt der Zustand der Objekte durchaus eine Rolle.

Die Idee hier ist, folgendes Konzept auf BI zu übertragen: Ein Objekt hat ein Problem (WARN, CRIT). Aber das ist bekannt und jemand arbeitet daran ().

Sie können das für ein Aggregat wie folgt selbst berechnen:

Würde das Aggregat jedoch WARN oder CRIT bleiben, dann gilt es nicht als quittiert. Dann muss es noch mindestens ein weiteres wichtiges Problem geben, das selbst nicht quittiert ist und den OK-Status des Aggregats entfernt.

Übrigens wird Ihnen bei den Kommandos zu einem BI-Aggregat angeboten, dessen Probleme zu quittieren. Dies bedeutet aber nur, dass alle im Aggregat erfassten Hosts und Services quittiert werden (nur solche, die aktuell auch Probleme haben).

Kann man bei Statusänderungen in BI-Aggregaten eigentlich benachrichtigen? Nun — auf direktem Wege geht das erst mal nicht, denn BI ist ausschließlich in der GUI vorhanden und hat keinen Bezug zum eigentlichen Monitoring. Aber: Sie können aus BI-Aggregaten normale Services machen. Und diese können dann natürlich wieder Benachrichtigungen auslösen. Dazu gibt es zwei Möglichkeiten:

Den Anfang macht die Methode „Datenquellenprogramm“, denn diese ist immer dann gut, wenn Sie mehr als nur eine Handvoll Aggregate als Services erzeugen wollen. Dazu finden Sie unter Setup > Agents > Other integrations > BI Aggregations den passenden Regelsatz:

Hier können Sie sogar verschiedene Optionen angeben, zu welchen Hosts die Services hinzugefügt werden sollen. Sie müssen nicht zwingend an dem Host kleben, welcher das Datenquellenprogramm ausführt (Assign to the querying host). Möglich ist auch eine Zuordnung zu den Hosts, welche das Aggregat betrifft (Assign to the affected hosts). Das macht allerdings nur dann wirklich Sinn, wenn es sich dabei immer nur um einen Host handelt. Über reguläre Ausdrücke und Ersetzungen können Sie sogar noch flexibler zuordnen. Das Ganze geschieht dann über den Piggyback-Mechanismus.

Wichtig: Falls der Host, dem Sie diese Regel zuweisen, auch noch über den normalen Agenten überwacht werden soll, müssen Sie unbedingt in dessen Einstellungen dafür sorgen, dass Agent und Datenquellenprogramme ausgeführt werden:

Die Benachrichtigung mit einem aktiven Check ist quasi der direktere Weg und erfordert keinen künstlichen „Hilfs-Host“, welcher das Datenquellenprogramm ausführt. Da er jedes Aggregat einzeln abfragen muss, ist er aber bei einer größeren Menge von Aggregaten deutlich weniger performant und dann auch umständlicher aufzusetzen.

Das Ganze geht so: Es gibt einen aktiven Check, welcher per HTTP von der Web-API von Checkmk den Zustand von BI-Aggregaten abrufen kann. Diesen können Sie bequem mit dem Regelsatz Setup > Services > Other services > Check State of BI Aggregation einrichten:

Bitte beachten Sie hierbei Folgendes:

Im Beispiel ist Automatically track downtimes of aggregation aktiviert. Genau genommen sind damit die scheduled Downtimes gemeint, also die geplanten Wartungszeiten. Damit wird der neue aktive Service automatisch eine Wartungszeit bekommen, wenn auch das BI-Aggregat dies tut.

Der neue Service zeigt dann — natürlich mit einer Verzögerung von bis zu einem Check-Intervall — den Zustand des Aggregats. Im Beispiel liegt der BI-Check auf dem Host srv-mys-1:

Diesen Service können Sie dann wie gewohnt Kontakten zuordnen und ihn als Basis für Benachrichtigungen verwenden.