In diesem Blogpost stellen wir die verschiedenen Neuerungen in Checkmk 2.0 vor, die vor allem die Leistung des Monitorings deutlich verbessern. So verringert die neue Archtektur des CMC (Checkmk Micro Core) zum Beispiel den Memory- und CPU-Footprint von Checkmk.
Neue Helper-Prozesse brauchen viermal weniger Leistung
Neben all den bereits erwähnten neuen Funktionen, haben wir für Checkmk 2.0 auch unter die Haube geschaut und einige Verbesserungen vorgenommen, unter anderem am Checkmk Micro Core, der bei der Enterprise Edition zum Einsatz kommt. Ergebnis der Core-Modifizierung ist, dass Checkmk 2.0 für die gleiche Performance nun viermal weniger Arbeitsspeicher braucht als vorher. Dafür haben wir die Helper-Prozesse komplett überarbeitet.
Die Helper-Architektur in Checkmk 1.6 sah bisher so aus: Der Core übermittelt eine Aufgabe an einen der Checkmk-Helper, beispielsweise die Durchführung einer Host-Abfrage. Nachdem der Helper die Aufgabe vom Micro Core erhalten hat, fängt er an, diese zu bearbeiten. Dafür sammelt er zunächst die Daten vom gewünschten Host ein, etwa über einen Agenten oder SNMP. Aus diesen eingeholten Daten verarbeitet der Helper anschließend das Ergebnis des Checks. Dieses wird anschließend an den CMC weitergeleitet, wo es nun als neuer Service-Status einfließt. Bei diesen ganzen Vorgang handelt es sich um einen einzelnen Prozess.
Problematisch ist hierbei, dass diese Prozesse sehr Memory-lastig sind – vor allem in großen Umgebungen. Zudem müssen diese Prozesse möglicherweise auf Netzwerk-I/O warten. Dies führt dazu, dass diese Memory-hungrigen Prozesse beim Warten auf Netzwerk-I/O im Leerlauf und somit ineffizient sind.
Daher haben wir die Architektur überarbeitet und den ganzen Vorgang geteilt. In Checkmk 2.0 haben wir zwar weiterhin den Monitoring-Core, jedoch haben wir jetzt zwei Helper-Prozesse: Die Fetchers sowie die Checkers.
Die Fetcher sind für das einsammeln der rohen Monitoring-Daten beispielsweise via Agenten oder SNMP zuständig. Da es sich hierbei um sehr kleine Prozesse handelt, kann eine Monitoring-Umgebung über sehr viele verfügen. Da sie außerdem nur wenig Memory benötigen, ist es auch kein Problem mehr, dass sie auf Netzwerk-I/O warten müssen. Hat ein Fetcher seine Daten oder ein Timeout erhalten, leitet er dies an den Core weiter.
Anschließend übermittelt der CMC die Daten an die Checker-Prozesse. Diese sind weiterhin sehr Memory-lastig, ähnlich wie die Helper in Checkmk 1.6. Das liegt daran, dass sie neben der rohen Monitoring-Daten außerdem über alle Check-Konfigurationen Bescheid wissen müssen. Da der Core die Monitoring-Daten jedoch bereitstellt, können die Checker diese direkt bearbeiten und die Service-Status liefern. Da die Checker keinen Leerlauf mehr haben, benötigt Checkmk auch nicht mehr so viele davon. Dadurch verringert sich die Belastung des Arbeitsspeichers und der CPU deutlich.
In den Umgebungen, in denen wir die neue Architektur bereits getestet haben, konnten wir den Memory-Verbrauch um den Faktor vier reduzieren. Im Umkehrschluss heißt das, dass sich mit der neuen Architektur bei gleichbleibender Performance des CMC viermal so viele Systeme in Checkmk überwachen lassen.
Standardmäßig verfügt Checkmk 2.0 über 13 Fetcher- und vier Checker-Prozesse. Es besteht jedoch die Möglichkeit, wenn die Check-Latenz zu hoch ist oder die Checker- und Fetcher-Nutzung zu hoch ist, granular nachzubessern. Etwa, indem man die Anzahl eines Pools manuell erhöht, um die bestmögliche Performance für seine Monitoring-Umgebung zu erhalten.
Mehr Leistung in verteilten Umgebungen
Darüber hinaus führen wir im Rahmen von Checkmk 2.0 auch weitere Performance-Verbesserungen ein. In verteilten Monitoring-Umgebungen wird der Synchronisierungsmechanismus künftig inkrementell arbeiten. Das heißt, dass die Central und die Remote-Site vor der Synchronisierung miteinander kommunizieren und anschließend nur die geänderten Konfigurationsdaten austauschen.
Auf diese Weise soll das Durchführen von Änderungen an der Konfiguration in Distributed-Monitoring-Umgebungen deutlich effizienter werden. Zuvor hat Checkmk immer das gesamte Konfigurationspaket synchronisiert. Der neue Ansatz benötigt zudem weniger Bandbreite und CPU-Leistung.
Weitere Leistungsengpässe im Monitoring behoben
Darüber hinaus haben wir uns viele einzelne Einsatzszenarien angeschaut und geprüft, wie wir mit kleinen Änderungen die Leistung für den jeweiligen Use Case als auch für das Monitoring generell verbessern können. Unsere Motivation ist es, so die Performance von Checkmk aus Nutzersicht nachhaltig zu verbessern, indem wir verschiedene Einsatzszenarien von Checkmk in der Praxis gezielt analysieren.
Das Ergebnis dieser Vorgehensweise sind beispielsweise Änderungen an nahezu allen Komponenten, speziell an der Check-Engine und an der Konfigurationsverarbeitung, etwa durch eine schnellere Regelauswertung von expliziten Host-Attributen, verbessertes Handling bei einer größeren Anzahl von Piggyback-Hosts, ein bis zu hundertmal so schnelle Aktualisierung von DNS-Einträgen von Hosts sowie eine sechsmal schnellere Ladezeit der Konfiguration. Darüber hinaus haben wir das Rendern von Graphen mit hoher Auflösung in der GUI beschleunigt.
Beim Setup haben wir das Sortieren von tausenden Host-Tag-Gruppen sowie die Host- und Service-Fertigstellung verbessert. Zudem laden Host-relevante Seiten nun schneller und auch das Rendern von langen Tabellen geht nun rascher. Mit Checkmk haben wir darüber hinaus die Suche nach Regelwerken mit vielen Zeitspannen-Referenzen sowie Kontakt-, Host- und Service-Gruppen verbessert.
Weitere Informationen rund um Checkmk 2.0
Lesen Sie auch die anderen Blogartikel zu den neuen Funktionen von Checkmk 2.0:
- Moderner, intuitiver und individueller: Die neue UX
- Cloud und Container: Monitoring von modernen IT-Assets
- Netzwerk-Monitoring: Tiefere Einblicke und verbesserte Konfiguration
- Neue APIs sorgen für Automatisierung und mehr Stabilität
- Breites Fundament für Ihr IT-Monitoring
Weitere Informationen rund um Checkmk 2.0 finden Sie auch im Checkmk-Forum, im Checkmk-Handbuch auf unserem YouTube-Kanal.