Managed Services Edition

Check_MK Manual
Letzte Aktualisierung: 26. Juni 2018

Suche im Handbuch

1. Einführung

In einem regulären verteilten Monitoring mit einem zentralen WATO werden sich die Benutzer in der Regel auf der zentralen Master Instanz einloggen, um dort Konfigurationen vorzunehmen oder auf die Monitoringdaten zuzugreifen. Die Benutzer können sich zwar zusätzlich auch auf den Slave-Instanzen einloggen, weil sie z. B. nur für die Hosts und Services zuständig sind, die von dort aus überwacht werden. Das Berechtigungskonzept von Check_MK, die Sichtbar- und Konfigurierbarkeit von Hosts und Services mittels Rollen und Kontaktgruppen einzuschränken, ist jedoch für beide Szenarien vollkommen ausreichend. Benutzer mit sehr eingeschränkten Berechtigungen werden in aller Regel keinen direkten Kommandozeilenzugriff auf den Monitoring-Server bekommen und können daher auch nur die Daten sehen, für die sie zuständig sind. Dass sie dabei eventuell über die Existenz von anderen Host- und Services informiert sind, ist kein Problem.

In einem zentralen WATO wird Check_MK in der  Check_MK Enterprise Edition daher alle Konfigurationsdaten an alle beteiligten Instanzen verteilen, da sie prinzipiell auch überall liegen könnten, bzw. benötigt werden. Zentral verwaltete Passwörter müssen auch für die Slave-Instanzen zur Verfügung gestellt werden, Host und Services von Kontaktgruppen können über mehrere Instanzen verteilt sein.

Sobald Check_MK jedoch als Dienstleistung einem Dritten angeboten werden soll, dürfen bestimmte Konfigurationsdaten nur noch auf bestimmten Slave-Instanzen verteilt werden. Das heißt, sensible Daten eines Kunden dürfen nicht auf dem Server eines anderen Kunden liegen – eine reine Einschränkung der Sichtbarkeit in der Weboberfläche ist daher nicht mehr ausreichend. Schließlich kann es sein, dass der lokale Monitoring-Server von dem Kunden selbst betrieben wird, oder er anderweitig über direkten Zugang zu der Kommandozeile des Servers verfügt.

Zusätzlich ist es nicht mehr erforderlich, dass diese Kunden zentral eine Konfiguration vornehmen können – der Sinn einer Dienstleistung ist es ja gerade, diesem Kunden solche Arbeiten zu ersparen. Auch benötigt er keine zentrale Ansicht, da er nur auf seine eigenen Daten Zugriff benötigt.

Mit der  Check_MK Managed Services Edition bindet ein Anbieter (= ein Provider) in seine zentrale Instanz für jeden Kunden über das verteilte Monitoring eine oder mehrere lokale Instanzen ein, die nur diesem Kunden gehören. Einzelne Elemente im WATO werden dann diesen Instanzen zugewiesen. Check_MK wird jetzt bei der Verteilung der Konfigurationsdaten nur diese zu einer Kunden-Instanz schicken, welche entweder allgemeiner Natur sind, oder für diese Instanz freigegeben wurden. Die Konfiguration kann von dem Dienstleister weiterhin bequem über das zentrale WATO seiner eigenen Instanz erfolgen. Ebenso steht dem Dienstleister eine zentrale Weboberfläche für alle seine Kunden zur Verfügung, um dort mit den Monitoringdaten arbeiten zu können. Das funktioniert genauso, wie in einer normalen verteilten Umgebung auch:

Die folgenden Elemente in Check_MK können einem Kunden zugewiesen werden:

  • Slave-Instanzen
  • Benutzer
  • LDAP Verbindungen
  • Regeln und Regelpakete der Event Console
  • Zentral verwaltete Passwörter
  • Kontaktgruppe
  • Host- und Servicegruppen
  • Globale Einstellungen von Slave-Instanzen

Dem Kunden stehen also über die ihm zugeordnete Instanz nur seine eigenen Konfigurations- Host- und Servicedaten zur Verfügung. Er muss sich nur auf seiner eigenen Instanz einloggen und bekommt daher auch nur seine Daten. Ein Login auf dem zentralen Server des Dienstleisters ist nicht erforderlich – und auch nicht möglich!

Wichtig: Sie müssen die Option Managed Services bei der Lizensierung auswählen, sobald Sie mit Check_MK nicht nur Ihre eigene, sondern auch die Infrastruktur von anderen Unternehmen überwachen. Selbst wenn Sie die erweiterte Funktionalität der  Check_MK Managed Services Edition nicht nutzen.

