Interview mit Marcel Arentz, Technical Product Manager bei Checkmk Cloud-Monitoring der IT-Realität ohne blinde Flecken

Checkmk ist eine in Python und C++ entwickelte Software für das Service-Monitoring von IT-Infrastrukturen inklusive Clouds. Wir loteten im Gespräch mit Marcel Arentz, Technical Product Manager bei Checkmk, die Grenzen des Möglichen aus.

CloudComputing Insider: Checkmk offeriert Monitoring von hybriden IT-Infrastrukturen inklusive Clouds aller Art. Wie sehen Ihre typischen Kunden aus?

Marcel Arentz: Den typischen Kunden per se gibt es nicht. Unsere Kunden kommen aus verschiedenen Industriezweigen und haben damit auch unterschiedlichste IT-Infrastrukturen, was die Größe und Zusammensetzung betrifft. Das kann ein Hoster mit weltweit verteilten Rechenzentren sein, dessen Fokus verstärkt auf der Überwachung der Netzwerk- und Server-Infrastruktur liegt, ein Industrie-Hersteller, der neben seinen IT-Systemen auch Produktionsanlagen überwacht, oder ein Service-Provider der mit Checkmk die Verfügbarkeit und Qualität seiner Services sicherstellt. Der große Vorteil von Checkmk ist seine Flexibilität und Vielseitigkeit, all diese unterschiedlichen Anforderungen an das Monitoring abdecken zu können. Dabei macht es keinen Unterschied, ob es sich um eine kleine Umgebung oder eine große IT-Infrastruktur handelt, die sich möglicherweise noch über mehrere weltweit verteilte Standorte erstreckt.

Sie versprechen lückenloses Monitoring von hybriden IT-Infrastrukturen, und zwar ohne Ausnahme. Bleibt da wirklich kein blinder Fleck?

Arentz: Der Anspruch eines Monitorings ist es immer, alles zu überwachen – ohne dabei Abstriche machen zu müssen. Mit seinen über 2.000 Monitoring-Plugins ist es sehr wahrscheinlich, dass Checkmk ein Gerät überwachen kann. Das bedeutet, es erkennt, um welches Gerät oder System es sich handelt und welche Metriken es abrufen soll – oft auch mit bereits sinnvoll gesetzten Schwellwerten für das Alerting. Damit ist Checkmk in der Lage, sämtliche Systeme in einem Netzwerk zu erfassen. Sollte ein System dabei sein, das Checkmk nicht kennt, ist es sehr wahrscheinlich, dass unsere Community bereits ein entsprechendes Plugin im Checkmk Exchange bereitgestellt hat. Das Exchange ist eine Plattform zum Teilen von eigenen Erweiterungen. Derzeit gibt es dort knapp 540 Plugins. Diese sind natürlich nicht herstellergewartet. Es ist außerdem auch möglich, eigene Plugins zu programmieren und Checkmk so zu erweitern. Letztendlich kommt es darauf an, dass wir die IT-Realität bei unseren Kunden im Monitoring abdecken können. In den letzten Jahren haben wir beispielsweise das Cloud-Monitoring immer weiter ausgebaut. Jetzt mit dem jüngsten Release unterstützen wir nicht nur erstmals das Monitoring von Google Cloud Platform, sondern haben auch das Monitoring für die anderen Public-Cloud-Anbieter erweitert, unter anderem für serverless functions oder gemanagte Datenbanken. Damit sind wir mit unserem Cloud-Monitoring gut aufgestellt und decken das Gros der Cloud-Anwendungsfälle von Unternehmen ab. Mit Checkmk vereinen wir das Monitoring von traditionellen Infrastrukturen mit Cloud-Szenarien in einer Lösung. Sollte das nicht ausreichen, lassen sich andere Monitoring-Tools mit Checkmk integrieren. Etwa das Monitoring von Network-Flows von ntop, für tiefgreifendere Analysen des Netzwerk-Traffics. Wir integrieren aber auch mit Datadog, sollten andere Teams im Unternehmen auf diese Lösung setzen.

Ihre Sammlung von mehr als 2.000 Monitoring-Plugins wird ständig erneuert, vermuten wir?

