Die fünfte Check_MK-Konferenz fand im Zeitraum 28.-30. April 2019 in München statt. Eine neue Firma, viele neue Mitarbeiter und neue Strukturen geben dem Monitoring Projekt Check_MK weiteren Schwung. Das letzte Jahr konzentrierte sich das Team auf dynamische Umgebungen, Container und Cloud Dienste. Zusätzlich zu den Plänen der Check_MK-Entwickler wurden spannende Vorträge rund um das Monitoring angeboten.

Nachdem im letzten Jahr ein neuer Geschäftsführer bei der Matthias Kettner GmbH eingesetzt wurde und Matthias Kettner sich auf die technische Weiterentwicklung konzentriert hat, wurde in diesem Jahr die Firma umbenannt und ein neues Corporate Design vorgestellt. Das Produkt Check_MK wird nun von der tribe29 GmbH entwickelt. Dieser Name setzt sich aus dem Gefühl der Mitarbeiter ein Stamm zu sein und der Kellerstraße 29 zusammen.

Letztes Jahr war das Ziel ausgegeben worden, um 10 Personen zu wachsen. Letztlich sind es mehr geworden. Inzwischen umfasst der Stamm 34 Mitglieder. Dieses Wachstum ist gründlich geplant und durch Strukturen gelenkt.

Neuerungen in Check_MK

Bereits im letzten Jahr wurde der Plan verfasst, das Benutzerinterface von Check_MK zu modernisieren und intuitiver zu gestalten. Zunächst wurde das „Modern Theme“ eingeführt, eine ab der Version 1.5 verfügbare dunkle Version der Oberfläche.

Für die Version 1.6 wird die Oberfläche komplett überarbeitet, hierbei werden auch Informationen verdichtet und viele Abstände auf der Webseite verkleinert. Eine Umfrage unter den Konferenzteilnehmern zeigte klar, dass mehr Informationen auf gleichem Raum dargestellt werden sollen. Zudem werden die Filtermöglichkeiten überarbeitet und die Darstellung gestrafft. Eine Dynamisierung oder Anpassungen pro User werden aber nicht ermöglicht.

Zur Steigerung der Flexibilität können mit der Version 1.6 auch Tags für Services vergeben werden. Die Steuerung des Monitorings kann hierdurch wesentlich flexibler gestaltet werden. Zusätzlich zu fest vergebenen Tags, die vom Admin vorkonfiguriert werden und vom Benutzer nur noch ausgewählt werden können, wird mit Labels eine weitere Möglichkeit der Kennzeichnung eingeführt. Labels entstehen durch die Eingabe beim Host oder Service und verschwinden auch wieder automatisch, wenn sie nicht mehr verwendet werden. Genau wie Tags können sie in Regeln verwendet werden, aber die Eingabe der Labels wird nicht validiert. Eingabefehler können also dazu führen, dass eine Regel unerwarteter Weise nicht zutrifft.

Bisher war es so, dass die Regelauswertung sehr statisch war. Innerhalb einer Zeile waren die Bedingungen mit ODER verknüpft, alle Zeilen waren mit UND verknüpft. Diese statische Definition soll aufgelöst werden und die Verbindung der Bedingungen soll vom Benutzer gepflegt werden können.

Bisher war das Ermitteln der Services eines Hosts ein synchroner Prozess, auch an der Benutzeroberfläche. Dieses führt aber bei großen Hostsystemen oder großen Netzwerkkomponenten häufig zu einem HTTP-Timeout, wenn das Discovery länger dauert als der Browser warten mag. Diesem Thema haben sich die Entwickler angenommen und das Service Discovery läuft nun im Hintergrund. Solange das Service Discovery läuft, werden noch die potentiell aus dem Cache stammenden alten Werte angezeigt. Nach Abschluss des Scans, auch wenn dies mehrere Minuten dauern sollte, sind die Werte dann aktualisiert. Diese Funktion ist essenziell zur Überwachung von z. B. VMware, Storage Systemen und Switchen.

Auch im Bereich Sicherheit haben die Entwickler einiges geändert. Durch ein Security Audit der Software sind Schwachstellen ermittelt worden. Dieses umfasst z. B. Javascript Code Injection, verbessertes Passwort Hashing, CSRF-Absicherung der Hintergrundabfragen.

Die Änderungen sind vielfach schon in die Updates der Versionen 1.4 und 1.5 eingeflossen und somit bereits im Einsatz.

Ein vielfach gewünschtes Feature kommt allerdings mit der Version 1.6. Die Livestatus-Verbindung kann verschlüsselt werden. Diese Funktion ist bei einer Neuinstallation standardmäßig aktiviert, erfordert bei der Einrichtung einer Multisite Verbindung einen Klick mehr und muss für bestehende Installationen beim Update auf die Version 1.6 manuell aktiviert werden. Nach der Aktivierung der Verschlüsselung muss aber geprüft werden, ob Checks, die auf die Livestatus-Informationen zugreifen, noch funktionieren. Dieses könnten zum Beispiel Checks sein, die auf das Alter eines anderen Services zugreifen.

Der bisherige Windows-Agent ist an seine Grenzen gekommen. Zwar funktioniert er zuverlässig und ist an vielen Stellen im Einsatz, aber die Wartbarkeit und Erweiterbarkeit sind kompliziert. Das Team um Matthias Kettner war schon lange auf der Suche nach einem reinen Windows Entwickler, der den Windows Client supporten und weiterentwickeln kann. Im letzten Jahr ist Sergey zum Team gestoßen und hat sich diesem Part angenommen. Anstatt den alten Windows Client zu modernisieren, ist die wesentlich bessere Entscheidung gefallen, von null anzufangen.

So steht mit der Version 1.6 ein komplett neuer Windows Agent zur Verfügung, der in C++ geschrieben ist und nativ gegen die Microsoft APIs arbeitet. Mit diesem neuen Agenten steht nun dem ehrgeizigen Plan, das beste Windows Monitoring, das es gibt, anzubieten, nichts mehr im Wege.

Herr Kettner stellte eine eher verspielt wirkende neue Visualisierungsmöglichkeit für Auswertungen der Business-Intelligence (BI) vor. Statt die Informationen in einer statischen Tabelle zu haben, sollten diese in flexiblen Knoten-Graphen dargestellt werden. Diese Ansicht ist unserer Meinung eher für Abhängigkeits- und Beziehungsdarstellung nützlich, nicht so sehr für eine Visualisierung einer BI.

Überwachung dynamischer Umgebungen

Die Überwachung von dynamischen Umgebungen war bisher nur über Umwege möglich. Mit dem Dynamic Configuration Daemon (DCD) wird dies nun vereinfacht. Dieser läuft parallel zum Check_MK-Microcore (CMC) und erstellt dynamisch neue Konfigurationen, welche anschließend vom CMC „on the fly“ geladen werden. Als Datenquelle dienen z. B. Docker Container, Kubernetes Pods oder Cloud-Dienste. Der Intervall für die Synchronisierung der Piggyback-Daten kann dabei frei gewählt werden. Die eigentliche Generierung der Konfiguration dauert meist nur einen Bruchteil einer Sekunde. In verteilten Umgebungen kann die Latenzzeit der Synchronisierung - und somit die Generierung der Konfiguration - steigen. Für die Zukunft wird daher über ein Push-Mechanismus nachgedacht.

Überwachung von Cloud-Diensten

Wie schon auf der letzten Konferenz ist das Monitoring von Cloud-Diensten ein großes Thema. Im Focus stehen dabei die Amazon Web Services (AWS) sowie Microsoft Azure. Für diese Umgebungen wurde der Dynamic Configuration Daemon (DCD) entwickelt, welcher zwei Aufgaben erfüllt: Das Erstellen von neuen Hosts aus Piggyback-Daten sowie das automatische Erkennen von neuen Services. Zu diesem Zweck wurden für AWS sowie Azure neue Spezial-Agenten entwickelt.

IT-Bedarf mit Check_MK planen

Um den IT-Bedarf planen zu können, werden Informationen über die vorhandenen Systeme benötigt. Der optimale Zustand wäre, die Auslastung aller Systeme nicht zu hoch und gleichzeitig nicht zu gering zu halten. Eine zu hohe Auslastung kann zu Problemen in der Infrastruktur führen, eine zu geringe Auslastung verursacht zu hohe Kosten. Check_MK liefert mit der Business Intelligence und den kombinierten Graphen bereits eine gute Grundlage an Daten. Es wurde gezeigt, wie sich mit diesen Daten in Kombination mit der Trendberechnung, noch genauere Voraussagen über Spitzenwerte oder Flaschenhälse finden lassen.

i-doit

