Ethan Galstad von Nagios Enterprises spricht mit Mathias Kettner über check_mk

Vielen Dank an Ethan für dieses Interview. The Originalfassung finden Sie hier. Eine Englische Version ist auch verfügbar.

Ethan Galstad: In dieser Folge von "Meet The Community" spreche ich mit Mathias Kettner, dem Autor von check_mk - einem einzigartigen Addon für Nagios, das das Remote-Monitoring von Systemdaten stark vereinfacht.

Ethan Galstad : Kannst du uns in bisschen über dich selbst erzählen?
—
Mathias Kettner: Ich komme aus München in Deutschland und habe dort 1998 mein Informatikstudium abgeschlossen. Von Herbst 1999 bis Frühjar 2001 habe ich als Entwickler bei SuSE in Nürnberg gearbeitet. Während dieser Zeit habe ich unter anderem die Systemarchitektur für YaST2 entworfen. Seit ich bei SuSE aufgehört habe bin ich selbständiger Linux-Experte und biete zusammen mit meinen Mitarbeitern Beratung und Schulungen rund um das Thema Linux und Open Source an. Dabei bildet das Thema Monitoring mit Nagios einen wichtigen Schwerpunkt.

EG: Kannst du uns einen kurzen Überblick darüber geben, was das Projekt (check_mk) ist?
—
MK: Check_mk ist aus der Erfahrung von vielen Jahren Nagios-Consulting heraus geboren. Gerade bei größeren Installationen ist das Erstellen und vor allem Aktuellhalten der Konfiguration sehr aufwendig. Und natürlich kommt man ab etwa 2.000 Checks langsam Probleme mit der Performance, teils schon deutlich früher. Check_mk löst diese Probleme auf eine überraschend einfache Art. Es verwendet eigene sehr einfach gebaute Agenten. Das Besondere: der Agent wird nicht für jeden Check separat aufgerufen sondern sendet immer gleich alles, was er über den Host weiß. Pro Host richtet man in Nagios nur noch einen einzigen aktiven Check ein. Dieser holt die Daten vom Host, wertet sie aus und sendet Nagios per passive Servicechecks die Resultate der einzelnen Services.

EG: Was sind die Hauptvorzüge für einen Nagios-Benutzer, wenn er check_mk einführt?
—
MK: Der auffälligste Vorteil ist, dass es mit check_mk viel weniger Arbeit macht, neue Hosts in das Monitoring aufzunehmen. Der Agent - egal ob für Windows, Linux oder UNIX - erfordert keine Konfiguration. Bei Linux und UNIX ist besonders hervorzuheben, dass der Agent ohne kompilierte Programme auskommt und als portables Shellskript realisiert ist. Der Großteil der Services wird automatisch erkannt und eingebunden, die Konfiguration für Nagios automatisch erstellt. Bei zunehmender Größe der Installation wird außerdem der große Performancevorteil deutlich. Check_mk macht es möglich, zehntausende von Checks pro Minute durchzuführen - selbst wenn man die Daten in RRD-Datenbanken einträgt.

EG: Check_mk hat eine einzigartige Architektur, wenn man es mit anderen Methoden des Remote-Monitorings vergleicht. Was hat dich zu dieser Idee inspiriert?
—
MK: Die Idee zu dieser Architektur enstand beim Monitoring von UNIX-Systemen. NRPE ist hier besonders aufwendig, da vorkompilierte Pakete nicht verfügbar sind und das Kompilieren auf den verschiedenen UNIX-Derivaten viele Administatoren überfordert - denn zum NRPE müssen ja auch noch die Plugins kompiliert werden. Aus diesem Grund entwickelte ich ein Verfahren, das auf einem Shellskript und inetd basierte. Die Idee, alle Services von einem Host in einem einzigen Durchlauf zu bearbeiten und die Ergebnisse durch die Kommandopipe an Nagios zu senden, kam erst vor eineinhalb Jahren wie aus heiterem Himmel. Später habe ich erkannt, dass sich das Verfahren auch wunderbar auf SNMP ausdehnen lässt. Beim Überwachen von Switchports kann check_mk die Daten zu allen Ports in einem Durchlauf verarbeiten. Und es kann automatisch erkennen, welche Ports in Verwendung sind und dafür Nagios-Services einrichten.

EG: Aus deiner Erfahrung: Ersetzen Benutzer normalerweise ihre bestehenden Monitoring-Agenten (NRPE, NSClient++, usw.) durch dieses Addon oder benutzen sie sie weiter?
—
MK: Prinzipiell kann check_mk in jeder beliebigen Dosierung parallel zu allen anderen Methoden eingesetzt werden. Wer allerdings ein paar Tage mit check_mk gearbeitet hat, der wird die Nachteile, die mit NRPE und NSClient++ verbunden sind, bald scheuen. Eine Migration zu check_mk geht meist sehr rasch. Einzelne Checks, die mit check_mk nicht gut zu realisieren sind oder wo der Aufwand einer Umstellung nicht lohnt, können problemlos mit den klassischen Methoden parallel weiterbetrieben werden.

