Glossar

Ein Agent sammelt die für das Monitoring relevanten Daten von einem Host ein. Das kann ein kleines, auf dem Host installiertes Programm sein (der Checkmk-Agent), ein unabhängig von Checkmk auf dem Host laufender SNMP-Agent, ein Spezialagent, der sich die Informationen über eine vom Zielsystem bereitgestellte API besorgt — oder ein aktiver Check, der netzwerkbasierte Dienste abfragt.

Mehr unter Monitoring-Agenten.

Der Agent Updater ist ein Agentenplugin in den kommerziellen Editionen, das die automatischen Aktualisierungen der Agenten ermöglicht.

Mehr unter Automatische Agenten-Updates.

Mit der Agentenbäckerei (englisch: agent bakery) können Agenten in den kommerziellen Editionen individuell paketiert und optional auch automatisch verteilt werden.

Mehr unter Die Agentenbäckerei.

Ein Agentenplugin erweitert die Funktionen des standardmäßig ausgelieferten Checkmk-Agenten. Es ist ein kleines Programm oder Skript, das vom Checkmk-Agenten aufgerufen wird und die Ausgabe des Agenten um weitere Sektionen mit zusätzlichen Monitoring-Daten anreichert. Ein Beispiel für ein Agentenplugin ist der Agent Updater.

Mehr unter Agent um Plugins erweitern.

Ein aktiver Check ist ein kleines Programm oder Skript, das eine direkte Verbindung zu einem Dienst im Netzwerk oder Internet aufbaut und von dort die Monitoring-Daten abfragt. Aktive Checks werden für netzwerkbasierte Dienste wie HTTP, SMTP oder IMAP genutzt, z.B. check_http für das Abfragen von Webseiten. Ein aktiver Check kümmert sich sowohl um die Erhebung als auch um die Auswertung der Daten. Im Gegensatz dazu wird ein Check-Plugin manchmal auch als passiver Check bezeichnet, da es nur vorhandene Daten auswertet.

Mehr unter Netzwerkdienste überwachen (Aktive Checks).

Änderungen an der Konfiguration wirken sich erst auf das Monitoring aus, nachdem sie in einem zweiten Schritt aktiviert wurden; ähnlich, wie es zum Beispiel Partitionierungsprogramme handhaben: Konfigurieren, prüfen, anwenden.

Mehr unter Änderungen aktivieren.

Wenn im Setup von Checkmk von API integrations die Rede ist, sind Monitoring-Daten gemeint, die zwar das Datenformat des Checkmk-Agenten nutzen, aber aus einer anderen Quelle stammen. Solche Quellen können Datenquellenprogramme, Spezialagenten oder Hosts sein, die ihre Daten per Piggyback (huckepack) liefern. Sollen per API-Integration empfangene Daten im Monitoring verwendet werden, muss in den Eigenschaften eines Hosts API integrations aktiviert sein.

Mehr unter Datenquellenprogramme.

Spezielles Konto für die Abfrage und Konfiguration von Checkmk abseits der Weboberfläche, also zum Beispiel über API, Kommandozeile, Skript oder Webdienst. Ein Automationsbenutzer hat standardmäßig ein zufällig ausgewürfeltes Automationspasswort (englisch automation secret). In einer frischen Checkmk-Instanz sind zwei Automationsbenutzer bereits eingerichtet: für Webdienste und für die Registrierung des Agenten beim Checkmk-Server zur TLS-verschlüsselten Datenübertragung.

Mehr unter Automationsbenutzer (für Webdienste).

