Mobile-Menu

Workshop: Monitoring mit Checkmk – Teil 1 Wie funktioniert das Monitoring mit Checkmk?

Von Mirco Lang 6 min Lesedauer

Anbieter zum Thema

Checkmk GmbH

Eine komplette IT-Infrastruktur aufzubauen ist schon komplex – sie ständig im Auge zu behalten nicht minder. Wie kann die quelloffene Monitoring-Lösung Checkmk aus München dabei helfen?

Im ersten Teil unseres Checkmk-Monitoring-Workshops befassen wir uns mit den Grundlagen der umfangreichen Überwachungslösung.(Bild: Lang - Checkmk)
Im ersten Teil unseres Checkmk-Monitoring-Workshops befassen wir uns mit den Grundlagen der umfangreichen Überwachungslösung.
(Bild: Lang - Checkmk)

In dieser dreiteiligen Serie zu Checkmk zeigen wir, was die Monitoring-Software zu leisten vermag und vor allem wie sie tickt. Wie sieht ein Workflow generell aus? Wie kommen Geräte und Dienste ins Monitoring? Was sind sinnvolle erste Schritte? Wie genau lassen sich zum Beispiel Webseiten, Mailboxen oder die Auslastung von Speichermedien überwachen?

Die Teile zwei und drei der Serie erscheinen in den nächsten Tagen und werden sehr konkrete Aspekte beleuchten und gängige Beispiele zu Monitoring-Objekten wie Server-Hardware, Netzwerk-Verfügbarkeit oder Webanwendungen zeigen. Zunächst geht es allerdings darum, zu verstehen, wie Checkmk grundsätzlich funktioniert, was es überhaupt zu leisten vermag, wie der Datenfluss läuft – kurz: Wie Checkmk tickt.

Bildergalerie
Bildergalerie mit 5 Bildern

Features, Editionen, Aufbau

Checkmk gibt es bereits seit 2008, damals noch als Check_MK, entwickelt von Mathias Kettner – die mk-Endung taucht auch bei Plugins und Komponenten immer wieder mal auf. Ursprünglich baute Checkmk auf Nagios https://www.nagios.org/ auf und wurde mehr und mehr um eigene Komponenten erweitert, darunter auch eine – für damalige Verhältnisse – recht komfortable Weboberfläche. Heute ist der Nagios-Kern nur noch in der Open-Source-Version verbaut, die kommerziellen Editionen verfügen über einen eigenständigen Kern, der vor allem deutlich performanter arbeitet.

Monitoren lassen sich mit Checkmk grundsätzlich alle Dinge, die über eine IP-Adresse verfügen sowie darauf laufende Dienste. Sprich es können jegliche Arten von Servern und Workstations ins Monitoring aufgenommen werden, Netzwerkgeräte wie Switches oder Drucker, Cloud-Instanzen und sonstige virtuelle Maschinen, Container und so weiter.

All diese einzelnen Geräte werden in Checkmk als „Hosts“ aufgeführt. Alle Hosts zeigen wiederum mehr oder weniger „Services“, also beispielsweise laufende Prozesse, die Auslastung der CPU, die einzelnen Ports eines Switches bis hin zu konkreten SQL-Abfragen von Oracle-Datenbanken. Komplexere Komponenten wie etwa Kubernetes-Cluster dürfen natürlich auch nicht fehlen, hier bietet Checkmk diverse Möglichkeiten, um flüchtige, automatisch erzeugte Objekte ebenso automatisch ins Monitoring zu übernehmen. Zu guter Letzt: Auch ein Hardware-/Software-Inventar gehört zum Feature-Set.

Noch ein Wort zu den Editionen. Der größte Unterschied zwischen Open-Source-Version und kommerziellen Editionen ist wie bereits erwähnt der Monitoring-Kern – der Checkmk-eigene Kern „CMC“ (Checkmk Monitoring Core) ist deutlich performanter und für Projekte mit Tausenden von Hosts und entsprechend vielen Services ausgelegt. Funktional lässt sich dies jedoch genauso mit dem Nagios-Kern erledigen.