Arentz: Ja, wir warten unsere über 2.000 Monitoring-Plugins selbst. Schließlich wandelt sich die IT-Infrastruktur bei unseren Kunden immer weiter: Eine eingesetzte Hardwaregeneration wird durch eine neue ersetzt, Software weiterentwickelt. Es ist zwar sehr wahrscheinlich, dass wir eine neue Generation von Cisco-Geräten genauso überwachen können, wie die vorherige, kommen jedoch neue Protokolle, Techniken oder andere Änderungen hinzu, muss sich das natürlich auch im Monitoring wiederfinden. Durch die Wartung von bestehenden Plugins versuchen wir auch sicherzustellen, dass unser Monitoring an diese Änderungen angepasst ist. Darüber hinaus bauen wir selbstverständlich auch die Anzahl an Monitoring-Plugins immer weiter aus.

Sie bieten auch Check-Plugins für Cloud-Anwendungen von AWS, Azure und GCP: Frage von einem Doofen: Gibt es Unterschiede beim Monitoring von Hyperscaler-Clouds, Public Clouds kleinerer Art und privaten Clouds? Muss die Technik da jeweils anders vorgehen oder funktioniert das im Prinzip immer gleich?

Arentz: Es gibt immer mehrere Möglichkeiten, die Daten für das Monitoring abzurufen. Wenn es möglich ist, installiert man einen Monitoring-Agenten auf einem System. Das ist eine kleine Software, die die Daten abruft und an das Monitoring übermittelt. Wenn man keinen Zugriff auf das System hat, sei es aus Sicherheitsgründen oder weil es von der Beschaffenheit her nicht möglich ist, lassen sich die Daten über die gängigen Monitoring-Protokolle wie zum Beispiel SNMP oder eben über vom Hersteller bereitgestellte Schnittstellen, wie einer Rest-API, abrufen. Da man in der Regel in Cloud-Umgebungen keinen Zugriff auf die darunterliegende Infrastruktur hat, geschieht das Monitoring über eine solche API. Das heißt, Sie müssen sich bei der Entwicklung eines Checks fragen: Was soll überwacht werden? Was für Metriken lassen sich über die API überhaupt abrufen und wie? Man ist also auch immer ein bisschen davon abhängig, was der Anbieter „erlaubt“ abzurufen. Einfacher ist es, wenn Sie auf Ihren Cloud-Ressourcen, sei es Container, Kubernetes-Nodes oder virtuellen Maschinen einen Agenten ausrollen dürfen. Dann unterscheidet sich das Monitoring in der Cloud nicht von einer lokal gehosteten Lösung. Das „Was“, macht ebenfalls einen Unterschied aus, da es sich auch direkt auf die Technik auswirkt. In der Cloud überwacht man hauptsächlich die Anwendungsebene, also Applikationen, Netzwerk etc. und nicht die Hardware-Ebene. In einer privaten Cloud benötigen die gleichen Ressourcen jedoch noch zusätzliche Ebenen im Monitoring oder sogar alternative, eben weil man möglicherweise den Zugriff hat, um bessere Einblicke zu erhalten.

Sie unterstützen die Kubernetes-Distributionen Vanilla Kubernetes, OpenShift, AKS, EKS und GKE. Wird das erweitert? Was ist zB mit Cloud Foundry?

Arentz: Die Unterstützung von zusätzlichen Plattformen entwickeln wir fast immer zusammen mit unseren Nutzern. Das seit Version 2.2 verfügbare OpenShift-Monitoring haben wir auf diese Weise entwickelt und aktuell ist dies auch mit der für Checkmk 2.3 geplanten Unterstützung von SUSE Rancher der Fall. Ob wir Cloud Foundry oder weitere K8s-Distributionen in zukünftigen Versionen unterstützen, werden wir nach den gleichen Kriterien entscheiden.

Sie offerieren die Möglichkeit, über die Check-API auch selbst erstellte Monitoring-Plugins hinzuzufügen. Interessehalber die Frage: Wie viele Kunden schreiben eigene Plugins?

Arentz: Genaue Zahlen haben wir dazu nicht. Aus unseren Kundengesprächen geht jedoch hervor, dass die Erweiterung durch eigene Check-Plugins seit der Einführung der Check-API vor zwei Jahren deutlich gestiegen ist. Aber nicht alle – oder nur sehr wenige – stellen ihr eigenes Plugin als teilbares Erweiterungspaket im Checkmk Exchange online oder veröffentlichen den Code auf GitHub. Das liegt hauptsächlich daran, dass Checkmk selbst schon sehr viel überwachen kann und die eigenen Entwicklungen oft ganz spezifische, teilweise unternehmensinterne Anwendungen oder Geräte abdecken.