EG: Gibt es irgendwelche Nachteile, wenn man check_mk anstelle von dedizierten Agenten wie NRPE oder NSClient++ verwendet? Gibt es zum Beispiel bestimmte Arten von Informationen oder Messwerten, die man mit check_mk und seiner Architektur nicht so einfach monitoren kann?
—
MK: Die Architektur legt keine Einschränkungen auf. Es gibt allerdings Einzelfälle, wo Checks mit der klassischen Methode besser zu lösen sind. Zum einen sind das Netzwerkchecks wie check_http, welche ohnehin ohne Agent arbeiten. Zum anderen ist der Windows-Agent leider noch nicht so flexibel wie die für Linux und UNIX - er ist aktuell noch nicht skriptbar und nur über Programmierung in C zu erweitern. Das liegt nicht zuletzt an meiner Entscheidung, direkt gegen die WIN32-API zu programmieren. Der Vorteil: Der Agent braucht weder .NET, noch Java noch irgendeine andere Laufzeitumgebung - nicht mal eine spezielle DLL - und ist so optimal portabel.

EG: Du hast check_mk bei etlichen deiner Kunden mit einer großen IT-Infrastruktur eingesetzt. Wie hilft check_mk Nagios zu skalieren? Was ist die größte Installation von check_mk, die du kennst?
—
MK: Die größte Installation führt aktuell 17.500 Checks pro Minute durch. Demnächst soll die Überwachung um etliche hundert Windows-Server erweitert werden. Die Load auf der 4-CPU-Maschine liegt bei etwa 6 - wobei der Großteil der Zeit auf IO-Wait geht (Linux rechnet Prozesse, die auf IO warten zur Load hinzu). Es werden etwa 5MB pro Sekunde an RRD-Daten geschrieben. Unter Einsatz des RRD-Caches, sehe ich auf dieser Hardware 30.000 bis 40.000 Checks pro Minute als machbar an.

EG: Wie lange arbeitest du schon an check_mk?
—
MK: Die heutige Implementierung - in Python - ist vor etwa eineinhalb Jahren entstanden. Check_mk ist seit Ende April 2009 unter GPL verfügbar.

EG: Du bist der Hauptentwickler von check_mk. Gibt es in dem Projekt andere Entwickler oder Mitwirkende?
—
MK: Momentan bin ich der einzige, der an der eigentlichen Programmierung arbeitet. Einen maßgeblichen Teil zum Erfolg und der Reife des Projektes trägt allerdings einer meiner Kunden bei: Karl-Heinz Fiebig. Er ist der Herr über die größte Installation, bringt sehr viele gute Ideen, ist meist der erste, der meine Fehler ausbaden muss und legt gelegentlich schonmal selbst Hand an den Code an, wenn Probleme behoben werden müssen.

EG: Auf welche Art hast du zum ersten mal von Nagios gehört und warum hast du dich dafür entschieden, es einzusetzen?
—
MK: Mein erstes Projekt mit Nagios habe ich 2003 durchgeführt. Aus Kostengründen sollte ein Open-Source-System zum Monitoring verwendet werden. Schon damals war Nagios das bekannteste System seiner Art. Es konnte dann auch alle Anforderungen des Projektes voll erfüllen.

EG: Was sind deiner Meinung nach die nützlichsten Vorteile wenn man Nagios einsetzt?
—
MK: Nagios ist sehr flexibel und ermöglicht den Aufbau von sehr individuellen Lösungen. Auch der Kostenfaktor spielt eine große Rolle, da kommerzielle Monitoringsysteme sehr hohe Lizenzkosten verursachen.
—
EG: Gibt es bestimmte Änderungen, die du dir an Nagios wünschst, damit die Integration von check_mk einfacher wird?
—
MK: Die Integration von Nagios und check_mk lässt eigentlich wenig zu wünschen übrig. Alle nötigen Schnittstellen sind vorhanden und sind auch einfach sehr effizient.

EG: Gibt es etwas, dass du für die Fortsetzung und Verbesserung des Projektes benötigst?
—
MK: Was das Projekt am meisten weiterbringt, sind zum einen Kundenprojekte, bei denen ich selbst mit Nagios und check_mk Monitoringlösungen umsetze und das System so weiterentwickelt wird. Zum anderen sind aber auch Rückmeldungen von Nutzern aus der Community sehr wertvoll - seien es qualifizierte Fehlermeldungen, Hinweise auf wichtige Anforderungen und nicht zuletzt natürlich Werbung für das Projekt in Form von Links, Forenbeiträgen, fremdsprachiger Dokumentation und Ähnlichem.

EG: Was sind deine Pläne für die Zukunft von check_mk?
—
MK: Der wichtigste Punkt ist sicherlich der Ausbau der Dokumentation. Außerdem arbeite ich an Konzepten zur Modularisierung der Agenten. Vor allem den Windows-Agenten möchte ich leichter erweiterbar machen. Dabei bin ich noch auf der Suche nach einem wirklich überzeugenden Konzept, bei dem der jetzige minimalistische Ansatz nicht verloren geht.