Im Detail gibt es etliche Unterschiede zwischen der kommerziellen Standardversion „Enterprise Edition“ und der Open-Source-Basis „Raw Edition“. Zum Beispiel enthält die Enterprise Edition umfangreiche Reporting-Funktionen, verteiltes Monitoring (etwa für mehrere Standorte, Kunden, Netzwerkzonen) oder das durchaus spannende „Predictive Monitoring“, das auf Voraussagen basiert.

Der wohl wichtigste Unterschied liegt jedoch in der so genannten „Agent Bakery“ – und die bringt uns direkt zur Frage, wie Checkmk überhaupt aufgebaut ist. Und das lässt sich am einfachsten am guten alten Grundprinzip der EDV zeigen: Eingabe, Verarbeitung, Ausgabe – EVA.

Eingabe: Agenten, SNMP, APIs

Der Checkmk-Server läuft ausschließlich auf Linux-Systemen und liefert die zentrale Weboberfläche. Hosts, beziehungsweise deren Daten, kommen nun auf drei Wegen ins Monitoring: Über installierte „Agenten“, Spezialagenten oder SNMP-Agenten. Agenten sind die Komponenten, die Roh-Daten ans Monitoring liefern – die Auswertung erfolgt auf dem Server.

Bei SNMP-Hosts wie Switches oder Firewalls werden die Daten direkt via SNMP ans Monitoring geliefert, hier werden allein die Metadaten (IP, Version, Community) benötigt. Spezialagenten laufen ebenfalls rein auf dem Checkmk-Server und holen sich Daten von Geräten, die weder SNMP anbieten noch die Installation von Software ermöglichen – über deren APIs. So lassen sich beispielsweise über die Kubernetes-API sämtliche (flüchtige) Container automatisch ins Monitoring holen und überwachen. Ein weiteres Beispiel für diese Agenten wäre das Monitoring von Füllständen von Tonern in Netzwerkdruckern.

Auf allen „richtigen“ Rechnern, sprich Servern und Workstations, wird in der Regel der Checkmk-Agent installiert. Der Agent führt auf den Hosts allerlei Tools und Skripte aus, sammelt Daten zu Prozessen, Logs oder Hardware-Metriken und liefert diese dann – auf Anfrage – regelmäßig an den Checkmk-Server. Der Datenstrom ist dabei ganz schlicht formatierter, menschenlesbarer Text.

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zu Netzwerktechnik, IP-Kommunikation und UCC

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung. Die Einwilligungserklärung bezieht sich u. a. auf die Zusendung von redaktionellen Newslettern per E-Mail und auf den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern (z. B. LinkedIn, Google, Meta).

Aufklappen für Details zu Ihrer Einwilligung

Und das bringt uns nun wieder zur „Agentenbäckerei“, dem vielleicht größten Unterschied zwischen Open-Source- und kommerzieller Version. Standardmäßig liefert ein installierter Agent lediglich einige Standarddaten. Wird er nun so konfiguriert, dass etwa Nvidia-GPUs überwacht werden sollen, wird das intern über ein Plugin erreicht. In der Open-Source-Version muss dieses Plugin in Form eines Skripts jedoch händisch auf dem Host ausgerollt, sprich in ein Unterverzeichnis des Agenten kopiert werden. Über die Agentenbäckerei lassen sich die Agenten hingegen auf dem Server erweitern, was in einer einzelnen kompilierten EXE-Datei resultiert. Einmal per Agentenbäckerei gebaute und auf den Hosts installierte Agenten lassen sich dann später auch automatisch aktualisieren. Die Agentenbäckerei erspart also händisches Ausrollen und Aktualisieren. So komfortabel dies auch sein mag – freilich kann man in der Open-Source-Version beispielsweise auch Ansible nutzen, um derlei Aktualisierungen ebenso komfortabel umzusetzen.