Die Checkmk Cloud Edition bietet Ihren Angaben zufolge eine „Autoregistrierung für die Aufnahme von Cloud-Objekten in Echtzeit“. Können Sie das unseren Lesern näher erläutern?

Arentz: Die Autoregistrierung ist ein Feature des Monitoring-Agenten in der Checkmk Cloud Edition. Sie sorgt dafür, dass von AWS, Azure oder GCP erzeugte Objekte als Hosts ins Monitoring aufgenommen werden. Dazu kommuniziert der Checkmk-Agent mit dem Checkmk-Server. Der Agent stellt eine Anfrage zur Registrierung und übermittelt die für die Erstellung des Hosts benötigten Daten. Akzeptiert der Checkmk-Server die Anfrage, wird die Registrierung durchgeführt und eine TSL-Verbindung aufgebaut. Checkmk erstellt nun den Hosts, führt automatisch eine Erkennung aller auf dem Host verfügbaren Services durch und übernimmt den Hosts mit allen erkannten Services anschließend ohne manuelles Zutun in das Monitoring. Der Einsatz der Autoregistrierung ist jedoch nicht allein auf Cloud-Umgebungen begrenzt. Ein für die Autoregistrierung konfigurierter Agent lässt sich zum Beispiel mittels des zentralen Agenten-Managements von Checkmk automatisch auf neue Hosts etwa bei Massenrollouts ausrollen, sodass diese sich nach der Installation des Agenten automatisch im Monitoring registrieren.

Apropos Automatisierung: Sie stellen eine integrierte Agentenverwaltung in Aussicht: Cloud-fähige Agenten „mit Push- oder Pull-Modus“ sollen für die Datenerfassung von Cloud-basierten und lokalen Hosts sorgen. Wie genau funktioniert das?

Arentz: Die Checkmk-Agenten sind kleine Programme, die Sie auf dem Host installieren und die Daten für das Monitoring auf dem System sammeln. Bisher haben unsere Monitoring-Agenten standardmäßig im Pull-Modus gearbeitet. Dabei baut der Checkmk-Server die Verbindung zum Agenten auf einem Host auf und bekommt so die Monitoring-Daten. Dieser Modus funktioniert also nur, wenn der Checkmk-Server auch auf das Netzwerk des Hosts mit dem Agenten direkt zugreifen kann. Mit der Checkmk Cloud Edition lassen sich die Monitoring-Agenten im Push-Modus konfigurieren, sodass der Verbindungsaufbau genau umgekehrt erfolgt. Der Agent auf einem Host greift in diesem Fall direkt auf den Checkmk-Server zu. Er wartet also nicht auf die Anfrage vom Server, sondern sendet selbstständig die Monitoring-Daten an Checkmk. In Cloud-basierten Konfigurationen oder segmentierten Netzwerken ist der Push-Modus daher für das Monitoring oft besser geeignet.

Sie versprechen dank einer verteilten Architektur „nahezu unbegrenzte Skalierbarkeit“ für die Überwachung von Hosts und Services – wo liegen die Grenzen?

Arentz: Der Vorteil einer verteilten Architektur ist, dass es theoretisch keine Grenzen gibt. Im Prinzip bedeutet es, dass Sie neben einer zentralen Monitoring-Instanz das Monitoring auf beliebige Remote-Instanzen verteilen. Dies kann der Fall sein, weil Sie zum Beispiel unterschiedliche, eigenverantwortliche Teams haben. Hochverfügbarkeit und Redundanz sind jedoch meist die wichtigsten Argumente für ein Distributed Monitoring: Das Monitoring soll an einem anderen Unternehmensstandort unabhängig von anderen Standorten betrieben werden oder ein Standort lässt sich aufgrund seiner schlechten Anbindung am besten lokal überwachen. Jede Remote-Instanz überwacht dabei die jeweilige IT-Umgebung, ohne dass dabei ständig Daten an die zentrale Monitoring-Instanz übertragen werden müssen. Sie können aber von der Zentral-Instanz auf die Remote-Instanzen zugreifen und alle Instanzen in einer Gesamtsicht zusammenführen, sodass es sich wie ein großes Monitoring-System anfühlt. Die GUI ruft lediglich die Live-Daten ab, die der Anwender in der Zentral-Instanz abruft. Da das Monitoring selbst keinerlei Netzwerk-Traffic zwischen den einzelnen Instanzen erzeugt, ist es problemlos möglich, hunderte und mehr Standorte an eine Zentral-Instanz anzubinden. Auf diese Weise lassen sich hunderttausende von Hosts mit Checkmk überwachen – und wir haben auch Kunden mit solch großen Monitoring-Umgebungen.

