1. Einleitung
Checkmk ist in verschiedenen Editionen verfügbar, die sich im Leistungsumfang und in den Einsatzmöglichkeiten unterscheiden.
Im Folgenden möchten wir Ihnen mit der 
Checkmk Enterprise Managed Services Edition eine der kommerziellen Editionen vorstellen.
In einem verteilten Monitoring mit verteiltem 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 verteilten Setup wird Checkmk in der Raw Edition, 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. So müssen zum Beispiel zentral verwaltete Passwörter auch für die Remote-Instanzen zur Verfügung gestellt werden und Hosts/Services von Kontaktgruppen können über mehrere Instanzen verteilt sein.
Sobald Checkmk jedoch als Dienstleistung einem Dritten (das heißt einem Kunden) 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 seine Instanz konfigurieren 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 Dienstleister (das heißt ein Managed Service Provider, kurz MSP oder Provider) in seiner Zentralinstanz für jeden Kunden über das verteilte Monitoring eine oder mehrere Remote-Instanzen ein, die nur diesem Kunden gehören.
Einzelne Elemente im Setup werden dann diesem Kunden zugewiesen.
Checkmk wird jetzt bei der Verteilung der Konfigurationsdaten nur diese zu einer Kundeninstanz schicken, welche entweder allgemeiner Natur sind oder für diesen Kunden freigegeben wurden.
Die Konfiguration kann vom Provider weiterhin bequem über das verteilte Setup seiner eigenen Zentralinstanz erfolgen.
Ebenso steht dem Provider 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.
In der Managed Services Edition können Kunden wichtige Konfigurationsdaten (zum Beispiel Remote-Instanzen und Benutzer) zugewiesen werden. Dem Kunden steht also über die ihm zugeordnete Instanz nur seine eigene Konfiguration mit den Host- und Service-Daten zur Verfügung. Er muss sich nur auf seiner eigenen Instanz anmelden und bekommt daher auch nur seine Daten. Ein Login auf der Zentralinstanz des Providers ist nicht erforderlich — und auch nicht möglich!
Wichtig: Sie müssen die Checkmk Enterprise Managed Services Edition verwenden, wenn Sie mit Checkmk nicht nur Ihre eigene, sondern auch die Infrastruktur von anderen Unternehmen überwachen.
2. Einordnung der Managed Services Edition
Die Managed Services Edition ist die derzeit umfangreichste Edition von Checkmk.
Inhaltlich baut sie auf der 
Checkmk Cloud Edition auf und ist deren mandantenfähige Erweiterung.
Sie verfügt über alle notwendigen Funktionen, um mit Checkmk über das verteilte Monitoring voneinander abgeschottete Instanzen für mehrere Kunden zu betreiben.
Falls Sie als Provider Checkmk als Dienst für Ihre Kunden anbieten wollen, ist dies Ihre Edition.
3. Zusätzliche Funktionen der Managed Services Edition
Die wesentliche Funktion der Managed Services Edition, die diese von anderen Editionen unterscheidet, ist die Möglichkeit, folgende Elemente Kunden zuzuweisen:
Remote-Instanzen
Benutzer
LDAP-Verbindungen
Regeln und Regelpakete der Event Console
Passwörter im Passwortspeicher
Kontaktgruppen
BI-Aggregate
Globale Einstellungen von Remote-Instanzen
4. Upgrade zur Managed Services Edition
Für den Wechsel von einer der anderen Editionen zur Managed Services Edition folgen Sie der Upgrade-Beschreibung. Für das Upgrade zur Managed Services Edition kommt in verteilten Umgebungen nur das Offline-Upgrade in Frage.
Nach dem Upgrade sind alle kompatiblen Komponenten in Checkmk dem Provider zugeordnet. Ihnen stehen nun alle Funktionen zur Verfügung, um Kunden anzulegen und diesen Instanzen, Benutzer, usw. zuzuordnen.
Achten Sie dabei auf mögliche Abhängigkeiten, die sich aus einer 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.
Weitere Hinweise finden Sie im folgenden Kapitel.
5. Konfiguration
5.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 Provider ebenfalls wie ein Kunde behandelt und ist aus diesem Grund als Provider bereits angelegt. Sie können diese Zuweisung nicht löschen.
5.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.
 |
Die Global settings einer Kundeninstanz können Sie wie gewohnt über die instanzspezifischen globalen Einstellungen konfigurieren. |
5.3. Weitere Zuordnungen
Neben der Instanz selbst können Sie — wie bereits weiter oben erwähnt — auch andere Elemente aus dem Setup einem Kunden zuweisen. Dabei wird ein Element einem Kunden direkt zugewiesen. Alternativ können Sie einen Benutzer oder ein Passwort mit dem Eintrag Global aber auch allen zur Verfügung stellen. Hier am 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.
5.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.
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.
5.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 böswillige Mitarbeitende bei Kunde A einen Machine-in-the-Middle-Angriff auf die verschlüsselte Kommunikation bei Kunde B durchführen können. 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.
6. Unterschiede der Komponenten im Detail
6.1. Setup-Oberfläche
In Setup > Users > Customers können Sie auf eine Ansicht zur Verwaltung der Kunden zugreifen.
Bei der Einrichtung der Elemente, die Kunden zugewiesen werden können, wird ein zusätzliches Feld Customer angeboten.
Diese Funktionen werden exemplarisch im Kapitel zur Konfiguration beschrieben.
6.2. Monitoring-Oberfläche
Dashboard
Neu im Main dashboard ist das Dashlet Customers, welches sich links der Service-Probleme befindet:
Bei Auswahl eines Kunden gelangen Sie in eine Ansicht, in der alle seine Hosts gelistet sind. Diese Tabellenansicht funktioniert also wie die Ansicht All hosts — mit dem Unterschied, dass hier nur die Elemente eines bestimmten Kunden angezeigt werden.
Seitenleiste
Für die Seitenleiste gibt es in der Zentralinstanz das Snapin Customers, welches genauso funktioniert, 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.
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:
