Dies ist der zweite Teil unseres Berichtes von der diesjährigen Check_MK Konferenz in München. In Teil eins, den ihr hier nochmal nachlesen könnt, sind Keyfacts zu Check_MK und dem Team, sowie bereits viele der im vergangenen Jahr entwickelten neuen Funktionen beschrieben. Dieser zweite Teil stellt alle restlichen neuen Möglichkeiten vor und gibt einen Ausblick darauf, an welchen Funktionalitäten das Check_MK Team momentan und in Zukunft arbeitet.

Password Store

Die Verwendung des neuen Password Stores soll verhindern, dass Zugangsdaten, die z. B. für Prüfungen benötigt werden (Beispiel Datenbankabfragen), in den Systemprozessen und dem Frontend von Check_MK im Klartext zu sehen sind.

Check_MK Appliances

Alle Appliances wurden überholt und haben ein hardware-seitiges Update erhalten. Zudem werden ab Firmware-Version 1.3 keine 32-Bit Varianten mehr vertrieben.

Die größte Ausführung soll dabei mit zwei 480 GB großen SSD Festplatten (später optional auch größer), insgesamt 24-CPU-Cores/48-Threads (zwei E5-2650v4 12-Core/24-Threads CPUs), 64 GB Arbeitsspeicher (ECC), 4 x 10Gbit LAN und redundanten Netzteilen als 2HE-Variante erscheinen. In Labortests(!) wurde dieses System mit 10.000 Hosts und 800.000 Services betrieben und verursachte dabei eine CPU-Load von 36 und eine Speicherauslastung von 31%. Die Festplatten hatten dabei durchschnittlich 90MB/s zu verarbeiten. Die Check-Latency, also die Verzögerung der Monitoring-Checks, betrug 20 Sekunden.

Managed Service Edition

Ebenfalls ab Version 1.4.0 wird eine Managed Service Edition (CME) erhältlich sein und eine Erweiterung zur bestehenden Check_MK Enterprise Edition (CEE) darstellen. Diese am Design anpassbare Version dient als abgesetztes System zur View für Kunden, welche z. B. Teilbereiche der überwachten Landschaft in einem separaten System und/oder separaten Netzbereich einsehen können sollen.

Check_MK Handbuch

Noch in diesem Jahr soll ein Check_MK Handbuch veröffentlicht werden. Die bereits in kleiner Auflage vorhanden und für Schulungen verwendeten Unterlagen (mit ca. 530 Seiten) sollen vervollständigt und erweitert werden und als komplettes Handbuch zu erwerben sein. Am Ende soll ein Buch entstehen, welches rund 1.000 Seiten (mindestens 800+) stark ist und rund 90,- € kosten.

„Check_MK bei der EDEKA – Monitoring im Enterprise-Umfeld“

Lars Hansen und Martin Lange von der LUNAR GmbH aus Hamburg stellten in Ihrem Vortrag die Architektur und Kennzahlen der Check_MK Installation der IT-Umgebung der EDEKA-Gruppe vor. Interessant hierbei waren nicht nur die hohen Anforderungen an das einzusetzende Monitoring System, beeindruckt haben vor allem die Zahlen der im Monitoring befindlichen Geräte und Services. Durch die Anwendung des bei EDEKA definierten Rechenzentrumsmonitoringtemplate und Einzelhandelsmonitoringtemplate sind monentan ca. 126.000 Geräte mit 1.400.000 Services im Monitoring, was eine Anzahl von insgesamt rund 2.000.000.000 Checks pro Tag ergibt.

Im Endausbau sollen es bei bis zu 11.500 bundesweit angeschlossenen Märkten ungefähr 570.000 Geräte mit 6.300.000 Services sein. Dies ergibt eine beeindruckende Anzahl von rund 9.070.000.000 Checks pro Tag.

Roadmap

Der letzte Track der Check_MK Konferenz in diesem Jahr war ein Ausblick auf die kommenden Entwicklungen, Ideen und Vorhaben des Check_MK Teams.

In Zukunft sollen Administratoren die Möglichkeit besitzen selektive Konfigurationsänderungen Aktivieren und Deaktivieren zu können. Auch eine zeitabhängige, auf Timeperiods basierende dynamische Parameter-Anpassung soll möglich sein.  Zudem sind Performance-Verbesserungen bei Livestatus in Planung, sowie eine Überarbeitung des gesamten SLA-Moduls, welche dem Administrator granularere Einstellungsmöglichkeiten bieten soll.

Neben den vielen hinzugekommenen Funktionalitäten, wird ab sofort auch die Versionierungsstrategie leicht geändert. Hochgezählt wird zukünftig für Minor-Releases an der zweiten Stelle der Versionsangabe – bisher wurde hierfür die dritte Stelle angepasst. Zudem wird hierbei keine Unterscheidung mehr zwischen geraden und ungeraden Versionsnummern gemacht, was in der Vergangenheit – und auch bei vielen anderen Projekten – eine stabile von einer Entwicklerversion unterschieden hat. Aufgrund von diversen Abhängigkeiten in den bestehenden Entwicklungsumgebungen, bleibt die Angabe der Version jedoch vorerst dreistellig. Die letzte Stelle wird mit einer Null mitgeführt (bspw. 1.4.0).

 

 

Mathias Kettner selber hat nach meinen Eindrücken die Entwicklung indes größtenteils an Lars Michelsen abgegeben, der auch offiziell die Leitung der Entwicklung innehat, und schaltet sich hier nur noch bei konzeptionellen Punkten, Zukunfts- und Grundsatzentscheidungen ein. Selber beschäftigt er sich zurzeit in kleinen Teilen mit dem Marketing und Vertrieb von Check_MK, vielmehr aber mit der Vervollständigung und Erweiterung der Dokumentation.

 

Die Check_MK Konferenz war, wie schon 2015, ein toller Treffpunkt für Nutzer von Check_MK, aber auch für Interessierte, sowie Entscheider. Man bekommt einen Rundumschlag der in Vergangenheit entwickelten Funktionalitäten, Eindrücken von Umsetzungen im Kundenumfeld, Vorstellungen von Integrationsmöglichkeiten, sowie einen Ausblick auf zukünftige Funktionalitäten und auf das, woran das Entwicklerteam von Check_MK gerade tüftelt und arbeitet – diese Transparenz wirkt auf die Benutzer vertrauensfördernd und bindend. Ferner können sie sich durch die Beauftragung von gewünschten Funktionalitäten, sog. Feature-Requests, auch aktiv einbringen und die Zukunft der Lösung somit mitgestalten.

 

Check_MK – was ist das eigentlich genau? In unserem Open Source Monitoring Guide haben wir die grundlegende Architektur und Merkmale von Check_MK einfach erklärt.

Insgesamt haben wir neun der gängigsten Open Source Monitoring Lösungen beleuchtet und die jeweiligen Stärken der einzelnen Lösungen herausgestellt. Viel Spaß beim Lesen!

 

Abonniere unseren Blog, um keine Beiträge zu verpassen (oben rechts).

 

Bilderquellen:    https://mathias-kettner.de/bilder/development_cycle.png