Die vierte Check_MK-Konferenz fand im Zeitraum vom 02.-04.05.2018 in München statt. Neben einem Ausblick auf die Firmenentwicklung und der Vorstellung des neuen Geschäftsführers gab es einen Ausblick auf Weiterentwicklungen im Check_MK-Projekt mit Details zu Plänen der Check_MK-Entwickler. Spannende Vorträge rund um das Thema IT-Monitoring rundeten die Konferenz ab. Die DECOIT^® war dabei.

Nach 10 Jahren mit Mathias Kettner an der Spitze entwickelt sich die Mathias Kettner GmbH personell weiter. Die Verantwortung über die betrieblichen Aufgaben übernimmt nun Jan Justus, der neue CEO der Mathias Kettner GmbH. Mathias Kettner selber gibt diesen Bereich ab und konzentriert sich als CTO weiter auf die technische Weiterentwicklung und Umsetzung seiner Visionen mit Check_MK. Der Wechsel in der Führung bringt einige Neuerungen mit sich. Prozesse sollen in den nächsten Monaten untersucht und gestrafft werden. Die Website soll komplett modernisiert werden, um dem Benutzer ein besseres Erlebnis bieten zu können. Auch das eher technisch gehaltene Benutzerinterface von Check_MK soll in der Version 1.6 modernisiert und für den Benutzer intuitiver werden.

Die Belegschaft der Mathias Kettner GmbH ist im letzten Jahr, wie erwartet, weiter gewachsen. Inzwischen sind 20 Personen am Check_MK-Projekt beteiligt. Ein ehrgeiziges Ziel für das Jahr 2018 ist die Erweiterung des Teams um weitere 10 Personen. Dieser personelle Zuwachs und die Straffung, vor allem im Bereich der Supportprozesse, sollen dem Kunden eine schnellere Reaktion auf Anfragen und Probleme ermöglichen. An dieser Stelle wurden die Kunden in den letzten Jahren mehr und mehr vertröstet. Von anfangs wenigen Stunden auf inzwischen Monate für eine individuelle Anpassung.

Check_MK hochverfügbar machen

Um eine Check_MK-Umgebung hochverfügbar zu machen, werden Aktiv-/Passiv-Cluster verwendet. Hierbei laufen zwei Server gleichzeitig und verwalten die Cluster-Dienste mittels Pacemaker. Die Überprüfung der Funktionalität des jeweils aktiven Master-Servers wird über Corosync Cluster Engine abgebildet. Für die Synchronisation der Daten zwischen den beiden Servern wird DRBD eingesetzt. Die hier vorgestellte Technologie wird auch in den Check_MK-Appliances verwendet, um einen Clusterbetrieb zu ermöglichen. Im Gegensatz zu der vorgestellten, manuellen Methode ist der Prozess und die Konfiguration in den Appliances bereits vorbereitet.

Die Empfehlung ist, dass bei Hochverfügbarkeitsanwendungen auf Virtualisierung oder Appliances gesetzt werden sollte. Hierbei muss aber auch immer die notwendige Verfügbarkeit des Dienstes betrachtet werden. Der Aufwand, einen Cluster einzusetzen, ist bei einer Verfügbarkeitsanforderung von unter 99,9 Prozent in der Regel nicht gerechtfertigt.

Skalierung großer verteilter Systeme

Die Skalierung großer verteilter Systeme wird stetig verbessert. 80 Sites pro Mastersite können zukünftig abgebildet werden. Darüber hinaus wird es möglich sein, den Status eines Slaves von einem Slave in der Mastersite abzubilden. Dieses wird besonders bei DMZ-Systemen eines entfernten Standorts eingesetzt werden können, bei denen der Monitoring Master nur Zugriff auf den Satelliten im Netz, aber nicht auf die DMZ hat. Die Funktion hat den Namen Cascading Livestatus. Leider ist ein Cascading Config Push aktuell noch nicht vorgesehen, die Konfiguration muss also an mehreren Stellen erfolgen.

Absichern von Check_MK

