1. Einleitung
In einem regulären verteilten Monitoring mit einem zentralen Setup werden sich die Benutzer in der Regel auf der Zentralinstanz anmelden, um dort Konfigurationen vorzunehmen oder auf die Monitoring-Daten zuzugreifen. Die Benutzer können sich zwar zusätzlich auch auf den Remote-Instanzen anmelden, weil sie z.B. nur für die Hosts und Services zuständig sind, die von dort aus überwacht werden. Das Berechtigungskonzept von Checkmk, 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 Hosts und Services informiert sind, ist kein Problem.
In einem zentralen Setup wird Checkmk in der Standard Edition und Cloud 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 Remote-Instanzen zur Verfügung gestellt werden. Hosts und Services von Kontaktgruppen können über mehrere Instanzen verteilt sein.
Sobald Checkmk jedoch als Dienstleistung einem Dritten angeboten werden soll, dürfen bestimmte Konfigurationsdaten nur noch auf bestimmten Remote-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 ein Kunde zentral eine Konfiguration vornehmen kann — 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 
Checkmk Enterprise Managed Services Edition bindet ein Anbieter (= ein Provider) in seiner Zentralinstanz für jeden Kunden über das verteilte Monitoring eine oder mehrere lokale Instanzen ein, die nur diesem Kunden gehören.
Einzelne Elemente im Setup werden dann diesen Instanzen zugewiesen.
Checkmk wird jetzt bei der Verteilung der Konfigurationsdaten nur diese zu einer Kundeninstanz schicken, welche entweder allgemeiner Natur sind oder für diese Instanz freigegeben wurden.
Die Konfiguration kann von dem Dienstleister weiterhin bequem über das zentrale Setup seiner eigenen Instanz erfolgen.
Ebenso steht dem Dienstleister eine zentrale Weboberfläche für alle seine Kunden zur Verfügung, um dort mit den Monitoring-Daten arbeiten zu können.
Das funktioniert genauso, wie in einer normalen verteilten Umgebung auch, mit dem einzigen Unterschied, dass alle beteiligten Instanzen die Checkmk Enterprise Managed Services Edition verwenden müssen:
Die folgenden Elemente in Checkmk können einem Kunden zugewiesen werden:
Remote-Instanzen
Benutzer
LDAP-Verbindungen
Regeln und Regelpakete der Event Console
Zentral verwaltete Passwörter
Kontaktgruppen
Host- und Service-Gruppen
Globale Einstellungen von Remote-Instanzen
Dem Kunden steht also über die ihm zugeordnete Instanz nur seine eigenen Konfiguration mit den Host- und Servicedaten zur Verfügung. Er muss sich nur auf seiner eigenen Instanz anmelden 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 Lizenzierung auswählen,
sobald Sie mit Checkmk nicht nur Ihre eigene, sondern auch die Infrastruktur von anderen Unternehmen überwachen.
Selbst wenn Sie die erweiterte Funktionalität der Checkmk Enterprise Managed Services Edition nicht nutzen.
2. Konfigurationen
2.1. Kunden anlegen
Das Anlegen eines Ihrer Kunden erledigen Sie mit lediglich einem Schritt: Wählen Sie unter Setup > Users > Customers den Knopf Add Customer aus und vergeben Sie dort eine eindeutige ID, sowie den Namen, wie er in Checkmk angezeigt werden soll. Nach dem Speichern ist Ihr erster Kunde bereits in Checkmk 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 Checkmk mit diesem Kunden. Die Zentralinstanz, an die alle weiteren Instanzen der Kunden ihre Daten schicken, wird auch Provider-Instanz genannt. Die Trennung der Daten funktioniert 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ß Checkmk 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 Setup 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 Ordnern — 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. Die Nichtbeachtung dieser Hinweise kann ein moderates Sicherheitsrisiko darstellen.
Business Intelligence
Sie können BI-Aggregate keinem spezifischen Kunden zuordnen. Daher werden alle Aggregate und deren Regeln auf alle Instanzen übertragen. Die Benennung der Regeln, Pakete und Aggregate sollten aus diesem Grund so allgemein wie möglich gehalten werden, bzw. dürfen keine kundenspezifischen Bezeichnungen enthalten.
Host-Merkmale
Auch für Host-Merkmale (host tags) gilt, dass sie keine vertraulichen Informationen enthalten dürfen, da die Merkmale 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 Service-Namen, 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 globalen Benutzer daher eher für Ausnahmefälle und nicht für reguläre, alltägliche Aufgaben.
2.5. Zertifikatsmanagement
Die im vorhergehenden Kapitel erwähnten Punkte wie Benachrichtigungen mit Kontaktgruppen oder Host-Merkmale können lediglich Informationen über organisatorische Strukturen anderer Kunden offen legen.
Anders sieht es mit der Verteilung von CA („Certificate Authority“) Root-Zertifikaten aus: Würde ein für Kunde A bestimmtes CA-Zertifikat zu Kunde B verteilt werden, bestünde die Gefahr, dass ein böswilliger Administrator bei Kunde A einen Man in the Middle Angriff auf die verschlüsselte Kommunikation bei Kunde B durchführen kann. Aus diesem Grund werden mit der globalen Einstellung Trusted certificate authorities for SSL hinterlegte CA-Zertifikate nicht zu den Remote-Instanzen übertragen.
Der richtige Weg zur Konfiguration von kundenspezifischen CA-Zertifikaten ist es, sie in den instanzspezifischen globalen Einstellungen der Remote-Instanzen des Kunden einzutragen.
3. Erweiterte GUI
3.1. Dashboard
Neu auf dem Main dashboard ist das Dashlet Customers, welches sich links der Service-Probleme befindet:
Bei Auswahl eines Kunden gelangen Sie in eine Übersicht, in der alle seine Hosts gelistet sind. Diese Ansicht funktioniert also wie die Ansicht All hosts — mit dem Unterschied, dass hier nur die Elemente eines bestimmten Kunden angezeigt werden.
3.2. Seitenleiste
Das Snapin Customers der Seitenleiste 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. Ansichten filtern und bauen
Selbstverständlich können Sie die Filter und Datensätze, so wie sie für das Dashlet und das Snapin 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
4.1. Einleitung
Bei dem Upgrade einer bestehenden Umgebung von der Standard Edition auf die Managed Services Edition, gibt es einige Besonderheiten zu beachten. Wenn Sie nur eine einzelne Instanz umstellen möchten, ist der Umstieg sehr einfach: Sie führen 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 Umgebung für die Managed Services aufbauen.
Wenn Sie eine bestehende Umgebung umstellen möchten, bei der Sie bereits Remote-Instanzen bei einem Kunden eingerichtet haben, sind wenige Details mehr zu beachten.
4.2. Reihenfolge der Updates der einzelnen Instanzen
Nach dem Update stehen Ihnen alle Funktionen zur Verfügung, um Kunden anzulegen und diesen Instanzen, Benutzer, usw. zuzuordnen. Diese werden zwar, wie bereits beschrieben, dem Provider zugeordnet. In einem bestehenden verteilten Monitoring 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 Remote-Instanzen.
Updaten Sie zuletzt die Zentralinstanz.
Aktivieren Sie während des gesamten Update-Vorgangs zur Sicherheit keine Änderungen.
Um die Änderungen komplett zu unterbinden, können Sie diese im Setup für den Zeitraum der Updates sperren. Sie gelangen zu der Konfiguration über Setup > General > Read only mode:
Übrigens werden auch bei dem Update in einer verteilten Umgebung alle kompatiblen Komponenten in Checkmk dem Provider zugeordnet.
4.3. 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 Checkmk 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.