BI - Business Intelligence

Check_MK Manual

Suche im Handbuch

Dieser Artikel ist noch nicht fertig und nur ein Entwurf!

1. Einleitung

Check_MK Business Intelligence - das klingt zugegeben etwas hochtrabend für eine im Grunde recht einfache Sache. Aber dieser Name trifft den Kern des BI-Moduls von Check_MK recht gut. Hier geht es nämlich darum, aus den vielen einzelnen Statuswerten den Gesamtzustand von geschäftskritischen Anwendungen abzuleiten und übersichtlich darzustellen.

Nehmen wir als Beispiel den Dienst Email, der in vielen Unternehmen noch immer unverzichtbar ist. Dieser Dienst basiert auf dem korrekten Funktionieren einer Vielzahl von Hardware- und Softwarekomponenten - angefangen bei bestimmten Switchen, über SMTP- und IMAP-Dienste bis hin zu Infrastrukturdiensten wie LDAP und DNS.

Der Ausfall eines essentiellen Bausteins ist kein Problem, wenn dieser redundant ausgelegt ist. Umgekehrt mag ein Problem bei einem ganz anderen Service, der auf den ersten Blick mit Email nichts zu tun hat, viel schwerwiegendere Auswirkungen haben. Ein einfacher Blick auf eine Liste von Services in Check_MK ist also nicht immer aussagekräftig - zumindest nicht für jeden!

Check_MK BI ermöglicht Ihnen, aus dem aktuellen Zustand von einzelnen Hosts und Services einen Gesamtzustand für eine Anwendung abzuleiten. Dazu definieren Sie über BI-Regeln, wie die Dinge baumartig voneinander abhängen. Jede Anwendung ist dann insgesamt OK, WARN oder CRIT. Die Information über den Zustand und die Abhängigkeiten können Sie auf verschiedene Weise nutzen:

  • Anzeige des Gesamtstatus einer Anwendung in der GUI
  • Berechnung der Verfügbarkeit einer Anwendung
  • Alarmierung bei einem Problem oder gar einem Ausfall einer Anwendung
  • Impactanalyse: Ein Service geht kritisch - welche Anwendungen sind davon betroffen?
  • Planung von Wartungszeiten und „Was wäre wenn...“-Analysen

Daneben gibt es noch die Möglichkeit, die Baumdarstellung von BI für eine „Drilldown“-Ansicht für den Zustand eines Hosts mit allen seinen Services zu verwenden.

Eine Besonderheit von Check_MK BI im Gegensatz zu vergleichbaren Tools im Monitoringumfeld ist, dass Check_MK auch hier regelbasiert arbeitet. Das ermöglicht Ihnen z. B. mit einem generischen Satz von Regeln dynamisch eine unbestimmte Zahl von ähnlichen Anwendungen zu beschreiben. Das erleichtert immens die Arbeit und hilft Fehler zu vermeiden - besonders in sehr dynamischen Umgebungen.

2. Schritt für Schritt

2.1. Begriffe

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

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

Eine Aggregation ist ein Baum von Objekten. Diese werden Knoten genannt. Die untersten Knoten – also die Blätter des Baumes – sind Hosts und Services aus Ihren Check_MK-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 Regel legt 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.

2.2. Ein Beispiel

Am einfachsten geht alles mit einem konkreten Beispiel. Dafür haben wir uns für diesen Artikel die „Mystery Application“ ausgedacht. Sagen wir, 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. Um Sie nicht unnötig zu verwirren, haben diese einfache Namen wie srv-mys-1 oder switch-1. Folgendes Schaubild gibt den Aufbau grob wieder:

  • Die beiden Server srv-mys-1 und srv-mys-2 bilden einen redundanten Cluster, auf welchem die eigentliche Anwendung läuft.
  • srv-db ist ein Datenbankserver, welcher die Daten der Anwendung speichert.
  • switch-1 und switch-2 sind zwei redundante Router, welche das Servernetz mit einem höhere Netz verbinden.
  • In jenem befindet sich ein Zeitgeber srv-ntp, welcher für eine exakt synchrone Zeit sorgt.
  • Außerdem ist dort der Server srv-spool, welcher die von der Mystery Application berechneten Resultate in ein Spoolverzeichnis befördert.
  • Von dort werden die Daten von einen mysteriösen übergeordneten Dienst abgeholt.

Die Hosts im sehen im Monitoring etwa so aus:

2.3. Unsere erste BI-Regel

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