2. Konfigurationen

2.1. Kunden anlegen

Das Anlegen eines Ihrer Kunden erledigen Sie mit lediglich einem einzigen Schritt: Wählen Sie unter WATO ➳ Customers den Knopf New Customer aus und vergeben Sie dort eine eindeutige ID, sowie den Namen, wie er in Check_MK angezeigt werden soll. Nach dem Speichern ist Ihr erster Kunde bereits in Check_MK angelegt.

Wie Sie sehen können, wird der Dienstleister ebenfalls wie ein Kunde behandelt und ist aus diesem Grund als Provider bereits angelegt. Sie können diese Zuweisung nicht löschen.

2.2. Instanzen zuweisen

Nachdem Sie einen Kunden angelegt haben, verknüpfen Sie als nächstes die entsprechenden Komponenten in Check_MK mit diesem Kunden. Die Masterinstanz, an die alle weiteren Instanzen der Kunden ihre Daten schicken wird auch Provider-Instanz genannt. Im Moment funktioniert die Trennung der Daten nur, wenn Sie für jeden Kunden eine eigene Instanz anlegen und diese mit ihrer Provider-Instanz verbinden. Die Einrichtung unterscheidet sich in diesem Fall an einer einzigen Stelle: Sie geben in den Basic settings zusätzlich zu der ID und dem Alias noch den Customer an, welchen Sie zuvor angelegt haben.

Dadurch, dass auch der Provider als Kunde behandelt wird, weiß Check_MK anhand der Zuweisung zu einer Instanz immer, welcher Host zu welchem Kunden gehört.

Hinweis: Die Global Settings einer Kundeninstanz können Sie wie gewohnt über die instanzspezifischen globalen Einstellungen konfigurieren.

2.3. Weitere Zuordnungen

Neben der Instanz selbst können Sie – wie bereits in der Einleitung erwähnt – auch Elemente anderer Komponenten aus dem WATO einem Kunden zuzuweisen. Dabei wird ein Element einem Kunden direkt zugewiesen. Alternativ können Sie es aber auch global allen zur Verfügung stellen. Hier an dem Beispiel eines Benutzers:

Die Zuweisung erfolgt dabei immer über die Eigenschaften des jeweiligen Elements über die Option Customer. Ausgenommen davon sind die instanzspezifischen globalen Einstellungen.

Besonderheiten bei der Event Console

In der Event Console können Sie sowohl einzelne Regeln, als auch ganze Regelpakete einem Kunden zuordnen. Dabei gilt es zu beachten, dass die Vererbung bei Regelpaketen immer zwingend erfolgt. Sie kann also – anders, als bei Host-Verzeichnissen – nicht von den einzelnen Regeln wieder überschrieben werden. Auf diese Weise können Sie sich immer darauf verlassen, dass die Zuordnung bei jeder Regel gewährleistet ist.

Ist ein Regelpaket keinem Kunden zugeordnet, können Sie auch die einzelnen Regeln jeweils einem Kunden zuordnen.

2.4. Nicht anpassbare Komponenten

Alle Komponenten, welche im vorherigen Kapitel nicht genannt wurden, können einzelnen Kunden nicht zugewiesen werden. Dennoch gibt es ein paar Worte zu verschiedenen Komponenten zu verlieren, um auf Besonderheiten aufmerksam zu machen.

Business Intelligence

Sie können BI-Aggregationen keinem spezifischen Kunden zuordnen. Daher werden alle Aggregationen und deren Regeln auf alle Instanzen übertragen. Die Benennung der Regeln, Pakete und Aggregationen sollten aus diesem Grund so allgemein wie möglich gehalten werden, bzw. dürfen keine kundenspezifischen Bezeichnungen enthalten.

In einer späteren Version von Check_MK wird es eventuell möglich sein, auch BI-Aggregationen einem Kunden zuzuweisen. Die Dokumentation wird dann entsprechend angepasst.

Host Tags

Auch für Host Tags gilt, dass sie keine vertraulichen Informationen enthalten dürfen, da die Tags an alle Instanzen verteilt werden.

Benachrichtigungen

Regeln zu Benachrichtigungen enthalten oft Kontaktgruppen und sehr spezifische Bedingungen, unter denen die Benachrichtigung ausgelöst und verschickt werden soll. Da auch diese Regeln an alle Instanzen verteilt werden, verzichten Sie hier insbesondere auf explizite Host- und Servicenamen, Kontaktadressen und andere sensible Daten.

Anpassungen bei globalen Benutzern