Mit einer Benachrichtigung (englisch: notification) wird ein Checkmk-Benutzer über Probleme oder andere Monitoring-Ereignisse aktiv informiert, per HTML-E-Mail, SMS, Slack oder ähnlichem. Wer wie benachrichtigt wird, legen die Benachrichtigungsregeln fest. Wenn zum Beispiel Herr Hirsch eine E-Mail mit der Information erhält, dass der Service Filesystem / auf dem Host myserver123 von WARN nach CRIT gewechselt ist, dann deshalb, weil Herr Hirsch Kontakt für diesen Host ist und in einer Benachrichtigungsregel steht, dass alle Kontakte des Hosts eine E-Mail erhalten sollen, wenn einer seiner Services nach CRIT wechselt.

Mehr unter Benachrichtigungen.

Business Intelligence in Checkmk ermöglicht es, aus vielen einzelnen Statuswerten den Gesamtzustand einer übergeordneten Ebene abzuleiten und übersichtlich darzustellen. Das kann die abstrakte Gruppierung einzelner Komponenten oder eine geschäftskritische Anwendung sein. So lässt sich etwa der Zustand einer Anwendung E-Mail, bestehend aus diversen Hosts, Switches und Diensten wie SMTP und IMAP, über eine einzige Visualisierung erfassen. Auch die Formulierung gänzlich ungreifbarer und nicht-technischer Belange ist hier möglich, zum Beispiel die termingerechte Verfügbarkeit eines auszuliefernden Produkts: Dieses Ziel liegt in der Zukunft und hängt von vielen Aspekten ab, der Supply Chain, einem funktionierenden Maschinenpark, verfügbarem Personal etc. Etwaige Gefährdungen für dieses abstrakte Ziel ließen sich über das BI-Modul erfassen.

Mehr unter Business Intelligence (BI).

Ein Check im Sinne von Checkmk ist ein Skript oder Programm, das einen Host oder Service gemäß erstellter Regeln prüft, also der Vorgang, der den Status von Hosts und Services bestimmt und zu einem der folgenden Ergebnisse führt: OK, DOWN, UNREACH, WARN, CRIT, PEND oder UNKNOWN. Checks können zum Beispiel mit einem Check-Plugin, lokalen Check oder aktiven Check implementiert werden.

Mehr unter Checks.

Check-Plugins sind in Python geschriebene Module, die auf der Checkmk-Instanz ausgeführt werden und die Services eines Hosts erstellen und auswerten. Ein Beispiel: Das Check-Plugin df, zu finden innerhalb einer Instanz unter ~/local/lib/python3/cmk_addons/plugins/<plug-in_family>/agent_based/ (bei Nutzung der Check-API V2) oder ~/local/lib/check_mk/base/plugins/agent_based/ (bei Nutzung der Check-API V1), erstellt aus den Daten eines Agenten in der Instanz Services für die vorhandenen eingebundenen Dateisysteme eines Hosts und überprüft diese Services anhand der Daten, also etwa wie viel freien Speicherplatz es noch gibt.

Mehr über Check-Plugins.

MKP ist das Checkmk-eigene Dateiformat zum Zusammenfassen und Verteilen von Erweiterungen, also eigenen Check-Plugins, Agentenplugins, Zeitreihen-Graph-Definitionen, Benachrichtigungsskripten, Tabellenansichten, Dashboards und so weiter.

Mehr unter Checkmk-Erweiterungspakete (MKPs).

Ein Dashboard ist eine frei konfigurierbare Übersicht, bestehend aus Tabellenansichten und/oder so genannten Dashboard-Elementen (englisch: dashlet). Diese Elemente gibt es zum Beispiel in Form von Listen (etwa Host-Probleme), Zeitreihen-Graphen oder kleinen Tachometern, die einzelne Werte wie etwa eine CPU-Temperatur visualisieren.

Mehr unter Dashboards.

Checkmk-Editionen sind die unterschiedlichen Software-Varianten von Checkmk, die geladen und installiert werden können. Also die Open Source Checkmk Raw, für professionelle Anwender die per Subskription erhältliche Checkmk Enterprise, die darauf aufbauende Checkmk Cloud sowie die mandantenfähige Checkmk MSP. In dieser Reihenfolge enthält jede Edition den kompletten Funktionsumfang der vorher genannten Edition — und erweitert diesen um spezifische Zusatzfunktionen. So ist zum Beispiel Checkmk Cloud eine für Cloud-Umgebungen ausgebaute und optimierte Checkmk Enterprise.

Mehr unter Edition auswählen.

Bei der Überwachung von Hosts und Services geht es in Checkmk um Zustände. Die Event Console ist das Modul, das sich im Gegensatz dazu um Ereignisse kümmert, also die Überwachung aus Quellen wie Syslog oder SNMP-Traps, aber optional auch Windows Event Log, Log-Dateien und eigenen Anwendungen. Ein Beispiel: Eine Warnmeldung des SMTP-Dienstes auf einem Mailserver würde weder den Status/Zustand von dessen Host noch Services ändern — dennoch ist es eine relevante Information, die ins Monitoring gehört. Mit der Event Console können solche Ereignisse in Checkmk dargestellt werden.

Mehr unter Die Event Console.

Ein Host im Sinne von Checkmk ist jedes eigenständige, physische oder virtuelle System, das von Checkmk überwacht wird. In der Regel handelt es sich um Dinge mit eigener IP-Adresse (Server, Switches, SNMP-Geräte, virtuelle Maschinen), aber auch um beispielsweise Docker Container oder andere logische Objekte ohne eine solche Adresse. Jeder Host hat immer einen der Zustände UP, DOWN, UNREACH oder PEND und immer mindestens einen Service.

Noch weiter heruntergebrochen: Ein Host ist für Checkmk intern lediglich ein Strukturierungselement, das zu überwachende Elemente beinhaltet, also Services. Jeder Host hat zwangsläufig mindestens einen Service, um überhaupt die Erreichbarkeit zu verifizieren (etwa PING oder der Checkmk-Agent selbst, also der Service Check_MK). Insofern meint Host kaum mehr als die Überschrift, unter der eine Anzahl an Services gruppiert ist.

Mehr unter Verwaltung der Hosts.

Hosts werden in Checkmk primär über Ordner verwaltet. Host-Gruppen ermöglichen eine andere Gruppierung von Hosts, um Hosts im Monitoring z.B. in Tabellenansichten auswählen zu können. Host-Merkmale, Labels und Ordner werden genutzt, um Hosts über Regeln solchen Gruppen zuzuordnen. Hosts können aber auch explizit einer Host-Gruppe zugeordnet werden.

Mehr unter Host-Gruppen

Host-Merkmale (englisch: host tags) sind Kennzeichen, die Hosts zugeordnet werden können, um diese in der Konfiguration für Regeln oder später im Monitoring für Tabellenansichten gezielt ansprechen zu können. Host-Merkmale sind in Gruppen eingeteilt, beispielsweise lässt sich eine Merkmalsgruppe Betriebssysteme mit den Merkmalen Linux und Windows einrichten. Einige Merkmalsgruppen sind bereits vordefiniert, etwa zur Art des verwendeten Checkmk-Agenten oder zur IP-Adressfamilie, über die festgehalten wird, ob ein Host über IPv4, IPv6 oder beide Versionen überwacht werden soll. Sie haben außerdem vorher festgelegte Werte und einen Standard, welcher jedem Host zugeordnet ist, solange er nicht mit einer anderen Option aus der Gruppe überschrieben wurde.

Mehr unter Host-Merkmale.

Der Zustand eines Hosts, also ob dieser über das Netz erreichbar ist (UP), nicht auf Anfragen aus dem Netz antwortet (DOWN) oder ob der Weg durch ausgefallene zwischengeschaltete Geräte (Switches, Router etc.) versperrt ist (UNREACH). Für frisch ins Monitoring aufgenommene, noch nie abgefragte Hosts gibt es zudem den Zustand PEND, welcher aber kein Status im eigentlichen Sinne ist.