Legen wir los: BI konfigurieren Sie über das WATO-Modul {{Business Intelligence}}. Die Konfiguration der Regeln und Aggregationen geschieht innerhalb von Konfigurations­paketen: den BI Packs. Die Pakete sind nicht nur deswegen praktisch, weil Sie komplexere Konfigurationen damit besser verwalten können. Auch können Sie auf einem Paket Berechtigungen für bestimmte Kontaktgruppen vergeben und somit auch Benutzern ohne Adminrechte ein Editieren von Teilen der Konfiguration erlauben. Doch dazu später mehr...

Wenn Sie die das BI-Modul zum ersten mal aufrufen, dann sieht das etwa so aus:

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

Für unser Beispiel legen wir am besten ein neues Paket an (Knopf New BI Pack), welches wir Mystery nennen. Wie immer in Check_MK vergeben wir 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 wir unsere Experimente erstmal in Ruhe alleine durchführen wollen, lassen wir das deaktiviert:

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

Bei jedem Eintrag ist ein Symbol zum Editieren der Eigen­schaften () und eins, um zum eigentlichen Inhalt des Pakets zu kommen (). Dort angelangt legen wir gleich unsere erste Regel an.

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

Der nächste 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 physische Monitoringobjekte – nämlich Hosts oder Services.

Für unser erstes Beispiel wählen wir die zweite Variante und legen jetzt 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 wir dann logischerweise State of a host und tragen jeweils den Namen des Hosts ein:

Im dritten und letzten Kasten gegen 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 Worst – takes worst of all node states. Das würde bedeuten, dass der Knoten CRIT wird, sobald auch nur einer der Unterknoten CRIT bzw. DOWN ist. Wie oben erwähnt wollen wir das aber nicht. Wir wählen stattdessen Count the number of nodes in state OK. Hier werden als Schwellwerte die beiden Zahlen 2 und 1 vorgeschlagen. Das ist prima, denn es ist genau was wir brauchen:

  • Wenn beide Switche UP sind (das wird hier als OK gewertet), soll der Knoten OK werden.
  • Wenn nur ein Switch UP ist, wird es WARN
  • Und wenn beide DOWN sind, bekommen wir ein CRIT

Und so sieht die Maske ausgefüllt aus:

Ein Klick auf Create und schon haben wir unsere erste Regel:

2.4. Unsere erste Aggregation

Nun ist es wichtig, dass Sie verstehen, dass eine Regel noch keine Aggregation ist. Check_MK 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 wir in die Liste der Aggregationen.

Der Knopf New Aggregation bringt uns zu einer Maske zum Anlegen einer neuen Aggregation. Hier gibt es erstmal wenig auszufüllen. 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 diese Gruppen genannt haben. Das ist eigentlich das gleiche Konzept wie Hashtags oder Schlagworten.

Wichtig ist jedoch, dass Sie bei Rule to call die Einstellung auf Call a rule lassen und bei Rule: jetzt die Regel auswählen, die wir gerade angelegt haben (und davor das Regelpaket, in dem diese sich befindet).

Wenn Sie die Aggregation jetzt mit Create erzeugen, 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!

3. Das Aggregat in der Statusoberfläche (Teil 1)

3.1. Alle Aggregate anzeigen

Wenn Sie alles richtig gemacht haben, dann können Sie jetzt ihr erstes Aggregat über die Statusoberfläche aufrufen. Das geht am einfachsten über das Views-Element in der Seitenleiste und dort mit dem Eintrag Business Intelligence ➳ All Aggregations:

3.2. Mit dem Baum arbeiten

Sehen wir uns die Darstellung des BI-Baumes etwas näher an. Folgendes Beispiel zeigt unser Mini-Aggregat in einer Situation, in der einer der beiden Switches DOWN ist und der andere UP. Wie von uns 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.

Mit dem schwarzen Dreieck klappen Sie Unterbäume auf und zu.

Die Blätter des Baumes 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 Objektes. Außerdem sehen Sie die letzte Ausgabe des Checkplugins.

Ganz links neben jedem Aggregat finden Sie zwei Symbole: und . Mit dem ersten – – 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. Damit werden wir uns später befassen.

3.3. BI ausprobieren: Was wäre wenn?

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 durch. Folgende Abbildung zeigt unser 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.

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

  • Testen, ob das BI-Aggregat so reagiert, wie Sie das wollen.
  • Planung der Abschaltung einer Komponente aus Gründen der Wartung.

Bei letzterem 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.

3.4. Bi ausprobieren durch gefakte Zustände

Es gibt noch eine zweite Möglichkeit, die BI-Aggregate zu testen: nämlich 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 habe ich 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, so 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 Seitenleisten­element Master Control. Bitte vergessen Sie nie, das später wieder zu aktivieren!

3.5. BI-Gruppen