Ein für uns wichtiges Thema konnten wir auf der Konferenz klären: Wie kann SELinux auf einem System aktiviert bleiben, obwohl Check_MK installiert wird? Permissive Modus für die exakte Einstellung der Richtlinien funktioniert nur beschränkt, da das Monitoring sich stets weiterentwickelt und neue Funktionen und Checks hinzukommen. Das Check_MK-Team empfiehlt daher den Check_MK-Agenten und den OMD-Prozess als unconfined_t laufen zu lassen, so dass SELinux aktiviert bleiben kann, aber Check_MK bei der Ausführung nicht behindert wird. Dies bietet den Vorteil, alle anderen Prozesse einschränken zu können und damit signifikant mehr Sicherheit als das Deaktivieren von SELinux, was heute weitgehend als Standardvorgang verwendet wird. Außerdem sollte TLS in der Check_MK-Umgebung eingerichtet werden, da auch Daten zwischen Nutzer und Monitoring-System, wie z.B. Login-Daten, zu schützen sind.

Verbesserungen des Monitorings im Bereich dynamischer Umgebungen

Bei der Entwicklung des Check_MK-Projekts für die kommenden Versionen 1.5 und 1.6 liegt der Schwerpunkt auf der Entwicklung der Bereiche Container Management und Virtualisierung. Im Bereich dynamischer Umgebungen bietet Check_MK mit seiner eher statischen Konfiguration heute nur mit viel Aufwand in Form von zusätzlichen Scripten oder manueller Arbeit die Möglichkeit eines kompletten Monitorings. Der Schnelllebigkeit von Docker, Kubernettes, AWS oder anderen Orchestration Lösungen kommt check_MK aktuell nicht hinterher.

Mittels DCD, dem Dynamic Configuration Daemon soll check_MK schneller auf sich ändernde Umgebungen reagieren können. Plugins ermöglichen den Anschluss von Check_MK an die Orchestrierung der virtuellen Maschinen oder Container und die Konfiguration kann direkt anhand von Templates erstellt und aktiviert werden. Neu entstandene virtuelle Maschinen oder Container werden in das Monitoring aufgenommen.

Statische Graphen, zum Beispiel CPU-Auslastung, stellen heute den Verlauf eines Hosts oder eines Services da. Wird ein Service nun aber von einer stetig wechselnden Anzahl von zum Beispiel Docker-Containern abgebildet, so kann eine Aussage über den CPU-Verbrauch nur in Kombination mit allen CPU-Verbräuchen aller Docker-Container getroffen werden. Die einzelnen Graphen sind zu kurzlebig oder weisen Lücken auf, wenn der Container ausgeschaltet ist. Das Graphensystem wird derzeit dahingehend angepasst, Graphen von gleichartigen Services zusammenzufassen, auch wenn deren Hosts sich ändern. Statt von zehn Hosts die CPU Auslastung in zehn Graphen darzustellen wird ein Graph mit addierten Messwerten abgebildet.

Acivate Changes

Eine Funktion, auf die wir schon seit einiger Zeit warten, wird es trotz anderer Pläne leider noch nicht in die Version 1.6 schaffen. Activate Changes wird weiterhin nur alle Änderungen in WATO aktivieren können und ein Discard von Changes ist weiterhin nicht möglich. Zwar existiert ein Konzept für die Realisierung der Funktion „teilweises Aktivieren von Änderungen“, aber die Umsetzung hat sich als zu komplex herausgestellt. Wir hoffen, dass dieses Feature Einzug in eine der kommenden Versionen erhält.

Die dieses Jahr angekündigten personellen und prozessbezogenen Änderungen zeigen, dass Check_MK sich dem eigenen Wachstum und der steigenden Verbreitung der Lösung auch strukturell anpasst. Dies ist genau der richtige Schritt, um weiterem Wachstum mit gleichbleibender hoher Qualität und verlässlichem Support den Weg zu ebnen. Wir freuen uns auf weitere spannende Entwicklungen.

Sind Sie an dem Einsatz einer Monitoring-Lösung interessiert? Gern stellen wir Ihnen in einem Beratungsgespräch unterschiedliche Open-Source- und proprietäre Lösungen mit ihren Vor- und Nachteilen vor.