Beachten Sie, dass alle Anpassungen, welche bei einem globalen Benutzer vorgenommen werden, auf alle Instanzen der Kunden übertragen werden. Globale Benutzer eignen sich daher nicht für spezielle Ansichten, eigene Graphen oder Lesezeichen, da diese sensible, kundenspezifische Daten enthalten können. Nutzen Sie die globale Benutzer daher eher für Ausnahmefälle und nicht als regulären für tägliche Arbeiten.

3. Erweiterte Ansichten

3.1. Dashboard

Neu auf dem Dashboard Main Overview ist die Spalte Customers, welche sich links der Service Probleme befindet:

Bei Auswahl eines Kunden, gelangen Sie in eine Übersicht, in der alle seine Hosts gelistet sind. Die Ansicht funktioniert also wie die Ansicht {{All hosts}}. Mit dem Unterschied, dass hier nur die Elemente eines bestimmten Kunden anzeigt.

3.2. Snapin

Das neue Snapin Customers funktioniert genauso, wie das ähnlich aussehende Snapin Site Status. Sie können sich hier den Status der Instanzen der einzelnen Kunden ausgeben lassen und mit einem Klick auf den Status bestimmte Kunden aus der Ansicht aus- oder einblenden.

Im Unterschied zu dem Snapin Site Status blenden Sie über dieses Snapin mit einem Klick alle Instanzen eines Kunden auf einmal aus.

3.3. Eigene Ansichten bauen

Selbstverständlich können Sie die neuen Filter und Datensätze, so wie sie für das Snapin und das Dashboard verwendet werden, auch für die eigenen Ansichten benutzen. Zum einen ist dafür der Filter Site erweitert worden, um eine Ansicht anzupassen:

Zum anderen können Sie auch ganz neue Ansichten auf Basis eines oder aller Kunden bauen. Wählen Sie dazu als Datenquelle All customers aus:

4. Tipps zum Upgrade

Bei dem Upgrade einer bestehenden Umgebung von der  Check_MK Enterprise Edition auf die  Check_MK Managed Services Edition, gibt es einige Besonderheiten, die zu beachten sind. Wenn Sie nur eine einzelne Instanz umstellen möchten, ist der Umstieg sehr einfach: Sie führen einfach wie gewohnt ein Update der Instanz durch und haben danach bereits alles Wichtige erledigt. Alle Hosts, Benutzer und andere Einstellungen, die Sie bereits vorher vorgenommen haben, werden dem Customer Provider zugeordnet, so dass sich Ihr Monitoring zunächst wie vorher verhält. Sie können dann in Ruhe eine Managed-Services-Umgebung aufbauen.

Wenn Sie eine bestehende Umgebung umstellen möchten, bei der Sie bereits entfernte Instanzen bei einem Kunden eingerichtet haben, sind wenige Details mehr zu beachten:

Reihenfolge der Updates der einzelnen Instanzen

Nach dem Update stehen Ihnen alle Funktionen zur Verfügung, um Kunden anzulegen und diesem Instanzen, Benutzer, usw. zuzuordnen. Diese werden zwar wie bereits geschrieben dem Provider zugeordnet. In einer bestehenden Verteilten Umgebung bedeutet das aber auch, dass alle anderen Instanzen mit diesen Daten noch nichts anfangen können. Dadurch ergibt sich die folgende Reihenfolge für ein sicheres Update:

  • Updaten Sie zuerst alle Slave-Instanzen.
  • Updaten Sie zuletzt die Master-Instanz.
  • Aktivieren Sie während des gesamten Update-Vorgangs zur Sicherheit keine Änderungen.

Um die Änderungen komplett zu unterbinden, können Sie diese im WATO für den Zeitraum der Updates sperren. Sie aktivieren Sie diese Sperre in den WATO ➳ Global Settings mit dem Button :

Übrigens werden auch bei dem Update in einer verteilten Umgebung alle kompatiblen Komponenten in Check_MK dem Provider zugeordnet.

Zuordnung der Kunden

Nach dem Update können Sie die Instanzen den Kunden zuordnen. Achten Sie dabei auf mögliche Abhängigkeiten, die sich aus der bereits bestehenden Konfiguration ergeben können und ordnen Sie auch die richtigen Elemente aus den anderen Komponenten in Check_MK entsprechend dem Kunden zu, bevor Sie die Zuordnung zu einer Instanz aktivieren.

Wichtig: Mindestens ein Benutzer muss an die Instanz eines Kunden übertragen werden. Dabei ist es egal, ob es sich um einen globalen Benutzer handelt, der an alle Instanzen repliziert wird, oder ob es sich um einen kundenspezifischen Benutzer handelt.