Beim Anlegen des Aggregats haben wir die Eingabemöglichkeit der Aggregation Groups kurz angesprochen. In unserem Beispiel hatten wir 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 Aggregates auf die angezeigten Namen der Gruppen klicken – also in unserem obigen Beispiel einfach auf die Überschrift Main. Wenn Sie bisher nur dieses eine einzige Aggregat haben, ändert sich natürlich nicht viel. Nur wenn man genau hinsieht merkt man:

  • Der Titel der Seite heißt jetzt Aggregation group Main.
  • Die Gruppenüberschrift Main ist verschwunden.

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

3.6. Vom Host/Service zum Aggregat

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.

4. Schritt für Schritt zum komplexeren Aggregat

4.1. Ein Mehrstufiger Baum

Nach diesem ersten kurzen Eindruck der BI-Statusoberfläche kehren wir zurück zur Konfiguration. Denn mit unserem Miniaggregat können wir natürlich noch niemanden wirklich beeindrucken.

Beginnen wir damit, dass wir den Baum um eine Ebene erweitern - also von zwei Ebenen (Wurzel und Blätter) auf drei Ebenen (Wurzel, Zwischenebene, Blätter) gehen. Dazu kombinieren wir unseren vorhandenen Knoten „Switches 1 & 2“ mit dem Zustand der NTP-Zeitsynchronisation zu einem Oberknoten „Infrastructure“. Das Ergebnis soll dann so aussehen:

Dabei gehen wir davon aus, dass es einen Host srv-ntp gibt, der einen Service mit dem Namen NTP Time hat:

Jetzt legen wir eine BI-Regel an, welche als Unterknoten 1 die Regel „Switches 1 & 2“ bekommt und als Unterknoten 2 direkt den Service NTP Time des Hosts srv-ntp. Im Knopf der Regel wählen wir infrastructure als Regel-ID und Infrastructure als Name. Weitere Angaben sparen wir uns erstmal:

In der Child node generation wird es interessant. Unser erster Eintrag ist jetzt vom Typ Call a rule und als Regel wählen wir unsere Regel von oben aus. Damit „hängen“ wir diese quasi den Unterbaum hier ein.

Der zweite Unterknoten ist vom Type State of a service und hier wählen wir unseren NTP Time-Service aus (bitte beachten Sie hier die exakte Schreibung, inklusive der Groß-/Kleinbuchstaben):

Die Aggregation Function im dritten Kasten lassen wir diesmal auf Worst - take worst state of all nodes.

Damit der neue größere Baum sichtbar wird, müssen wir natürlich wieder eine Aggregation anlegen. Am besten machen Sie es so, dass Sie die bestehende einfach so ändern, dass jetzt die neue Regel verwendet wird:

Auf diese Art bleiben wir bei einer Aggregation. Und die sieht dann so aus (diesmal sind beide Switches wieder auf OK):

5. Das Aggregat in der Statusoberfläche (Teil 2)

5.1. Alternative Baumdarstellungen

Jetzt da wir einen etwas interessanteren Baum haben, können wir uns etwas genauer mit den verschiedenen Darstellungsmöglichkeiten befassen, die Check_MK bietet. Ausgangspunkt dafür sind die sogenannten Display options, welche Sie über das Symbol am oberen Rand jeder Statusansicht finden. Dies ö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 vier Optionen:

Bäume sofort auf- oder zuklappen

Wenn Sie nicht nur ein Aggregat sondern sehr viele anzeigen, dann ist die Einstellung Initial expansion of aggregations hilfreich. Hier legen Sie fest, wie weit die Bäume beim ersten Anzeigen aufgeklappt sein sollen. Die Auswahl reicht von geschlossen (collapsed) bis hin zu komplett geöffent (complete).

Nur Probleme zeigen

Wenn Sie die Option Show only problems aktivieren, werden in den Bäumen nur noch solche Zweige angezeigt, die nicht den Status OK haben. Das sieht dann z. B. so aus:

Art der Baumdarstellung

Unter dem Punkt Type of tree layout finden Sie etliche alternative Darstellungsarten für den Baum. Eine davon heißt Table: top down und sieht so aus:

Extrem platzsparend - vor allem wenn Sie viele Aggregate gleichzeitig sehen möchten - ist die Darstellung Boxes. Hier ist jeder Knoten ein farbiger Kasten, der durch Klick aufgeklappt wird. Die Baumstruktur ist nicht mehr sichtbar, aber Sie können sich so bei minimalem Platzverbrauch schnell zu einem Problem durchklicken. Hier im Beispiel sind die Boxen komplett aufgeklappt:

6. Konfiguration mit Variablen, Schablonen und Suche

6.1. Konfiguration mit mehr Intelligenz

