Am 3. und 4. Mai 2017 fand die diesjährige Check_MK Konferenz in München statt, welche mit 220 Gästen einen deutlichen Zuwachs im Vergleich zu der letzten Konferenz im Oktober 2015 verzeichnen konnte.

Das Programm enthielt eine in fünf Parts aufgeteilte Vorstellung der im vergangenen Jahr entwickelten neuen Funktionen, vier Gast-Vorträge von Kunden und Partnern, dedizierte Tracks über die neuen automatischen Agenten-Updates und die neue Managed Services Edition, sowie als Finale einen Ausblick auf die Roadmap und geplanten Entwicklungen. Die Gast-Vorträge behandelten die Themen Business Intelligence, Security, End-to-End Monitoring und Monitoring im Enterprise-Umfeld.

Zu Beginn der Konferenz stellte Mathias Kettner das gesamte Check_MK Team vor und veröffentlichte ein paar Keyfacts. War das Team bei der letzten Konferenz im Oktober 2015 noch ca. zwölf Personen stark, ist es bis heute auf 20 Personen angewachsen. 39 Partner in 12 Ländern unterstützen zurzeit das Check_MK Team und halten dabei 217 der insgesamt mittlerweile über 1.000 Subskriptionen. Diese Marke konnte zur Jahreswende 2016/2017 geknackt werden und zeigt, was für eine Verbreitung Check_MK bis heute erreicht hat.

Im Anschluss daran und über beide Tage verteilt, stellte das Entwicklerteam die im vergangenen Jahr entwickelten neuen Funktionen vor. Ein paar dieser Neuerungen habe ich hier kurz beschrieben:

 

Graphen

Die Anzahl der Datasources einer RRD-Datei passt sich neuerdings im laufenden Betrieb (mittels rrdtool tune) automatisch an die Anzahl der überwachten Performance-Daten an, ohne dass die Art der Speicherung der RRD-Dateien von SINGLE auf MULTI umgestellt werden muss. Somit muss man bei einer Veränderung der Anzahl der Performance-Daten nicht mehr den Umweg über ein händische Löschen und den somit einhergehenden Datenverlusst der RRD-Dateien nehmen.

Neben dieser Verbesserung haben die Administratoren über die Funktion der sogenannten „custom graphs“ eine Möglichkeit, sich Sammlungen von mehreren Graphen zusammenzustellen. Diese können gespeichert und auch als Python-Datei im Backend abgelegt werden. Zudem können die Daten eines Graphen über eine API im JSON-Format ausgelesen werden. Sicherungen der Graphendaten können zukünftig ohne das Deaktivieren des Monitorings durchgeführt werden. Das Verarbeiten der Performance-Daten über den eingesetzten rrdcache-Daemon kann mittels „suspend“ und „resume“ Befehlen angehalten und nach Abschluss des Backups wieder fortgeführt werden.

 

Sicherheit in der „Agent Bakery“

Auch in der „Agent Bakery“ gibt es Neuerungen. So können nun benutzerdefinierte Dateien mit auf die überwachten Systeme ausgerollt werden. Zudem werden neu „gebackene“ Agenten signiert, wodurch der Updater innerhalb des Check_MK Agenten auf dem überwachten System erkennen kann, ob er das für ihn vorgesehene Update sorgenfrei einspielen kann, oder dieses in der Zwischenzeit oder auf dem Transportweg manipuliert wurde. Zuletzt kann auch die Kommunikation zwischen Check_MK Server und den Agenten verschlüsselt erfolgen.

 

Realtime Monitoring

Durch Neuerungen im Check_MK MicroCore und dem Check_MK Agenten kann jetzt ein „Realtime Monitoring“ realisiert werden. Hierzu wird ein separater Prozess des Agenten auf dem überwachten System geforked, der anschließend die gewünschten Metriken sekündlich als UDP-Pakete an den MicroCore übermittelt.

 

Web-API

Auch die Web-API wurde um einige Funktionen erweitert. So können mittels entsprechender API-Calls diverse Funktionen (wie Anlegen, Löschen, Bearbeiten, etc.) benutzt und somit jegliche Objekte (wie Geräte, Services, Benutzer, etc.) innerhalb von Check_MK administriert werden. Auch Integrationen können darüber geschaffen werden, bspw. das Anbinden einer CMDB. Sehr interessant hierbei ist zudem wohl die Funktion zum Anstoßen einer Service-Discovery, wodurch dem Administrator hinsichtlich Automatisierung großartige Möglichkeiten offenstehen.

 

Event-Console

Die Event-Console basiert ab Version 1.4.0 auf der Datenbasis von Livestatus. Alle Nutzer eines verteilten Umfeldes sollte dies freuen. Ebenso können Meldungen von „unbekannten“ Geräten, also Geräten, die noch nicht im Monitoring eingerichtet sind, entgegengenommen und entsprechend gekennzeichnet werden. Zusätzlich dazu sind weitere Funktionalitäten enthalten, wie die Benutzung von regulären Ausdrücken (RegExp) für Filter-Mechanismen, oder einer „Overflow Protection“, welche Meldungs-Fluten unterdrücken soll.

 

Alle weiteren neuen Funktionalitäten folgen in der nächsten Woche im zweiten Teil dieser Blogserie. Abonniere unseren Blog per Email, um keine Beiträge zu verpassen (oben rechts).

 

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!

 

Ende Teil 1 – Teil 2 folgt nächste Woche.