Ihre Lösung ist Open Source – auch hier die Frage: Wie viele Ihrer Kunden bearbeiten den Code und passen ihn sich an, wie viele kaufen "von der Stange"?

Arentz: Der Großteil der Kunden kauft tatsächlich „von der Stange“ und erweitert das Monitoring mit Checkmk bei Bedarf über Plugins aus der Checkmk Exchange. Die Möglichkeit der einfachen Erweiterung spielt für viele Kunden bei der Evaluierung des Monitoring-Tools eine große Rolle, da praktisch alle Unternehmen selbst entwickelte Lösungen betreiben, die keine Monitoring-Software direkt abbildet. So ist es der Fall, dass viele Kunden erst im Laufe der Zeit eigene Plugins entwickeln. Zudem kann man durch die freie Zugänglichkeit des Codes diesen nicht nur anpassen oder erweitern. Ein nicht unerheblicher Aspekt von Open-Source ist die Transparenz und Nachvollziehbarkeit. Gerade in der heutigen Zeit ist Security ein immer wichtiger werdendes Thema. Die Nutzer von Checkmk können daher jederzeit nachsehen, welcher Code ausgeführt wird und diesen bei Bedarf an die eigenen Richtlinien anpassen. Gerade bei den Agenten auf den produktiven Geräten, ist es ein wichtiger Aspekt, Sicherheits-Audits jederzeit durchführen zu können. Die Eigenschaften von Open-Source erleichtern das sehr.

Unter welcher Lizenz kann Ihre Lösung bearbeitet werden und welche Konsequenzen ergeben sich daraus für den Bearbeiter?

Arentz: Alle Anpassungen müssen unter die gleiche Lizenz gestellt werden, die auch Checkmk nutzt. Im Wesentlichen bedeutet das, dass jeder Code ebenfalls die GPLv2 als Lizenzierung nutzt. Auf diese Weise bleiben die Prinzipien der Nachvollziehbarkeit erhalten. Noch wichtiger ist jedoch der enorme Mehrwert, den jeder Nutzer dadurch erhält: Bei der Veröffentlichung des Codes erhalten alle Anwender von Checkmk die Erweiterung. Die Investition der eigenen Ressourcen wird dadurch belohnt, dass andere Nutzer es ebenso machen. Mit vergleichsweise wenig Aufwand erhält man sehr viel Inhalt – mehr als man sich allein erarbeiten könnte.

Der Trend, die IT in die Cloud zu verlagern, ist ungebrochen. Was macht Checkmk, um auch in der Zukunft dafür gerüstet zu sein?

Arentz: Genau, in den letzten Jahren verlagern immer mehr Unternehmen ihre IT-Infrastruktur in die Cloud. Die Umsetzung erfolgt zum einen im Rahmen von langfristigen Projekten, um bestehende Teile der IT zu migrieren und auf die Eigenschaften der Cloud anzupassen. Zum anderen gibt es in fast allen Unternehmen auch Teile der IT, die sich nicht auslagern lassen oder die langfristig nicht wirtschaftlich in der Cloud betrieben werden können. IT-Infrastrukturen sind in der Realität in Unternehmen daher meist hybrid, auch wenn die Gewichtung zwischen Cloud und On-Premises in jedem Unternehmen unterschiedlich ausfällt. Dank der Grundarchitektur von Checkmk waren wir in der Lage, das Monitoring schnell um reine Cloud-Services zu erweitern. Dadurch müssen unsere Nutzer keine Kompromisse eingehen, egal an welchem Punkt ihrer Cloud-Reise sie sich befinden und unabhängig davon, wie sich die IT-Infrastruktur auf On-Premises und Cloud verteilt. Mit Checkmk lässt sich jedes Szenario abbilden und vor allem auch über die Zeit einfach anpassen. Dieses Profil werden wir auch in der Zukunft weiter schärfen.

Herr Arentz, wir danken für das interessante Gespräch!

(ID:49580847)