Weiter geht's mit der Konfiguration. Und jetzt wird es Zeit, dass wir wirklich zur Sache kommen. 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 wir mächtigere Methoden der Konfiguration. Und die sind genau das, was Check_MK BI gegenüber anderen Tools auszeichnet – und leider auch die Lernkurve etwas steiler gestaltet. Es ist auch der Grund, warum Check_MK BI sich nicht per „Drag and Drop“ konfigurieren lässt. Aber wenn Sie die Möglichkeiten erstmal kennengelernt haben, werden Sie sie sicher nicht mehr missen wollen.

6.2. Parameter

Beginnen wir mit den Parametern. Nehmen wir folgende Situation: wir 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:

Wir wollen jetzt unseren Knoten Switch 1 & 2 so erweitern, dass wir anstelle der beiden Hostzustände für Switch 1 und 2 jeweils einen Unterknoten einführen, der den Hoststatus und die beiden Uplink-Interfaces zeigt. Diese beiden Unterknoten sollen Switch 1 bzw. Switch 2 heißen.

Eigentlich bräuchten wir jetzt also zwei neue Regeln - für jeden Switch eine. Besser geht das, indem wir nur eine Regel einsetzen, diese aber mit einem Parameter ausstatten. Dieser Parameter ist eine Variable, die man beim Aufruf der Regel mitgeben kann. In unserem Beispiel können wir einfach entweder eine 1 oder eine 2 übergeben. Der Parameter bekommt einen Namen, den Sie frei wählen können. Nehmen wir 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 Regel habe ich switch gewählt. Bei Parameter trage ich 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 im Check_MK üblich) vorne und hinten ein Dollarzeichen gesetzt. Als Ergebnis werden die beiden Knoten dann Switch 1 und Switch 2 heißen.

Präfix-Match ist für Servicenamen Default

Beim Child node generator fügen wir jetzt als erstes den Hostzustand ein. Dabei dürfen wir beim Hostnamen anstelle der 1 oder 2 einfach unsere Variable einsetzen und zwar auch hier wieder mit je einem $ hinten und vorne.

Das gleiche machen wir bei dem Hostnamen der Uplink-Interfaces. Und hier kommt gleich noch der zweite Trick. Denn wie Sie vielleicht an der kleinen Serviceliste oben bemerkt haben, heißen die Services für den Uplink bei beiden Switchen unterschiedlich! Das ist aber kein Problem, da BI den Servicenamen – ganz analog zu den bekannten Service-Regeln immer als Präfixmatch mit regulären Ausdrücken interpretiert. Wir schreiben also einfach Interface Uplink und erwischen so alle auf dem jeweiligen Host vorhandenen Services, die mit Interface Uplink beginnen:

Übrigens: Durch ein Anhängen von $ können Sie das mit dem Präfix abschalten. Ein $ bedeutet bei regulären Ausdrücken soviel wie „Der Text muss hier enden“. Also matcht Interface 1$ auch nur auf Interface 1 und nicht z. B. auch auf Interface 10!

Jetzt bauen wir noch die alte Regel Switch 1 & 2 so um, dass diese anstelle der Hostzustände die neue Regel für jeden der beiden Switche je einmal aufruft. Und hier ist jetzt auch die Stelle, bei der wir die Werte 1 und 2 als Parameter übergeben:

Und voila: schon haben wir einen hübschen Baum mit drei Ebenen:

6.3. Reguläre Ausdrücke und nicht vorhandene Objekte

Sehen wir uns die Sache mit den regulären Ausdrücken nochmal etwas näher an. Beim Matching der Servicenamen habe ich 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äfixmatch 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:

  1. Wenn sich ein Knoten auf Objekte bezieht, die es (aktuell) nicht gibt, dann werden diese einfach weggelassen.
  2. Wenn ein Knoten dadurch leer wird, wird er selbst weggelassen.
  3. Ist auch der Wurzelknoten eines Aggregats leer, wird das Aggregat selbst weggelasen.

Vielleicht klingt das für Sie erstmal etwas verwegen! Ist das 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 die 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.

6.4. Knoten als Ergebnis einer Suche anlegen

Wir wollen weiter automatisieren und vor allem flexibel auf Veränderungen reagieren können. Machen wir das am Beispiel der beiden Anwendungsserver srv-mys-1 und srv-mys-2 aus dem Beispiel. Unser Baum soll weiter wachsen. Der Knoten Infrastructure soll auf Ebene 2 rutschen und wir legen als Wurzel nun endgültig eine Regel mit dem Titel The Mystery Application, unter der alles hängen soll. Neben der Infrastructure wollen wir einen Knoten mit dem Namen Mystery Servers. Unter diesem sollen die (aktuell) zwei Mystery-Server hängen. Von jedem nehmen wir exemplarisch ein paar Services in das Aggregat mit auf. Das Ergebnis soll so aussehen:

Unterste Regel: Mystery Server X

Fangen wir von unten an. Denn das ist in BI immer der einfachste Weg. Unten gibt es die neue Regel Mystery Server .... Natürlich verwenden wir einen Parameter, damit wir nicht für jeden Server eine eigene Regel brauchen. Den Parameter nennen wir z. B. NUMBER. Er soll dann später als Wert 1 oder 2 haben. Also müssen wir NUMBER im Kopf der Regel bei Parameters eintragen.

Der Child-Node-Generator sieht dann so aus:

Hier ist folgendes bemerkenswert:

  • Beim Hostnamen srv-mys-$NUMBER$ haben wir die Nummer aus dem Paramter eingesetzt.
  • Bei Service: haben wir den raffinierten regulärer Ausdruck CPU|Memory eingesetzt, der mit einem senkrechten Balken alternative Servicenamen (-anfänge) zulässt und auf alle Services matcht, die mit CPU oder Memory beginnen. Das spart eine Verdoppelung der Konfiguration!

Übrigens: dieses Beispiel ist natürlich noch nicht unbedingt perfekt. z. B. haben wir den Status des Hosts selbst garnicht aufgenommen. Wenn also einer der Server DOWN geht, werden die Services auf diesem veralten (stale gehen), aber der Zustand wird OK bleiben und das Aggregat wird von dem Ausfall nichts „mitbekommen“. Wenn so etwas aber wissen möchten, sollten Sie neben den Services auf jeden Fall auch den Hoststatus aufnehmen!

Mittlere Regel: Mystery Servers

Diese Regel wird interessant. Sie fasst die beiden Mystery-Server zu einem Knoten zusammen. Aber wir wollen jetzt zulassen, dass die Anzahl der Server nicht festgelegt ist und durchaus später auch mal drei oder mehr sein kann. Oder es könnte gar sein, dass es dutzende Instanzen der Mystery-Anwendung gibt – jede mit einer anderen Anzahl von Servern!

Der Trick liegt im Child-Node-Generator-Typ Create nodes based on host search. Dieser sucht nach vorhandenen Hosts und erzeugt Knoten auf Basis der gefundenen Hosts. Er sieht hier so aus:

Das Ganze funktioniert so:

  1. Sie formulieren eine Suchbedingung, um Hosts zu finden.
  2. Für jeden gefundenen Host wird eine Child-Node angelegt.
  3. Dabei können Sie aus den gefundenen Hostnamen Teile herausschneiden und als Parameter bereitstellen.

Beginnen wir mit dem Finden. Hier stehen Ihnen wie üblich Hosttags zur Verfügung. In meinem Beispiel habe ich darauf verzichtet und stattdessen den regulären Ausdruck srv-mys-(.*) für den Hostnamen verwendet. Dieser matcht auf alle Hosts, die mit srv-mys- beginnen. Das .* steht für eine beliebige Zeichenfolge.

Wichtig ist hierbei, dass das .* eingeklammert ist, also (.*). Durch die Klammerung bildet der Match eine sogenannte Gruppe. In dieser wird genau der Text eingefangen, auf den das .* gematcht hat – also in unserem Fall 1 oder 2. Die Matchgruppen werden durchnummeriert. Wir haben hier nur eine, welche die Nummer 1 bekommt. Auf den gematchten Text können wir später daher mit $1$ zugreifen.

Unsere Suche wird also jetzt zwei Hosts finden:

Hostname Wert von $1$
srv-mys-1 1
srv-mys-2 2

Für jeden gefundenen Host erzeugen wir jetzt einen Unterknoten nach dem Prinzip Call a rule. Wir wählen die Regel Mystery Server $NUMBER$ aus, die wir gerade vorhin angelegt haben. Als Argument für das NUMBER übergeben wir jetzt die Matchgruppe: $1$

Jetzt wird also die Unterregel Mystery Server $NUMBER$ zweimal aufgerufen: einmal mit 1 und einmal mit 2.

Sollte in Zukunft mal ein neuer Server mit dem Namen srv-mys-3 ins Monitoring aufgenommen werden, so wird dieser automatisch im BI-Aggregat auftauchen! Der Zustand des Hosts ist dabei egal – unabhängig von dessen aktuellen Zustand. Also auch wenn der Server mal DOWN ist, wird er natürlich nicht aus dem Aggregat entfernt!