Natürlich gibt es Monitoring-Systeme, die explizit mit agentenlosem Monitoring werben. Der große Vorteil dort: Die (Basis-)Einrichtung ist unkompliziert, ein Übersichtsmonitoring ist fix eingerichtet. Der Vorteil von Agenten: Sie können extrem detailliert monitoren. Zumal eigene Erweiterungen schon ganz trivial möglich sind, Skripte müssen dem Datenstrom des Agenten lediglich eine Ausgabe in der Form „Zustand – Name – Beschreibung“ hinzufügen.

Verarbeitung: Checks

Der erste Schritt des EVA-Prinzips ist damit erledigt, die Eingabe der Daten erledigen die Agenten. Der nächste Schritt ist demnach die Verarbeitung. Das erledigen in Checkmk die so genannten „Checks“. Mal ein Beispiel: Der Agent liefert Daten zum Arbeitsspeicher in der Form „MemFree: 20501872 KB“. Dass rund 20 GB frei sind, mag interessant sein, aber die Aufgabe des Monitorings ist schließlich zu warnen und zu benachrichtigen, wenn etwa nur noch 5 Prozent des RAMs frei sind.

Diese Auswertungen werden in Checkmk über Regeln konfiguriert. Eine Regel könnte zum Beispiel lauten: „Wenn ein Linux-Host in Köln nur 5 Prozent freien RAM hat, soll der RAM-Service im Monitoring auf den Zustand WARN gehen.“ Der Vorteil dieser Art von Konfiguration: Es lassen sich in einem Schritt Hunderte Hosts/Services konfigurieren! Stellt sich nun die Frage, woher Checkmk weiß, dass es sich um einen Linux-Host in Köln handelt?

Ausgabe: Ansichten, Graphen Dashboards

Vorher aber noch kurz zum letzten Part des EVA-Prinzips, der Ausgabe: Nachdem die Daten von den Agenten geliefert und von den Checks ausgewertet wurden, werden die Ergebnisse in vielfältiger Form in der Weboberfläche ausgegeben. Die Basisausgabe in Listen-Form würde im Grunde so aussehen: „Zustand – Name – Beschreibung“ – also genau das oben bereits angesprochene Format für eigene kleine Erweiterungen. Daneben gibt es aber noch etliche weitere Darstellungen von simplen Grafen für die zeitliche Entwicklung von Metriken über typische, Management-kompatible Dashboards bis hin zu (sehr) abstrakten Visualisierungen von Zusammenhängen und Geschäftsanwendungen (Stichwort Business Intelligence).

Erste Schritte zum Abschluss dieses ersten Teils

Wieder zum Linux-Host in Köln: Checkmk hat diverse Mechanismen, um Hosts und damit das gesamte Monitoring zu strukturieren. Primär sollte über Ordner strukturiert werden, hinzu gesellen sich manuell organisierte „Host-Merkmale“, per Regel gesetzte Host-Gruppen, völlig freie, manuell oder automatisch gesetzte „Labels“ sowie hierarchische Eltern-Kind-Beziehungen, die sich aus dem Netzwerkaufbau ergeben.

Die meisten dieser Einordnungen lassen sich anschließend in den Regeln als Bedingungen nutzen, um eben Linux-Server in Köln von Windows-Workstations in Hamburg unterscheiden zu können. Und natürlich gilt das auch für die Kernfunktion eines jeden Monitoringsystems: Benachrichtigungen. Über die saubere Strukturierung von Monitoring-Objekten und die Zuordnung von Kontakten lässt sich präzise benachrichtigen.

Für ernsthafte Projekte sollte daher genau an dieser Stelle angefangen werden: Die Strukturierung der Hosts nach Standorten, Betriebssystemen, Verwendungszwecken, Benutzergruppen oder dergleichen. Wie sich eine Struktur ergibt und nutzen lässt, lesen Sie im nächsten Teil.

(ID:50196961)

Weiterführende Inhalte