Mehr unter Hosts und Services.

Instanz (englisch: site) nennt sich ein laufendes Checkmk-Monitoring-Projekt. Checkmk lässt sich parallel auf demselben Server in mehreren, unabhängigen Instanzen betreiben, um beispielsweise unterschiedliche Checkmk-Versionen oder -Editionen auszuprobieren oder ein separates Monitoring für (neue) Hosts zu betreiben, die (noch) nicht ins produktive Monitoring aufgenommen werden sollen.

Mehr unter Eine Instanz erstellen.

Die Checkmk-Weboberfläche teilt sich auf in Monitoring- und Konfigurationsumgebung. Letztere bezeichnet die Bereiche, in denen Regeln gebaut, Host und Services hinzugefügt und eingestellt, Benutzer verwaltet oder generelle Optionen gesetzt werden. Zur Konfigurationsumgebung geht es über das Setup-Menü in der Navigationsleiste.

Mehr unter Die Benutzeroberfläche.

Kontakte werden Checkmk-Benutzer genannt, die für bestimmte Hosts und Services zuständig sind. Die Zuordnung von Kontakten zu Hosts und Service geschieht über Kontaktgruppen. Kontakte können auch Benutzerkonten sein, die rein für die Benachrichtigungen existieren, beispielsweise für die Weiterleitung an ein Ticketsystem.

Mehr unter Kontaktgruppen.

Hosts können mit vordefinierten Host-Merkmalen, aber auch mit direkten Kennzeichen, den Labels, versehen werden. Ein Label besteht aus zwei Teilen (Schlüssel und Wert), getrennt durch einen Doppelpunkt. Solche beliebigen Schlüssel-Wert-Paare (os:linux, os:windows, foo:bar etc.) können bei einem Host direkt gesetzt werden — ohne jede vorherige Konfiguration, wie es bei den Host-Merkmalen nötig ist. Labels verfügen daher über keinen vorher definierten Umfang und haben auch keinen Standardwert, sind dafür aber sehr dynamisch. Insbesondere kann Checkmk von Containersystemen wie Kubernetes, Azure oder AWS automatisch erzeugte Objekte selbständig als Hosts ins Monitoring übernehmen und diese dann mit automatisch aus deren Metadaten generierten Labels anreichern. Label lassen sich z. B. für die Auswahl von Bedingungen in Regeln oder im Monitoring für die Filterung in Tabellenansichten nutzen.

Mehr unter Labels.

Livestatus ist die wichtigste Schnittstelle in Checkmk. Durch sie bekommen Checkmk-Benutzer schnellstmöglich und live Zugriff auf alle Daten der überwachten Hosts und Services. So werden z.B. die Daten im Snapin Overview direkt über diese Schnittstelle abgerufen. Dass die Daten direkt aus dem RAM geholt werden, vermeidet langsame Festplattenzugriffe und gibt einen schnellen Zugriff auf das Monitoring, ohne das System zu sehr zu belasten.

Mehr unter Statusdaten abrufen via Livestatus.

Ein lokaler Check ist eine (selbst geschriebene) Erweiterung, die in Form eines Skripts in einer beliebigen Sprache auf dem überwachten Host läuft. Im Gegensatz zu normalen Checks läuft die Statusberechnung direkt auf dem Host. Die Ergebnisse werden der regulären Agentenausgabe hinzugefügt.

Mehr unter Lokale Checks.

Mess- und berechenbare Werte zu Hosts und Services in ihrem zeitlichen Verlauf, etwa Temperatur, Auslastung oder Verfügbarkeit, die beispielsweise für Graphen herangezogen werden können. Vergangene Werte werden in RRDs (Round-Robin-Datenbank) gespeichert und halten diese in der Standardeinstellung bis zu 4 Jahre vor.

Mehr unter Messwerte und Graphing.