Ich gebe zu: wir haben hier eine sehr steile Lernkurve. Diese Methode ist wirklich komplex. Aber wenn Sie das erstmal ausprobiert und verstanden haben, werden Sie verstehen, wie mächtig das ganze Konzept ist. Und wir haben die Möglichkeiten gerade erst angekratzt!

Oberste Regel

Der Neue Toplevel-Knoten The Mystery Application ist jetzt einfach: Dazu ist eine neue Regel notwendig, die zwei Child Nodes der Art Call a rule hat. Diese beiden Regeln sind die bestehende Infrastructure und gerade neu angelegte Regel mit dem Namen Mystery Servers.

6.5. Knoten mit Servicesuche anlegen

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

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

  • Wählen Sie Regex for host name so müssen Sie genau einen Klammerausdruck definieren. Der Matchtext wird dann als $1$ bereitgestellt.
  • Wählen Sie All hosts so wird der Hostname komplett als $1$ bereitgestellt.
  • Im Servicenamen dürfen Sie mehrere Subgruppen verwenden. Die zugehörigen Matchtexte werden als $2$, $3$, usw. bereitgestellt.

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

6.6. Alle übrigen Services

Vielleicht sind Sie bei Ihren Versuchen über den Child-Generator State of remaining services gestolpert. Dies 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.

7. Die vordefinierte Hostaggregation

Wie eingangs erwähnt können Sie BI auch dazu verwenden, die Services eines Hosts strukturiert anzuzeigen. Dabei ordnen Sie alle Services in einem Baum zu einem Aggregat zusammen und verwenden grundsätzlich die Funktion worst. Der Gesamtstatus eines Hosts zeigt dann nur noch, ob es irgendein Problem bei dem Host gibt. Und Sie nutzen BI als übersichtliche „drill down“-Methode.

Für diesen Zweck liefert Check_MK bereits einen vordefinierten Satz von Regeln mit, welchen Sie einfach nur freischalten müssen. Diese Regeln sind auf die Darstellung von Services auf Windows- oder Linuxhosts optimiert, aber Sie können sie natürlich nach Ihren Wünschen anpassen. Sie finden alle im Regelpaket Default. Wie üblich gelanden Sie dort durch einen Klick auf zu dem Regeln:

Dort finden Sie eine Liste von zwölf Regeln (hier gekürzt):

Die erste Regel ist die Regel für die Wurzel des Baumes. Das Symbol bei dieser Regel bringt Sie zu einer Baumdarstellung. Hier können Sie sehen wie die Regeln untereinander verschachtelt sind:

Zurück in der Liste der Regeln gelangen Sie mit dem Knopf Aggregations zur Liste der Aggregationen in diesem Regelpaket – welche nur aus einer einzigen Aggregation besteht. Entfernen Sie in den Details einfach die Checkbox bei Currently disable this aggregation und sofort bekommen Sie pro Host eine Aggretation mit dem Titel Host myhost123. Diese sieht dann z. B. so aus:

8. Berechtigungen und Sichtbarkeit

8.1. Berechtigungen zum Editieren

Kehren wir nochmal zu den Regelpaketen zurück. Normalerweise benötigt man für alle Editieraktionen in BI die Rolle Adminstrator. Genauer gesagt gibt es für BI zwei Berechtigungen:

In der Rolle User ist per Default nur die erste der beiden 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 habe ich bei Permitted Contact Groups die Kontaktgruppe The Mystery Admins hinterlegt. Alle Mitglieder dieser Gruppe dürfen jetzt hier 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.

8.2. Berechtigungen auf Host und Services

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

Nun – auf BI-Aggregaten selbst können Sie keine Rechte vergeben. Das geschieht indirekt über die Sichtbarkeit der Host und Services und wird geregelt über die Berechtigung See all hosts and services unter der Rubrik BI – Check_MK Business Intelligence:

In der Rolle User ist dieses Recht per Default ausgeknipst. Normale Benutzer können nur ihre berechtigten Hosts und Services sehen. Und das drückt sich bei BI so aus, dass sie genau alle BI-Aggregationen sehen, welche mindestens einen berechtigten 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 Benutzer 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.

9. BI und Wartungszeiten

9.1. Die generelle Idee

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

  • Sie können ein BI-Aggregat nicht in eine Wartungszeit versetzen – müssen es aber auch nicht, denn...
  • Die Wartungszeit eines BI-Aggregats leitet sich automatisch von den Wartungszeiten seiner Host und Services ab.

Die Idee dahinter ist wie folgt: Wenn sich ein Service in einer Wartungszeit befindet, bedeutet das, dass dieser aktuell nicht zuverlässig verfügbar ist. Er kann CRIT sein, muss es aber nicht. Der Hinweis „In Wartung“ ist unabhängig vom aktuellen Status.

