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 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 Einzelzuständen ein Gesamtzustand aggregiert wird.

Eine Aggregation ist ein Baum von Objekten, welche Knoten genannt werden. Die untersten Konten – 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 -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.

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 anderen BI-Regel auswählen. Oder es sind physische Monitoringobjekte – nämlich Hosts oder Services.

Für unser erstes Beispiel legen wir 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 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 Aggregations.

Der Knopf New Aggregation bringt uns 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 Hashtägs oder Schlagworte.

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 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 wo einer der beiden Switches DOWN ist und der andere UP. Wie von uns gewollt geht das Aggregat dabei in den Zustand Warning ():

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ättern des Baumes zeigen die Zustände von Hosts und Services. Der Hostname und – bei Services auch der Servicename – sind anklickbar und führt Sie um 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. Auch das eignet sich 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. Durch mehrfache Klicks gelangen Sie von (OK) über (WARN), (CRIT) und (UNKNOWN) wieder zu .

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. Denn das ist natürlich keineswegs immer der Fall.

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 einer Wartungszeit.

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, die sich vor allem in einem Testsystem anbietet. Dazu setzen Sie Hosts und Services tatsächlich in einem anderen Zustand. Dazu gibt es Host-/Servicekommando mit dem Namen Fake Check Results. Es ist per Default nur in der Roll 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 Master Control.

3.5. Gruppen

Beim Anlegen des Aggregats haben wir die Eingabemöglichkeit der Aggregation Groups kurz angesprochen. In unserem Beispiel hatten wir hier Main eingetragen, bzw. einfach den Vorschlag so 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 Aggregate 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.

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 uns natürlich nicht zufriedengeben.

Beginnen wir damit, dass wir den Baum um eine Ebene erweitern - also von zwei (Wurzel und Blätter) auf drei (Wurzel, Zwischenebene, Blätter). 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:

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ähren 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):

4.2. Alternative Baumdarstellungen

Der neue komplexere Baum gibt uns die Gelegenheit, uns etwas intensiver mit den Darstellung von BI in der Statusoberfläche zu befassen.

.

5. Konfiguration mit Variablen, Schablonen und Suche

5.1. Konfiguration mit mehr Intelligenz

Bisher war das Beispiel so einfach, dass es ohne Schwierigkeit möglich war, die Objekte in der Aggregation alles 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 eine größere Zahl von Instanzen gibt? Oder wenn sie mal eben 50-100 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.

5.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 und 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.

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.

Präfix-Match ist für Servicenamen Default

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:

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:

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

Sehen wir uns die Sache mit den regulären Ausdrücken etwas näher an. Beim Matching der Servicenamen habe ich nämlich am Anfang stillschweigend unterschlagen, dass es sich um eben diese 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 gilt generell folgende Prinzipien:

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

Vielleicht klingt das für Sie erstmal etwas verwegen. Mit der Zeit werden Sie aber feststellen, wie praktisch das ist, weil Sie dadurch „intelligente“ Regeln schreiben können, 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 ü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.

5.4. Flexible Auswahl von Hosts

COMMENT[Jetzt das mit den Hosttags erklären und auch in Screenshots zeigen. Kann man hier eigentlich auch mit Regexen arbeiten?].

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

5.5. Aggregate anhand gefundener Hosts und Services anlegen

.

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

6.1. Wartungszeiten

6.2. Quittierungen von Problemen

7. BI im verteilten Monitoring

8. Verfügbarkeit von BI-Aggregaten

9. Alarmierung