Die Checkmk-Weboberfläche teilt sich auf in Monitoring- und Konfigurationsumgebung. Erstere bezeichnet die Bereiche, in denen der Status der überwachten Infrastruktur angezeigt wird; dazu zählen etwa das Inventar, Dashboards, Listen mit Hosts, Services, Ereignissen oder Problemen, historische Daten und so weiter. Zur Monitoring-Umgebung geht es über das Monitor-Menü in der Navigationsleiste.

Mehr unter Die Benutzeroberfläche.

Die Navigationsleiste ist die Hauptnavigation der Checkmk-Oberfläche, auf der linken Seite u.a. mit den Menüs Monitor, Setup und Customize.

Mehr unter Navigationsleiste.

Die physische Appliance ist ein 19"-Server mit einer vorinstallierten, für Checkmk vorbereiteten Firmware, der sofort in Rechenzentren eingesetzt werden kann. Sie kommt mit einer grafischen Konfigurationsoberfläche, die jegliche Linux-Kenntnisse überflüssig macht.

Mehr unter Physische Appliance.

Manche Hosts im Monitoring werden nicht direkt abgefragt, weil es sich nicht um physischen Geräte, sondern virtuelle Maschinen oder Container handelt, oder die Daten nur von einem Drittsystem bereitgestellt werden können. Diese Drittsysteme (die physischen Gastgeber) liefern die Daten quasi als Anhang in ihrer eigenen Agentenausgabe mit. Ein Docker-Server würde also zum Beispiel neben den eigenen Daten die Daten der Container huckepack (englisch: piggyback) mitliefern.

Mehr unter Der Piggyback-Mechanismus.

Im Pull-Modus lauscht der Checkmk-Agent am TCP-Port 6556 auf eingehende Verbindungen vom Checkmk-Server. Sobald der Agent eine Aufforderung erhält, schickt er die Monitoring-Daten an den Server. Hier geht die Initiative zur Datenübertragung vom Server aus, der die Daten vom Agenten quasi heranzieht. Der Pull-Modus ist der Standardweg zur Datenübertragung vom Checkmk-Agenten — und funktioniert in allen Checkmk-Editionen.

Mehr unter Der Checkmk-Agent.

Im Push-Modus sendet der Checkmk-Agent minütlich die Monitoring-Daten an den Checkmk-Server. Der Agent stößt also die Datenübertragung von sich aus an und wartet nicht auf eine Aufforderung des Servers. Der Push-Modus ist immer dann erforderlich, wenn der Checkmk-Server nicht auf das Netzwerk zugreifen kann, in dem sich der zu überwachende Host mit seinem Agenten befindet, also z.B. in einer Cloud-basierte Konfiguration. Daher gibt es den Push-Modus nur ab Checkmk Cloud, d. h. für Checkmk Cloud und Checkmk MSP.

Mehr unter Der Checkmk-Agent.

Regeln sind die Grundlage der Konfiguration von Hosts und Services in Checkmk. Regeln in einem Regelsatz steuern immer einen einzelnen, fokussierten Aspekt eines Hosts oder Services. Sie lassen sich mit Bedingungen versehen, sowie innerhalb eines Regelsatzes beliebig aufeinander "stapeln". Die Auswertung erfolgt dann von oben nach unten, so dass es Standardregeln geben kann, wenn keine Bedingung greift, aber auch sehr spezielle Regeln, die nur einen ganz bestimmten Host betreffen. Viele Regelsätze in Checkmk haben bereits vordefinierte Standardwerte, so dass nur für abweichende Anforderungen Regeln erstellt werden müssen.

Mehr unter Regeln.

Ein Regelsatz steht für einen bestimmten Aspekt eines Hosts oder Services, beispielsweise die Schwellwerte der CPU-Auslastung. In jedem Regelsatz können beliebig viele einzelne Regeln erstellt werden. So könnte etwa der Regelsatz CPU utilization on Linux/UNIX zwei Regeln enthalten, die den Service auf bestimmten Hosts bei 90 Prozent und auf anderen schon bei 70 Prozent auf den Status WARN setzen.