Wenn ein BI-Aggregat auf einem Service aufbaut, der in Wartung ist, bedeutet es aber nicht zwingend, dass dadurch dieses Aggregat auch in Wartung sein muss. Denn der Service könnte ja redundant sein und durch einen Cluster oder dergleichen abgesichert sein. Sie können leicht selbst ableiten, wann ihr BI-Aggregat in Wartung ist:

1. Nehmen Sie den schlimmsten Fall an: nämlich dass alle Hosts und Services die in Wartung sind, tatsächlich CRIT sind. 2. Nehmen Sie weiterhin an, dass alle anderen Objekte OK sind. 3. Wenn unter dieser Annahme das Aggregat CRIT ist, bekommt es selbst den Wartungszustand.

Umgangssprachlich könnte man es so ausdrücken: „Nehmen wir an, (genau) alles was in Wartung ist, ist auch wirklich kaputt. Ist das BI-Aggregat dann auch kaputt? Dann ist das halt auch in Wartung.“

Wichtig: für das Berechnen des Wartungsstatus ist der aktuelle Monitoringstatus irrelevant!

Und hier haben wir noch ein Beispiel. Um Platz zu sparen ist das hier 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 .

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 diese auch in Wartung.

9.2. Kommando Wartungszeit

Habe ich oben geschrieben, dass Sie ein BI-Aggregat nicht manuell in eine Wartungszeit versetzen können? Das stimm eigentlich nur so halb. Denn Sie werden in der Tat bei BI-Aggregaten ein Kommando zum Setzen von Wartungszeiten finden! Aber dies 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.

9.3. Tuningmöglichkeiten

Oben habe wir gesehen, dass die Wartungszeitberechnung auf Basis eines angenommenen CRIT-Zustands geht. In den Eigenschaften eines Aggregates 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 als CRIT angenommen werden bleibt. Einen Unterschied gibt es nur dort, wo aufgrund der Aggregatsfunktion aus CRIT ein WARN werden kann – so wie das z. B. bei unserem allerersten Beispiel mit Count the number of nodes in state OK der Fall war. Hier würde dann eine Wartungszeit bereits dann angenommen werden, wenn auch nur einer der beiden Switche in Wartung wäre.

10. BI und Quittierungen

Ä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 dran ().

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

  • Nehmen Sie an, dass alle Hosts und Services, die quittierte Probleme haben, wieder OK wären.
  • Würde das Aggregat dann selbst auch wieder OK? Genau dann gilt es ebenfalls als quittiert.

Denn würde das Aggretat jedoch WARN oder CRIT bleiben, dann gilt es nicht als quittiert. Denn dann muss es noch mindest ein weitere wichtiges Problem geben, dass selbst nicht quittiert ist und den OK-Status des Aggregats entfernt.

Übrigens wird Ihnen bei dem 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 Problem haben).

11. Verfügbarkeit

Genauso wie bei Hosts und Services können Sie auch bei BI die Verfügbarkeit eines oder mehrerer Aggregate für beliebige Zeiträume in der Vergangenheit berechnen lassen. Dazu rekonstruiert das BI-Modul anhand der Historie von Hosts und Services den Zustand des Aggregats für jeden Zeitpunkt in der Vergangenheit. Somit können Sie auch für solche Zeiträume Verfügbarkeiten berechnen, in denen das Aggregat noch garnicht konfiguriert war!

Alle Einzelheiten zu BI und Verfügbarkeit finden Sie im Artikel zur Verfügbarkeit im Abschnitt zu BI.

12. BI im verteilten Monitoring

Was geschieht eigentlich mit BI in einer verteilten Umgebung? Also wenn die Hosts über mehrere Monitoringserver verteilt sind?

Die Antwort relativ einfach: es funktioniert – und zwar ohne dass Sie etwas weiteres beachten müssten. Da BI eine Komponente der Benutzeroberfläche ist und diese von Haus aus eine verteilte Umgebung annimmt, ist dies für BI vollkommen transparent.

Sollte ein Standort aktuell nicht erreichbar sein oder Sie diesen manuell aus der GUI ausgeblendet haben, so sind die Hosts des Standortes für BI nicht mehr vorhanden. Das bedeutet dann:

  • BI-Aggregate, die ausschließlich aus Objekten dieses Standortes aufgebaut sind, verschwinden.
  • BI-Aggregate, die teilweise aus Objekten diese Standortes aufgebaut sind, werden ausgedünnt.