Das Thema IT-Dokumentation spielt eine wichtige Rolle in großen sowie in kleinen Unternehmen. Hierfür wurde von den i-doit-Entwicklern eine Schnittstelle zwischen dem CMDB-System und Check_MK geschaffen: das Modul Check_MK 2. Damit lassen sich nicht nur neue Hosts in i-doit erstellen, es können ebenfalls Inventory-Daten geladen oder Aggregationen durchgeführt werden. Die Kommunikation läuft dabei über die in Check_MK eingebaute API. Für alle Aktionen existiert das Kommandozeilen-Tool idoitcmk. Dieses eignet sich auch ideal um Prozesse, wie z. B. einen Abgleich der Daten, zu automatisieren.

Integration Grafana und Check_MK

Monitoring-Daten sollten nicht nur erhoben, sondern auch auf geeignete Weise visualisiert werden. Eine sehr gute Ergänzung bietet die vorgestellte Open Source Software Grafana mit direkter Schnittstelle zu Check_MK. Damit können erhobene Daten nicht nur visualisiert, sondern auch korreliert werden. Bisher musste der CMC die Daten aus Check_MK in eine InfluxDB schreiben. Diese wurde wiederum von Grafana ausgelesen. Hinzugekommen ist jetzt der direkte Zugriff von Grafana auf Check_MK über die eingebaute API. Dies bietet einigen Umgebungen den Vorteil, dass die InfluxDB nicht benötigt wird. Alternativ kann Check_MK eine zusätzliche Datenquelle für die bestehende Visualisierung sein.

Automatisierung des Monitorings bei Agfa

Je größer die Umgebung, desto aufwendiger wird es, das Monitoring zu pflegen. Daher ist es ab einem bestimmten Punkt sinnvoll, einige oder mehrere Prozesse zu automatisieren. Neben der Automatisierung des Monitorings mit Ansible, wurde mit dem SaltStack eine weitere interessante Möglichkeit vorgestellt. Salt bietet einen gravierenden Vorteil für heterogene Systeme. So bringt es nicht nur für Linux und Windows, sondern auch für AIX und Solaris Systeme eine eigene Python-Umgebung mit. Salt arbeitet nach dem Client-Server-Prinzip indem ein Agent, auch genannt Minion, auf den Zielsystemen installiert wird. Dieser schickt anschließend einen Report an den Server mit der vorhandenen Konfiguration des Systems. Fehlt nun der Check_MK-Agent oder liegt dieser in einer veralteten Version vor, bekommt der Minion vom Server die Anweisung, diesen zu installieren, bzw. auf den aktuellen Stand zu bringen.

Ausblick

Bisher war das Entwickeln neuer Checks stark vom Wissen abhängig, was Check_MK mit diesen Dateien machen wird. Die Objekte, die gefüllt werden können, sind nicht ganz klar, die Rückgabetypen auch nicht fest und verständlich. So war zur Entwicklung eines neuen Checks häufig der Blick in vorhandene Checks, die ähnliche Aufgaben haben, der einfachste Weg zum Ziel.

Begonnen wurde mit ca. 30 Checks, heute sind es 1.700 (offizielle) Checks und diese nutzen immer noch die alte API. Diesem Problem möchte sich das Team nun annehmen und für die Version 1.7 eine komplett neue Check API anbieten. Hierfür müssen allerdings viele der vorhandenen Checks überarbeitet werden.

Damit es bei den Checks nicht langweilig wird, wird parallel mit der Einführung der neuen Check API auch die Python-Version aktualisiert. Lange Zeit war Python 2.7 bei Check_MK gesetzt und diese Version wurde letztlich auch von Check_MK mit ausgeliefert. Aber mit der Version 1.7 soll dieses Thema endlich angegangen und die Python-Version auf 3 angehoben werden. Probleme wird es allerdings mit dem Übergang geben. So wird die Python-Version 2.7 noch eine Weile parallel betrieben werden müssen.

Bedingt durch die stark gewachsene Mitarbeiterzahl kann das Team auch eine große Menge auf die Roadmap setzen. Daher werden die Themen hier nur kurz angeschnitten:

• Beim Monitoring werden die Schwerpunkte auf Kubernetes, AWS, Azure und Netzwerkequipment gelegt.
• Die bereits angesprochenen Verbesserungen für den User werden fertiggestellt. Hinzu kommen dynamischere Dashboards.
• Neue Features kommen vor allem im Capacity Management und der Anomalie-Erkennung.
• Für die weitere Integration der Software in andere Umgebungen wird die REST API erweitert.

Bei Interesse kann die komplette Roadmap eingesehen werden.