Mehr unter Arten von Regelsätzen.

Die Seitenleiste (englisch: sidebar) lässt sich aus der Navigationsleiste per Mausklick einblenden. In die Seitenleiste können Benutzer diverse Snapins aufnehmen, die die Navigation erleichtern oder wichtige Statusdaten auf einen Blick zeigen.

Mehr unter Seitenleiste.

Ein Service ist ein logisches Objekt, welches einen oder mehrere Teilaspekte eines Hosts zusammenfasst. Also beispielsweise Größe, Auslastung und Trends von Dateisystemen, CPU-Auslastung, Temperaturen, Alter und Anzahl laufender Programme, Ports, Sensoren und so weiter. Jeder Service im Monitoring hat zu jedem Zeitpunkt einen der Zustände OK, WARN, CRIT, UNKNOWN oder PEND, ist immer genau einem Host zugeordnet und enthält optional eine oder mehrere Metriken.

Mehr unter Services verstehen und konfigurieren.

Sobald ein Host dem Monitoring hinzugefügt wird, erkennt Checkmk automatisch alle verfügbaren Services, die ins Monitoring aufgenommen werden können — und hält diese Liste auch im laufenden Betrieb stets aktuell. Die Service-Erkennung (englisch: service discovery) lässt sich aber auch jederzeit manuell über die Konfiguration eines Hosts starten.

Mehr unter Services verstehen und konfigurieren.

Analog zu den Hosts lassen sich auch Services in Gruppen zusammenfassen, um diese Gruppen später in Tabellenansichten zu filtern oder in der Konfiguration gezielt anzusprechen. Gruppieren lässt sich nach Ordnern, Host-Merkmalen, Host- und Service-Labels sowie via regulären Ausdrücken gefilterten Host- und Service-Namen.

Mehr unter Service-Gruppen.

Der Service-Zustand ist immer OK WARN, CRIT oder UNKNOWN und beschreibt, in welchem Zustand sich der Service aktuell befindet — gemäß den gesetzten Regeln. Für frisch ins Monitoring aufgenommene, noch nie abgefragte Services gibt es zudem den Zustand PEND, welcher aber kein Status im eigentlichen Sinne ist.

Mehr unter Services.

Snapins, auch Seitenleistenelemente genannt, sind die einzelnen Bausteine, die sich in der Seitenleiste platzieren lassen, beispielsweise Overview und Master control. Zugriff auf die Snapins liefert das Plus-Symbol unten in der Seitenleiste.

Mehr unter Seitenleiste.

Das „Simple Network Management Protocol“ dient der Überwachung und Konfiguration von Netzwerkgeräten wie Routern, Switches oder Firewalls. Checkmk unterstützt dieses Protokoll — da es aber vergleichsweise ineffizient ist, sollten Sie SNMP nur bei Geräten einsetzen, die keine besseren Möglichkeiten zur Überwachung anbieten, wie beispielsweise Spezialagenten.

Mehr unter SNMP.

Auf einigen Systemen lässt sich der reguläre Checkmk-Agent nicht installieren und SNMP steht nicht (befriedigend) zur Verfügung. Stattdessen bieten diese Systeme Management-APIs, die auf Telnet, SSH oder HTTP/XML basieren. Über einen Spezialagenten, der auf dem Checkmk-Server läuft, fragt Checkmk diese Schnittstellen ab, womit der Host per API in Checkmk integriert wird.

Mehr unter Spezialagenten.

Neben den Dashboards sind die Tabellenansichten (englisch: views) die in der Checkmk-Oberfläche am häufigsten genutzten Darstellungen von Hosts, Services und anderen Objekten. Diese werden als Tabellen mit den im aktuellen Kontext relevanten Attributen angezeigt. Zum Beispiel sind All hosts und Host problems Tabellenansichten im Monitoring. Mitgelieferte Tabellenansichten können in ihrer Anzeige angepasst werden, und sie können als Basis für neue Ansichten dienen. Es ist auch möglich, Tabellenansichten komplett neu zu erstellen.