In letzterem Fall kann sich das natürlich auf den Status der betroffenen Aggregate auswirken. Wie genau, das hängt von ihren Aggregierungsfunktionen ab. Wenn Sie z. B. überall worst verwendet haben, kann der Status insgesamt nur gleich bleiben oder besser werden. Denn Objekte des nicht mehr vorhandenen Standortes könnten WARN oder CRIT gewesen sein. Bei anderen Aggregierungsfunktionen können sich natürlich andere Zustände ergeben.

Ob dieses Verhalten für Sie sinnvoll ist oder nicht, müssen Sie im Einzelfall beurteilen. BI ist auf jeden Fall so aufgebaut, dass nicht vorhandene Objekte auch nicht in einem Aggregat vorkommen können und auch nicht vermisst werden. Denn alle BI-Regeln arbeiten ja wie bereits oben erklärt ausschließlich mit Suchmustern.

13. Alarmierung, BI als Service

13.1. Alarmierung über einen aktiven Check

Kann man bei Statusänderungen in BI-Aggregaten eigentlich alarmieren? Nun – auf direktem Wege geht das erstmal 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 Alarme auslösen.

Dazu gibt es einen aktiven Check, welcher per HTTP von der Web-API von Check_MK den Zustand von BI-Aggregaten abrufen kann. Diesen können Sie bequem mit dem Regelsatz Host & Service Parameters ➳ Active checks ➳ Check State of BI Aggregation einrichten:

Bitte beachten Sie hierbei folgendes:

  • Aktivieren Sie diese Regel nur für einen einzigen Host. Bei diesem wird der aktive Check erscheinen.
  • Die URL muss diejenige sein, mittels der dieser Host auf die GUI von Check_MK zugreifen kann.
  • Der Benutzer muss ein Automationsuser sein. Nur solch einer darf die Web-API abrufen. Der Benutzer automation bietet sich an, da dieser immer automatisch für solche Zwecke angelegt wird.
  • Tragen Sie bei Passwort das Automation secret for machine accounts des Benutzers ein, welches Sie in der Konfigurationsmaske der Benutzereigenschaften finden.

In meinem Beispiel habe ich 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. In meinem Beispiel habe ich den BI-Check auf den Host srv-mys-1 gelegt:

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

13.2. Passive Checks mit Datasource-Program anlegen

Wenn Sie mehr als nur eine Handvoll Aggregate als Services erzeugen wollen, gibt es noch eine bequemere Methode: ein Datenquellenprogramm. Dazu finden Sie unter Datasource Programs ➳ Check state of BI Aggregations den passenden Regelsatz:

Hier können Sie sogar verschiedene Optionen angeben, zu welchem Host die Services hinzugefügt werden sollen. Diese 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 dem 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 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 Datenquellen­programme ausgeführt werden:

14. Performance

14.1. Single Host Aggregations

Zuguter Letzt noch ein paar Worte über das Thema Performance. Denn Performance ist immer wichtig. Check_MK hat schon viele Jahre harten Praxiseinsatz hinter sich und man glaubt garnicht, was unsere lieben Anwender alles so mit BI anstellen! Daher ist schon viel Zeit in die Optimierung der Performance geflossen, damit BI immer schnell antwortet und wenig CPU-Zeit verbraucht.

Gerade wenn Sie mit Host-Aggregationen arbeiten kann es aber ruck zuck passieren, dass Sie ein paar Tausend Aggregate haben. Damit BI dann immer noch schnell ist, ist es wichtig, dass Sie Aggregate, von denen Sie wissen, dass sie nur einen Host betreffen, also solche markieren.

Kreuzen Sie dazu in den Details der Aggregation die Checkbox Optimization ➳ The aggregation covers data from only one host and its parents an. BI tut sich dann wesentlich leichter bei der Suche nach den passenden Services.

14.2. Interner Ablauf

Falls Sie an eine Grenze stoßen, wo die Berechnungszeiten langsam spürbar werden, werden Sie das vor allem in der Zeit kurz nach einem Activate Changes feststellen. BI ist so aufgebaut, dass die Bäume in zwei Schritten berechnet werden.

  1. Die Struktur der Aggregate wird berechnet (wir nennen das Kompilieren).
  2. Der Status der Aggregate wird berechnet.

Der erste Schritt ist immer dann notwendig, wenn sich der die Menge an Hosts oder Services geändert hat. Und dies kann bekanntlich nur durch ein Active Changes passieren. Bei den Aggregationen, die als Single Host Aggregations markiert sind, wird der Komplierungsschritt hinausgezögert bis der betreffende Host aufgerufen wird. Darin besteht ein wichtiger Teil der Optimierung.

Der Status von Aggregaten wird natürlich immer wieder neu berechnet, sobald Sie sich ein Aggregat anzeigen lassen.