Mehr unter Ansichten von Hosts und Services (Views).

Checkmk unterscheidet zwischen verteiltem Monitoring und einem verteilten Setup. Verteiltes Monitoring bedeutet, dass das gesamte Monitoring-System aus mehr als einer Checkmk-Instanz besteht und die Daten an einer Stelle zusammen angezeigt werden. Oder anders: Das Monitoring besteht dann aus einer Zentralinstanz und mindestens einer Remote-Instanz und die Daten der Remote-Instanz werden auch in der Zentrale angezeigt. Ein verteiltes Monitoring kann optional mit einem verteilten Setup kombiniert werden.

Mehr unter Zentraler Status.

Checkmk unterscheidet zwischen verteiltem Monitoring und einem verteilten Setup. Verteiltes Setup bedeutet, dass das gesamte Monitoring-System aus mehr als einer Checkmk-Instanz besteht und die Konfiguration an einer einzigen Stelle vorgenommen wird. Oder anders: Das Monitoring besteht dann aus einer Zentralinstanz und mindestens einer Remote-Instanz und die Konfiguration der Remote-Instanz kommt aus der Zentrale. Ein Verteiltes Setup beinhaltet immer auch ein verteiltes Monitoring.

Mehr unter Zentrale Konfiguration.

Die virtuelle Appliance ist ein für VirtualBox oder VMware ESXi erstelltes System mit einer vorinstallierten, für Checkmk vorbereiteten Firmware. Sie beinhaltet eine grafischen Konfigurationsoberfläche, die jegliche Linux-Kenntnisse überflüssig macht.

Mehr unter Virtuelle Appliance.

Wartungszeiten (englisch: scheduled downtimes) sind geplante Ausfälle, etwa für Aktualisierungen bestimmter Hosts. Wartungszeiten setzen beispielsweise die Benachrichtigungen temporär außer Kraft, werden bei der Verfügbarkeitsberechnung extra berücksichtigt und sorgen dafür, dass zugehörige Hosts und Services zeitweilig nicht als Probleme auftauchen.

Mehr unter Wartungszeiten.

Das „Web Administration Tool“ war bis zur Checkmk-Version 1.6.0 das GUI-Werkzeug zur Konfiguration von Checkmk. Mit der Einführung von WATO hatten Benutzer erstmals die Möglichkeit, Checkmk über eine Weboberfläche statt über Konfigurationsdateien anzupassen. WATO wurde in der Version 2.0.0 ersetzt durch das Setup-Menü in der Navigationsleiste.

Mehr unter Setup-Menü.

Die Software-Entwicklung von Checkmk ist in sogenannten Werks organisiert. Jede Änderung, Fehlerbehebung oder Neuerung, die einen Einfluss auf die Erfahrung des Benutzers hat, wird in einem eigenen Werk erfasst, samt Hinweisen zu Auswirkungen und etwaigen Inkompatibilitäten. Die Liste der Werks gibt es direkt in Checkmk über das Help-Menü in der Navigationsleiste und auf der Checkmk-Homepage.

Mehr unter Werks.

In Checkmk lassen sich Dinge wie Benachrichtigungen, Verfügbarkeitsberechnungen und selbst die generelle Ausführung von Checks auf bestimmte, regelmäßig wiederkehrende Zeiträume beschränken. Mit Zeitperioden (englisch: time periods) lassen sich zum Beispiel tägliche Arbeitszeiten definieren, Urlaube und Feiertage festlegen oder Wochenenden von Wochentagen trennen. Diese Zeitperioden können anschließend in Regeln genutzt werden.

Mehr unter Zeitperioden.