Checkmk
to checkmk.com

Liebe Leserinnen und Leser,

wir freuen uns, dass Sie den Weg zu Checkmk gefunden haben — und dabei auch im Checkmk Handbuch vorbeischauen.

Der reibungslose Betrieb von IT-Systemen war schon immer eine Herausforderung. Sowohl die Komplexität der Hardware- und Software-Stacks als auch die Ansprüche der Anwender nehmen immer weiter zu — egal, ob sie mit echter Hardware oder mit Cloud-Lösungen arbeiten. So kommt einem detaillierten und umfassenden IT-Monitoring heute eine zentrale Rolle zu.

So komplex wie die IT-Welt sind natürlich auch die Anforderungen, die Anwender an ihr Monitoring stellen. Checkmk wurde von Anfang an für große und heterogene IT-Landschaften entwickelt. Deswegen bietet es eine Fülle von Funktionen und Möglichkeiten, um all den Problemstellungen gerecht zu werden, die daraus in der Praxis folgen. Daher ist der Umfang von Checkmk für einen Einsteiger erst mal überwältigend.

Damit Sie trotzdem schnell und bequem zu Ihrem ersten Checkmk-Monitoring kommen, haben wir das Checkmk Handbuch für Sie in zwei Teile untergliedert:

  1. einen Leitfaden für Einsteiger, den Sie gleich im Anschluss in diesem Artikel finden

  2. einen umfassenden Referenzteil für Experten, der den Rest des Handbuchs umfasst

Der Leitfaden für Einsteiger führt Sie Schritt für Schritt in Checkmk ein und ist so aufgebaut, dass Sie ihn zügig von Anfang bis Ende lesen und dabei gleich mitmachen können. Deswegen ist er auch kurz und knapp und hält sich nicht mit unnötigen Details auf. Am Ende des Leitfadens haben Sie ein praxisgerechtes Checkmk-System. Im letzten Kapitel zeigen wir Ihnen dann noch ein paar sehr nützliche Tipps und Tricks unserer erfahrenen Consultants, die sich in verschiedenen Checkmk-Installationen bewährt haben.

Natürlich lässt der Leitfaden für Einsteiger noch viele Fragen offen. Diese werden im ausführlichen Referenzteil des Handbuchs beantwortet. Dort finden Sie zu Themen, die wir im Leitfaden nur anreißen können, alle Hintergründe und Details um tiefer einzusteigen — auf Ihrem Weg vom Einsteiger zum Checkmk-Experten.

1. Checkmk aufsetzen

1.1. Edition auswählen

Bevor Sie beginnen, Checkmk zu installieren, müssen Sie sich zuerst entscheiden, welche der vier verfügbaren Editionen Sie einsetzen möchten:

Die CRE Checkmk Raw Edition (CRE) ist kostenlos, zu 100 % Open Source und enthält Nagios als Kern. Sie können damit komplexe Umgebungen umfassend überwachen. Support erhalten Sie in unserem Forum von der Checkmk-Community.

Die CFE Checkmk Enterprise Free Edition (CFE) ist für Sie die richtige, wenn Sie die Standard Edition unverbindlich testen wollen oder Checkmk im kleinen Rahmen mit bis zu zwei Instanzen mit je zehn überwachten Hosts einsetzen möchten. Die Free Edition enthält alle Features der Standard Edition und ist kostenlos. Sowohl die Free Edition als auch die Raw Edition können Sie später ohne Umwege direkt auf die Standard Edition upgraden.

Die CSE Checkmk Enterprise Standard Edition (CEE) richtet sich vor allem an professionelle Anwender und bietet über den Umfang der Raw Edition hinaus eine Reihe von interessanten Features, wie z.B. statt Nagios mit dem Checkmk Micro Core (CMC) einen sehr performanten eigenen Kern, ein Reporting, ein ausgefeiltes System für die Visualisierung von Messwerten, eine flexible Agentenverteilung und vieles mehr. Für die Standard Edition können Sie optional von uns oder einem unserer Partner professionellen Support erhalten.

Die CME Checkmk Enterprise Managed Services Edition (CME) ist eine mandantenfähige Erweiterung der Standard Edition und verfügt über alle notwendigen Funktionen, um mit Checkmk über das verteilte Monitoring voneinander abgeschottete Instanzen für mehrere Kunden zu betreiben. Falls Sie für Ihre Kunden diese Dienste anbieten wollen, ist diese Ihre Edition. Genaueres zum Konzept der Managed Services finden Sie in der Einführung dieses Artikels.

Eine Aufstellung der Unterschiede zwischen den Editionen finden Sie auf unserer Homepage.

CEE Wann immer wir in diesem Handbuch Funktionen besprechen, die nur für eine der Enterprise Editions gelten — also für die CEE, CFE oder CME — kennzeichnen wir dies mit dem Symbol wie in diesem Absatz.

1.2. Version auswählen

Wir entwickeln alle Editionen von Checkmk ständig weiter, und daher gibt es von jeder Edition verschiedene Versionen. Für den Einstieg empfehlen wir Ihnen grundsätzlich die jeweils neueste stabile Version. Einen detaillierten Überblick, welche Arten von anderen Versionen es außerdem gibt, zeigt dieser Artikel.

1.3. Die Software installieren

Der Checkmk-Server benötigt grundsätzlich ein Linux-System, auf dem er laufen kann. (Sie können natürlich trotzdem auch Windows und andere Betriebssysteme überwachen.) Wenn Sie keinen eigenen Linux-Server aufsetzen möchten, können Sie Checkmk auch mithilfe von Docker oder einer Appliance betreiben. Insgesamt gibt es vier Möglichkeiten, die wir im folgenden kurz vorstellen und die auf unterschiedliche Weise zu installieren sind. Wenn Sie die Installation Ihrer Variante abgeschlossen haben, lesen Sie im nächsten Kapitel weiter, in der es um die Erstellung einer Instanz geht.

Möglichkeit 1: Linux-Server

Die Installation von Checkmk auf einem Linux-Server, egal, ob auf einer „echten“ oder auf einer virtuellen Maschine, ist der Standardfall. Wenn Sie über Linux-Grundkenntnisse verfügen, ist die Installation sehr einfach. Die komplette Software, die Sie benötigen, ist entweder in Ihrer Linux-Distribution oder in unserem Checkmk-Paket enthalten.

Checkmk unterstützt die Distributionen von Red Hat/CentOS, SLES, Debian und Ubuntu. Für jede Checkmk-Edition, Checkmk-Version und Linux-Distribution gibt es ein eigenes angepasstes Paket von uns, das Sie mit dem Paketmanager Ihrer Linux-Distribution installieren können. Wie dies genau geht, erfahren Sie im Artikel zur Installation auf Linux-Systemen.

Möglichkeit 2: Virtuelle Appliance

Mit der virtuellen Appliance Checkmk virt1 erhalten Sie eine komplett eingerichtete virtuelle Maschine im Dateiformat OVA (Open Virtualization Archive), die Sie in einem Hypervisor wie zum Beispiel VirtualBox oder VMware vSphere ESXi verwenden können.

Die virtuelle Appliance enthält neben Checkmk auch das Linux-Betriebssystem Debian 9 (Stretch). Der Vorteil der Appliance ist, neben einem vorinstalliertem System, dass Sie Betriebssystem und Checkmk komplett über eine grafische Oberfläche konfigurieren können, ohne die Linux-Kommandozeile bemühen zu müssen. Dies umfasst auch den Update von Betriebssystem und Checkmk.

CEE Die virtuelle Appliance ist für alle Enterprise Editions verfügbar, für die Free Edition als kostenlose Demo-Version. Wie Sie bei der Installation vorgehen müssen, erfahren Sie in der Schnellstart-Anleitung.

Möglichkeit 3: Physische Appliance

Einen Schritt weiter können Sie mit der physischen Appliance (auch Hardware Appliance genannt) gehen, in der Checkmk fertig vorinstalliert und sofort einsetzbar auf einem Gerät geliefert wird, um es zum Beispiel direkt in Ihrem Rechenzentrum einzubauen. Zwei physische Appliances können Sie mit wenigen Handgriffen zu einem Hochverfügbarkeits-Cluster (HA-Cluster) zusammenschalten.

CEE Die physische Appliance gibt für die Standard Edition und Managed Services Edition. Sie können zwischen mehreren Modellen mit verschiedenen Wartungsstufen wählen. Die Anleitung zur Inbetriebnahme finden Sie in der Schnellstart-Anleitung.

Möglichkeit 4: Docker-Container

Wenn Sie Checkmk mithilfe eines Docker-Containers bereitstellen wollen, haben Sie auch diese Möglichkeit. Dabei unterstützen wir sowohl die Raw Edition als auch die Enterprise Editions mit fertigen Container-Images, die mit wenigen Kommandos eingerichtet sind.

Die Anleitung dazu finden Sie im Artikel zur Installation als Docker-Container.

1.4. Eine Instanz erstellen

Checkmk hat eine Besonderheit, die Ihnen zu Beginn vielleicht unwichtig erscheint, die sich in der Praxis aber als sehr nützlich herausgestellt hat: Sie können auf einem Server mehrere unabhängige Instanzen (sites) von Checkmk parallel betreiben. Dabei kann sogar jede Instanz mit einer anderen Version von Checkmk laufen.

Hier sind zwei häufige Anwendungen für dieses gut durchdachte Feature:

  • unkompliziertes Ausprobieren einer neuen Checkmk-Version

  • Parallelbetrieb einer Testinstanz zum Überwachen von Hosts, die noch nicht operativ sind

Wenn Sie Checkmk gerade auf einem Linux-Server installiert haben, kommt es noch komplett ohne Instanzen daher. Wir zeigen Ihnen in diesem Kapitel, wie Sie nach einer Software-Installation von Checkmk auf einer Linux-Distribution eine Instanz anlegen.

Hinweis: Checkmk-Appliances werden über eine Web-Oberfläche administriert, die auch das Anlegen von Instanzen abdeckt. Dies wird im Artikel über die Appliance erklärt. Falls Sie Checkmk in einem Docker-Container betreiben, wird für Sie automatisch während der Installation eine Instanz angelegt.

Wählen Sie zunächst einen Namen für Ihre Instanz. Diese darf nur aus Buchstaben und Ziffern bestehen. Konvention sind dabei Kleinbuchstaben. Im Handbuch verwenden wir in allen Beispielen den Namen mysite. Ersetzen Sie diesen Namen mit Ihren eigenen Instanznamen.

Das Anlegen selbst geht sehr einfach. Geben Sie einfach als root den Befehl omd create, gefolgt vom Namen der Instanz ein:

root@linux# omd create mysite
Adding /opt//omd/sites/mysite/tmp to /etc/fstab.
Creating temporary filesystem /omd/sites/mysite/tmp...OK
Updating core configuration...
Generating configuration for core (type cmc)...Creating helper config...OK
OK
Restarting Apache...OK
Created new site mysite with version 2.0.0i1.cee.

  The site can be started with omd start mysite.
  The default web UI is available at linux/mysite/

  The admin user for the web applications is cmkadmin with password: [hilite]#ZBdHdkl2*
  For command line administration of the site, log in with 'omd su mysite'.
  After logging in, you can change the password for cmkadmin with 'htpasswd etc/htpasswd cmkadmin'.

Beim Anlegen einer neuen Instanz passieren die folgenden Dinge:

  • Es werden ein Linux-Benutzer (ohne Passwort) und eine Linux-Gruppe angelegt, die den Namen der Instanz tragen. Der Benutzer wird Instanzbenutzer (site user) genannt.

  • Für die Instanz wird ein Home-Verzeichnis unterhalb von /omd/sites angelegt, z.B. /omd/sites/mysite.

  • Eine sinnvolle Defaultkonfiguration wird in das neue Verzeichnis kopiert.

  • Für die Web-Oberfläche von Checkmk wird ein Benutzer mit dem Namen cmkadmin und einem zufälligen Passwort angelegt.

Hinweis: Wenn Sie beim Versuch, die Instanz zu erstellen, diese oder eine ähnliche Fehlermeldung erhalten:

root@linux# omd create mysite
Group 'mysite' already existing.

dann existiert bereits ein Linux-Benutzer oder eine Gruppe mit dem von Ihnen angegebenen Instanznamen. Wählen Sie dann einfach einen anderen Namen.

Sobald Sie die neue Instanz erzeugt haben, erfolgt die weitere Administration nicht mehr als root, sondern als Instanzbenutzer. Zu diesem werden Sie am einfachsten mit dem folgenden Kommando:

root@linux# su - mysite
OMD[mysite]:~$

Am geänderten Prompt sehen Sie, dass Sie in der Instanz eingeloggt sind. Wie der Befehl pwd zeigt, befinden Sie sich danach automatisch im Home-Verzeichnis der Instanz:

OMD[mysite]:~$ pwd
/omd/sites/mysite

Wie Sie in der Ausgabe von omd create gesehen haben, wird beim Erzeugen der Instanz automatisch ein administrativer Checkmk-Benutzer mit dem Namen cmkadmin erzeugt. Dieser Benutzer ist für die Anmeldung an der Web-Oberfläche von Checkmk gedacht und hat ein zufälliges Passwort erhalten. Dieses Passwort können Sie als Instanzbenutzer leicht ändern:

OMD[mysite]:~$ htpasswd -m etc/htpasswd cmkadmin
New password: 
Re-type new password: 
Updating password for user cmkadmin

Übrigens: Immer wenn wir im Handbuch Pfadnamen angeben, die nicht mit einem Schrägstrich beginnen, beziehen sich diese auf das Home-Verzeichnis der Instanz. Wenn Sie sich in diesem Verzeichnis befinden, können Sie solche Pfade daher direkt so verwenden. Das gilt z.B. auch für die Datei etc/htpasswd, deren absoluter Pfad hier /omd/sites/mysite/etc/htpasswd ist. Diese Datei enthält die Passwörter der Checkmk-Benutzer dieser Instanz. Verwechseln Sie diese Datei nicht mit /etc/htpasswd.

1.5. Die Instanz starten

Eine Instanz kann gestartet oder gestoppt sein. Die Startart ist dabei automatisch, was bedeutet, dass eine gestartete Instanz auch nach einem Reboot des Rechners wieder gestartet wird. Frisch angelegte Instanzen beginnen ihr Leben dennoch gestoppt. Das können Sie leicht mit dem Befehl omd status überprüfen, der den Status aller Einzelprozesse zeigt, die zum Betrieb der Instanz nötig sind:

OMD[mysite]:~$ omd status
mkeventd:       stopped
liveproxyd:     stopped
mknotifyd:      stopped
rrdcached:      stopped
cmc:            stopped
apache:         stopped
dcd:            stopped
crontab:        stopped
-----------------------
Overall state:  stopped

Mit einem einfachen omd start können Sie die Instanz starten:

OMD[mysite]:~$ omd start
Creating temporary filesystem /omd/sites/mysite/tmp...OK
Starting mkeventd...OK
Starting liveproxyd...OK
Starting mknotifyd...OK
Starting rrdcached...OK
Starting cmc...OK
Starting apache...OK
Starting dcd...OK
Initializing Crontab...OK

Wie erwartet, zeigt der Status danach alle Dienste als running:

OMD[mysite]:~$ omd status
mkeventd:       running
liveproxyd:     running
mknotifyd:      running
rrdcached:      running
cmc:            running
apache:         running
dcd:            running
crontab:        running
-----------------------
Overall state:  running

CRE Da die Raw Edition nicht über alle Features der Enterprise Editions verfügt, sehen Sie dort weniger Dienste. Außerdem finden Sie für den Kern nagios statt cmc:

OMD[mysite]:~$ omd status
mkeventd:       started
rrdcached:      started
npcd:           started
nagios:         started
apache:         started
crontab:        started
-----------------------
Overall state:  started

Der Befehl omd bietet noch viele weitere Möglichkeiten zur Steuerung und Konfiguration von Instanzen, die im Artikel über Instanzen beschrieben sind. Für noch tiefergehende Informationen unter anderem zur Verzeichnisstruktur der Instanz gibt es den Artikel zu Checkmk auf der Kommandozeile.

1.6. Anmelden

Nachdem die Instanz läuft, kann es auch schon losgehen. Jede Instanz hat eine eigene URL, die Sie in Ihrem Browser öffnen können. Diese setzt sich zusammen aus der IP-Adresse oder dem Host-Namen des Checkmk-Servers, einem Schrägstrich und dem Namen der Instanz, z.B. mycmkserver/mysite. Unter dieser Adresse finden Sie diesen Anmeldedialog:

login

Melden Sie sich nun mit dem Benutzernamen cmkadmin und dem anfangs ausgewürfelten bzw. von Ihnen geänderten Passwort an. Dadurch landen Sie auf der Startseite von Checkmk, die wir uns im nächsten Kapitel genauer ansehen werden.

Falls Ihre Instanz nicht gestartet ist, sehen Sie statt des Anmeldedialogs folgende Fehlermeldung:

omd site not started

Falls es überhaupt keine Instanz mit diesem Namen gibt (oder Sie auf einem Server ohne Checkmk gelandet sind), sieht das eher so aus:

omd site not found

Wichtig: Sobald Sie Checkmk produktiv betreiben, empfehlen wir Ihnen aus Sicherheitsgründen den Zugriff auf die Oberfläche ausschließlich gesichert zuzulassen. Was Sie dafür tun müssen, erfahren Sie im Artikel über die Absicherung der Web-Oberfläche mit HTTPS.

2. Die Checkmk-Oberfläche

2.1. Die Startseite

empty dashboard

In der Benutzeroberfläche (graphical user interface, GUI) von Checkmk sehen Sie einige Elemente, die wir zum jetzigen Zeitpunkt noch nicht benötigen. Viele davon sind leer oder zeigen lauter Nullen, was daran liegt, dass wir noch keine Objekte ins Monitoring aufgenommen haben.

Trotzdem sollten Sie sich mit den Grundelementen der Oberfläche vertraut machen. Am wichtigsten ist die Aufteilung in die Navigationsleiste links, die Hauptseite in der Mitte und die Seitenleiste rechts.

2.2. Navigationsleiste

navbar

Mit der Navigationsleiste (navigation bar) auf der linken Seite und der sich darin befindlichen Symbole treffen Sie die Grundsatzentscheidung, worum sich Checkmk für Sie kümmern soll:

Setup — die Einrichtung der zu überwachenden Objekte (wie Hosts und Services)

Monitor — die Überwachung selbst

Customize — die Anpassung von Einstellungen, die für die Überwachung nützlich sind

Hinter den drei Symbolen verbergen sich mehr oder weniger umfangreiche Menüs, die sogenannten „Mega-Menüs“ oder Symbolmenüs, deren Einträge in mehrere Themen gegliedert sind: Zum Beispiel finden Sie im Setup-Menü zum Thema Hosts Einträge zum Konfigurieren von Hosts, Host-Gruppen, Host-Merkmalen und Host-spezifischen Regeln. Wir werden einen dieser Einträge im nächsten Kapitel beim Einrichten des ersten Hosts verwenden.

Im unteren Bereich der Navigationsleiste finden Sie im User-Menü Einträge, die Ihr Checkmk-Benutzerkonto betreffen — zurzeit also das Konto des Benutzers cmkadmin. Hier können Sie das Passwort ändern, persönliche Einstellungen Ihres Profils anpassen und sich von der Checkmk-Oberfläche abmelden. Für wichtige bzw. häufig verwendete Einstellungen gibt es im User-Menü einen Schnellzugriff, mit dem Sie zum Beispiel durch einfaches Anklicken von Interface theme das Aussehen der Oberfläche ändern können: von Dark nach Light bzw. umgekehrt, je nachdem welches Theme aktuell ausgewählt ist.

Im Help-Menü finden Sie die aktuell genutzte Edition und Version von Checkmk und einige Einträge, mit der Sie Dokumentation und Information aufrufen können — innerhalb von Checkmk oder außerhalb. Unter anderem können Sie auch dieses Handbuch öffnen.

Komplettiert wird die Navigationsleiste ganz unten durch Sidebar (mit der Sie durch einfaches Anklicken die Seitenleiste aus- oder einblenden können) und ganz oben durch das Checkmk-Logo. Ein Klick auf das Logo bringt Sie immer zurück zum Standard-Dashboard, das auf der Hauptseite angezeigt wird.

2.3. Hauptseite

mainpage default

Was Sie auf der Hauptseite sehen, hängt davon ab, wo Sie in Checkmk gerade unterwegs sind. Nach der Anmeldung sehen Sie zunächst das Standard-Dashboard, das einen Überblick über den aktuellen Zustand und die kürzlichen Ereignisse der überwachten Objekte zeigt.

Der Inhalt der Hauptseite ändert sich abhängig von Ihrer Auswahl in der Navigationsleiste oder auch der Seitenleiste. Wenn Sie zum Beispiel im User-Menü die Änderung Ihres Profils auswählen, werden Ihnen alle Profileinstellungen auf der Hauptseite angezeigt.

Unterhalb des Seitentitels sehen Sie den Pfad zur aktuellen Seite, stets beginnend mit dem Namen des Menüs aus der Navigationsleiste. Mithilfe dieser „Breadcrumb-Navigation“ wissen Sie auch nach komplexen Aktionen, wo Sie sich in Checkmk gerade befinden — momentan also auf der Seite Main Overview im Monitoring.

2.4. Seitenleiste

sidebar default

Die Seitenleiste (sidebar) ist Ihr Checkmk-Cockpit. Es ist der Ort, an dem Sie ständig die wichtigsten Informationen im Blick und den schnellen Zugriff auf die Funktionen haben, die Sie in Checkmk immer wieder benötigen.

In der obersten Reihe der Seitenleiste sehen Sie eine Auswahl von 5 Symbolen mit wichtigen Aktionen, die viele Checkmk-Benutzer besonders nützlich finden. Klicken Sie ruhig der Reihe nach diese Symbole durch — auch wenn mangels überwachter Objekte die dargestellten Informationen noch nicht aussagekräftiger sind als auf der Startseite Main Overview, zu der Sie übrigens durch Klick auf das erste Symbol Main wieder zurückkehren.

Unterhalb der 5 Symbole beginnt der Bereich, den Sie sich nach Ihren Vorlieben zusammenstellen können. Dazu dienen die Seitenleistenelemente, auch „Snapins“ genannt. Snapins sind kompakte GUI-Container mit vordefinierter Funktion. Da die Seitenleiste für Ihre Präferenzen da sein soll, enthält sie in der Standardeinstellung nur einige wenige Snapins:

Tactical overview — Übersicht aller überwachten Objekte mit aktuellen Statusinformationen

Quicksearch — Suchfeld

Bookmarks — Ihre persönlichen Lesezeichen innerhalb von Checkmk

Master Control — Verschiedene Hauptschalter für das Monitoring

Übrigens erhalten Sie genauere Informationen zu den genannten Snapins im Kapitel zu den Monitoring-Werkzeugen weiter unten.

Wenn Sie ganz unten in der Seitenleiste auf button sidebar add snapin klicken, werden Ihnen in der Hauptseite alle Snapins angezeigt, die aktuell nicht in Ihrer Seitenleiste sind und die Sie durch einen einfachen Klick hinzufügen können. Probieren Sie es aus und füllen Sie testweise die Seitenleiste.

Je nach Größe Ihres Bildschirms werden nun eventuell nicht alle Snapins sichtbar sein. Am schnellsten bewegen Sie sich vertikal durch die Seitenleiste mit dem Mausrad, während der Mauszeiger über der Seitenleiste ist. Bei Touchpads ist diese Funktion oft mit der Geste „zwei Finger nebeneinander hoch- und runterschieben“ möglich.

In der Seitenleiste können Sie die Snapins so manipulieren:

  • Auf- und zuklappen: Klicken Sie in den angezeigten Titel des Snapins.

  • Verschieben: Drücken Sie mit der linken Maustaste rechts neben den Titel, ziehen Sie das Snapin auf- oder abwärts an eine andere Position in der Seitenleiste und lassen Sie die Maustaste los.

  • Entfernen: Zeigen Sie mit der Maus auf die Titelleiste und klicken Sie auf button sidebar close snapin.

Soweit zu den Möglichkeiten, den Inhalt der Seitenleiste anzupassen. Als Ganzes können Sie die Seitenleiste aus- und wieder einblenden (mit Sidebar in der Navigationsleiste) und Sie können Ihre Position von rechts nach links verschieben, so dass sie an die Navigationsleiste andockt (mit User-Menü > Sidebar position).

Nach dieser Einführung sollten Sie mit den wichtigsten Elementen der Checkmk-Oberfläche vertraut sein (ausführlichere Informationen finden Sie im Artikel zur Benutzeroberfläche). Wir können also im nächsten Kapitel damit beginnen, Checkmk für das Monitoring einzurichten.

3. Das Monitoring einrichten

3.1. Hosts, Services und Agenten

So, Checkmk steht bereit. Doch bevor wir mit dem eigentlichen Monitoring beginnen, werden wir kurz einige wichtige Begriffe erläutern. Das beginnt mit dem Host: Ein Host ist in Checkmk ein Server, eine virtuelle Maschine (VM), ein Netzwerkgerät, eine Appliance — oder generell ein Ding mit einer IP-Adresse, das von Checkmk überwacht wird. Allerdings gibt es auch Hosts ohne IP-Adresse, z.B. Docker-Container. Jeder Host hat immer einen der Zustände UP, DOWN oder UNREACH.

Auf jedem Host wird eine Anzahl von Services überwacht. Ein Service kann dabei alles Mögliche sein, zum Beispiel ein Dateisystem, ein Prozess, ein Hardware-Sensor, ein Switchport — aber auch einfach nur eine bestimmte Metrik wie die CPU-Auslastung oder der RAM-Verbrauch. Jeder Service hat einen der Zustände OK, WARN, CRIT oder UNKNOWN.

Damit Checkmk von einem Host Daten abfragen kann, ist in der Regel ein Agent notwendig. Das ist ein kleines Programm, das auf dem Host installiert wird, und auf Anfrage Daten über den Zustand (oder die „Gesundheit“) des Hosts liefert. Server, auf denen Windows, Linux oder Unix läuft, können von Checkmk nur dann sinnvoll überwacht werden, wenn Sie dort einen von uns gelieferten Checkmk-Agenten installieren. Bei Netzwerkgeräten und vielen Appliances hat meist der Hersteller bereits einen Agenten eingebaut, den Checkmk ohne Weiteres mit dem standardisierten Protokoll SNMP abfragen kann. Cloud-Dienste wie Amazon Web Services (AWS) oder Azure stellen stattdessen eine Schnittstelle („API“) bereit, die von Checkmk per HTTP abgefragt werden kann.

3.2. Vorüberlegungen zu DNS

Auch wenn Checkmk keine Namensauflösung von Hosts voraussetzt, erleichtert ein gut gepflegtes Domain Name System (DNS) die Konfiguration erheblich und vermeidet Fehler, denn Checkmk kann dann die Namen der Hosts selbständig auflösen, ohne dass Sie IP-Adressen in Checkmk eintragen müssen.

Der Aufbau des Monitoring ist daher ein guter Anlass, zu überprüfen, ob Ihr DNS auf dem neuesten Stand ist und gegebenenfalls dort fehlende Einträge zu ergänzen.

3.3. Ordnerstruktur für Hosts

Checkmk verwaltet Ihre Hosts in einem hierarchischen Baum von Ordnern — ganz analog zu dem, was Sie von Dateien in Ihrem Betriebssystem kennen. Wenn Sie nur eine Handvoll Hosts überwachen, mag das für Sie weniger wichtig sein. Aber erinnern Sie sich: Checkmk ist für das Überwachen von Tausenden und Zigtausenden Hosts geschaffen — und dabei ist Ordnung die halbe Miete.

Bevor Sie die ersten Hosts in Checkmk aufnehmen, ist es daher von Vorteil, wenn Sie sich Gedanken über die Struktur dieser Ordner machen. Die Ordnerstruktur ist nicht nur für Ihre eigene Übersicht nützlich, sie kann zusätzlich auch für die Konfiguration von Checkmk verwendet werden: Alle Konfigurationsparameter von Hosts können in einem Ordner definiert werden, die dann automatisch an die dort enthaltenen Unterordner und Hosts vererbt werden.

Eine einmal erstellte Ordnerstruktur können Sie jederzeit verändern — müssen dabei allerdings sehr gewissenhaft vorgehen. Das Verschieben eines Hosts in einen anderen Ordner kann nämlich zur Folge haben, dass sich dessen Parameter ändern, ohne dass Sie sich dessen vielleicht bewusst sind.

Die eigentliche Frage beim Aufbau einer für Sie sinnvollen Ordnerstruktur ist, nach welchen Kriterien Sie die Ordner organisieren möchten. Die Kriterien können in jeder Ebene des Baums andere sein. So können Sie z.B. in der ersten Ebene nach Standorten unterscheiden und in der zweiten Ebene nach Technologie.

Folgende Ordnungskriterien haben sich in der Praxis bewährt:

  • Standort/Geographie

  • Organisation

  • Technologie

Eine Sortierung nach Standort ist vor allem in größeren Unternehmen sehr naheliegend, insbesondere dann, wenn Sie das Monitoring über mehrere Checkmk-Server verteilen. Jeder Server überwacht dann z.B. eine Region oder ein Land. Wenn Ihre Ordner diese Aufteilung abbilden, dann können Sie z.B. im Ordner „München“ definieren, dass alle Hosts in diesem Ordner von der Checkmk-Instanz „muc“ aus überwacht werden sollen.

Alternativ dazu kann die Organisation (d.h. die Antwort auf die Frage "Wer ist für einen Host zuständig?“) ein sinnvolleres Kriterium sein, denn nicht immer ist Standort und Verantwortung das Gleiche. So mag es sein, dass eine Gruppe Ihrer Kollegen für die Administration von Oracle zuständig ist, und zwar unabhängig davon, an welchem Standort die entsprechenden Hosts stehen. Ist also z.B. der Ordner „Oracle“ für die Hosts der Oracle-Kollegen vorgesehen, so ist es in Checkmk einfach zu konfigurieren, dass alle Hosts unterhalb dieses Ordners nur für diese Kollegen sichtbar sind oder, dass diese ihre Hosts dort sogar selbst pflegen können.

Eine Strukturierung nach Technologie könnte z.B. einen Ordner für Windows-Server und einen für Linux-Server vorsehen. Das würde die Umsetzung des Schemas „Auf allen Linux-Servern muss der Prozess sshd laufen.“ vereinfachen. Ein anderes Beispiel ist die Überwachung von Geräten via SNMP, wie beispielsweise Switches oder Router. Hier kommt kein Checkmk-Agent zum Einsatz, sondern die Geräte werden über das Protokoll SNMP abgefragt. Sind diese Hosts in eigenen Ordnern zusammengefasst, so können Sie direkt am Ordner die für SNMP notwendigen Einstellungen wie etwa die „Community“ vornehmen.

Da eine Ordnerstruktur nur in seltenen Fällen die Komplexität der Wirklichkeit abbilden kann, bietet Checkmk mit den Host-Merkmalen (host tags) eine weitere ergänzende Möglichkeit zur Strukturierung: doch dazu später mehr. Weiterführende Informationen unter anderem zur Ordnerstruktur finden Sie im Artikel über Hosts.

3.4. Ordner erstellen

Den Einstieg in die Verwaltung von Ordnern und Hosts finden Sie über die Navigationsleiste, das Setup-Menü, das Thema Hosts und den Eintrag Hosts. Dann wird die Seite Main directory angezeigt:

empty main directory

Bevor wir den ersten Ordner erstellen, werden wir kurz auf den Aufbau dieser Seite eingehen, da Sie die verschiedenen Elemente auf den meisten Checkmk-Seiten so oder so ähnlich wiederfinden werden. Unterhalb des Seitentitels Main directory finden Sie den Breadcrumb-Pfad, der Ihnen zeigt, wo Sie sich innerhalb der Checkmk-Oberfläche gerade befinden. Darunter wird die Menüleiste angezeigt, die die möglichen Aktionen auf dieser Seite in Menüs und Menüeinträgen zusammenfasst. Die Menüs sind in Checkmk stets kontext-spezifisch, d.h. sie finden nur Menüeinträge für Aktionen, die auf der aktuellen Seite Sinn machen.

Unter der Menüleiste finden Sie die Aktionsleiste, in der die wichtigsten Aktionen aus den Menüs als Knöpfe zum direkten Anklicken angeboten werden. Die Aktionsleiste können Sie mit dem Knopf button hide toolbar rechts neben dem Help-Menü ausblenden und mit button show toolbar wieder einblenden. Bei ausgeblendeter Aktionsleiste werden die Symbole in der Menüleiste rechts neben button show toolbar angezeigt.

Da wir uns zurzeit auf einer leeren Seite befinden (ohne Ordner und ohne Hosts), werden die wichtigen Aktionen zum Erstellen des ersten Objekts zusätzlich über noch größere Knöpfe angeboten — damit die Möglichkeiten auch nicht übersehen werden, die die Seite bietet. Diese Knöpfe werden nach dem Erstellen des ersten Objekts verschwinden.

Nun aber zurück zum Thema, weswegen wir uns eigentlich auf dieser Seite befinden: dem Anlegen von Ordnern. Einen Ordner — den Hauptordner — gibt es in jedem frisch aufgesetzten Checkmk-System. Er heißt Main directory, wie Sie im Titel der Seite sehen können. Unterhalb des Hauptordners werden wir nun für ein einfaches Beispiel die drei Ordner Windows, Linux und Network erstellen.

Legen Sie diese drei Ordner nacheinander an, indem Sie eine der angebotenen Aktionen zum Erstellen eines Ordners auswählen (z.B. den Aktionsknopf icon newfolder Add subfolder) und auf der neuen Seite Create new folder im ersten Kasten Basic Settings den jeweiligen Namen eintragen:

folder basic settings

Tipp: Vielleicht sind Ihnen die drei Punkte rechts oben im Bild schon an anderer Stelle der Checkmk-Oberfläche aufgefallen — z.B. im geöffneten Setup-Menü: Immer, wenn Sie diese Auslassungspunkte sehen, bietet Checkmk zwei Ansichten an: Es werden entweder nur die wichtigsten Einträge angezeigt (gedacht für den Einsteiger) oder alle Einträge (für den Experten). Sie können durch Klick auf die Auslassungspunkte zwischen beiden Ansichten wechseln und Sie können das generelle Verhalten in den Einstellungen Ihres Benutzerprofils unter Show more / Show less ändern.

Im obigen Bild ist der Show less-Modus aktiv und es wird nur derjenige Eintrag angezeigt, der zum Erstellen eines Ordners unbedingt notwendig ist. Bestätigen Sie die Eingabe mit Save.

Erstellen Sie analog zum Ordner Windows die anderen beiden Ordner Linux und Network. Danach sieht die Situation so aus:

three empty folders

Tipp: Wenn Sie mit der Maus auf den oberen Bereich eines der drei Ordner-Symbole zeigen, werden Ihnen Symbole angezeigt um schnell Aktionen mit dem Ordner auszuführen (die Eigenschaften ändern, den Ordner verschieben oder ihn löschen).

Noch ein Tipp: Rechts oben auf jeder Seite finden Sie die Information, ob — und wenn ja, wie viele — Änderungen inzwischen bereits aufgelaufen sind. Da wir drei Ordner erstellt haben, gibt es drei Änderungen, die jetzt aber noch nicht aktiviert werden müssen. Wir werden uns mit dem Aktivieren von Änderungen weiter unten genauer beschäftigen.

3.5. Den ersten Host aufnehmen

Jetzt ist alles dafür vorbereitet, um den ersten Host in das Monitoring aufzunehmen — und was wäre naheliegender, als den Checkmk-Server selbst zu überwachen? Natürlich wird dieser nicht seinen eigenen Totalausfall melden können, aber nützlich ist das trotzdem, denn Sie erhalten so nicht nur eine Übersicht über die CPU- und RAM-Nutzung, sondern auch etliche Metriken und Checks, die das Checkmk-System selbst betreffen.

Das Vorgehen zum Aufnehmen eines Linux-Hosts (wie übrigens auch eines Windows-Hosts) ist im Prinzip stets das Folgende:

  1. Agent herunterladen

  2. Agent installieren

  3. Host erstellen

Nach der Erstellung des Hosts wird die Einrichtung komplettiert durch die Konfiguration der Services und die Aktivierung der Änderungen.

Agent herunterladen

Da der Checkmk-Server ein Linux-Rechner ist, benötigen Sie den Checkmk-Agenten für Linux.

CEE In den Enterprise Editions gelangen Sie mit Setup > Agents > Windows, Linux, Solaris, AIX zu einer Seite, die Ihnen auch den Zugang zur Agentenbäckerei (agent bakery) bietet, mit dem Sie sich individuell konfigurierte Agentenpakete „backen“ können. Zusätzlich wird aber auch immer ein generischer Agent angeboten, den Sie sofort herunterladen können:

agent download cee

CRE Die Raw Edition verfügt über keine Agentenbäckerei. Hier gelanden Sie über Setup > Agents > Linux direkt zur Download-Seite, auf der Sie vorkonfigurierte Agenten und Agenten-Plugins finden. (Diese finden Sie in den Enterprise Editions über Setup > Agents > Other operating systems.)

agent download page

Laden Sie die Datei herunter: Wählen Sie das RPM-Dateiformat für Red Hat, CentOS und SLES oder das DEB-Dateiformat für Debian und Ubuntu.

Hinweis: Da der Checkmk-Server, von dem Sie die Datei geladen haben, identisch mit dem Host ist, auf dem der Agent installiert werden soll, brauchen Sie die Datei nicht auf einen anderen Rechner zu kopieren.

Agent installieren

Für folgendes Beispiel nehmen wir an, dass Sie die Datei in das Verzeichnis /root kopiert haben, also in das Home-Verzeichnis des root-Benutzers. Diese Datei wird nur während der Installation benötigt. Sie können sie nach der Installation löschen.

Die Installation erfolgt als root auf der Kommandozeile, für die RPM-Datei mit rpm, am besten mit der Option -U:

root@linux# rpm -U check-mk-agent-2.0.0i1-21eb305b265abc60.noarch.rpm

… oder für die DEB-Datei mit dem Befehl dpkg -i:

root@linux# dpkg -i check-mk-agent_2.0.0i1-21eb305b265abc60_all.deb

Wichtig: Der Agent benötigt zum Funktionieren entweder das Hintergrundprogramm (daemon) systemd, das bei neueren Linux-Distributionen Standard ist, oder den Hilfs-Daemon xinetd. Welcher Daemon auf Ihrem Rechner läuft, können Sie an der Ausgabe beim Installieren des Agenten sehen:

Agent läuft …​Ausgabe

mit xinetd

Reloading xinetd …​

mit systemd

Enable Checkmk agent in systemd…​

überhaupt nicht

Keine der beiden anderen Meldungen, dafür: This package needs xinetd to be installed for full functionality.

Falls bei Ihnen weder systemd noch xinetd vorhanden ist, installieren Sie xinetd einfach nach. Das geht auf RedHat/CentOS mit:

root@linux# yum install xinetd

auf SLES mit:

root@linux# zypper install xinetd

und auf Debian/Ubuntu mit:

root@linux# apt install xinetd

Damit ist die Installation des Agenten abgeschlossen.

Der Checkmk-Agent für Linux ist ein ausführbares Programm (Shell-Skript), das Sie sehr leicht testen können, indem Sie den Befehl check_mk_agent aufrufen:

root@linux# check_mk_agent
<<<check_mk>>>
Version: 2.0.0i1
AgentOS: linux
Hostname: linux
AgentDirectory: /etc/check_mk
DataDirectory: /var/lib/check_mk_agent
SpoolDirectory: /var/lib/check_mk_agent/spool
PluginsDirectory: /usr/lib/check_mk_agent/plugins
LocalDirectory: /usr/lib/check_mk_agent/local
...

Die Ausgabe des check_mk_agent-Kommandos ist sehr lang, daher haben wir nur die ersten Zeilen aufgelistet.

Um die Erreichbarkeit des Agenten von außen zu testen, können Sie von einem anderen Rechner aus mit telnet eine Verbindung auf Port 6556 versuchen. Hier sollte der Agent mit der gleichen Ausgabe antworten:

root@linux# telnet linux 6556
Trying 192.168.178.34...
Connected to linux.
Escape character is '^]'.
<<<check_mk>>>
Version: 2.0.0i1
AgentOS: linux
Hostname: linux
...

Hinweis: Der Agent ist standardmäßig aus dem ganzen Netz erreichbar und ohne Passwort abfragbar. Da der Agent aber grundsätzlich keine Befehle aus dem Netz annimmt, kann sich ein möglicher Angreifer keinen Zugriff verschaffen. Allerdings sind Informationen wie die Liste der aktuellen Prozesse sichtbar. Wie Sie den Agenten absichern, erfahren sie im Artikel über den Linux-Agenten.

Host erstellen

Nachdem der Agent auf dem Host installiert ist, können Sie den Host ins Monitoring aufnehmen — und zwar in den vorbereiteten Ordner Linux. Nur zur Erinnerung: In diesem Beispiel sind der Checkmk-Server und der zu überwachende Host identisch.

Öffnen Sie in der Checkmk-Oberfläche die gleiche Seite Main directory, auf der Sie bereits die drei Ordner erstellt haben: Setup > Hosts > Hosts. Wechseln Sie dort in den Ordner Linux, indem Sie den Ordner anklicken.

Klicken Sie Add host und die Seite Create new host wird geöffnet:

host allsettings less

Wie schon beim Anlegen der drei Ordner weiter oben ist bei uns immer noch der Einsteiger-Modus (oder Show less-Modus) von Checkmk aktiv. Daher zeigt Checkmk im Formular nur die wichtigsten und zum Erstellen eines Hosts notwendigen Host-Parameter an. Falls es sie interessiert, können Sie sich den Rest ansehen, indem Sie bei jedem der geöffneten Kästen die drei Auslassungszeichen button showmore anklicken und die beiden zugeklappten Kästen am Ende der Seite öffnen. Wie am Anfang erwähnt, ist Checkmk ein komplexes System, das auf jede Frage eine Antwort hat. Deswegen kann man bei einem Host (aber nicht nur dort) auch sehr viel konfigurieren.

Tipp: Auf vielen Seiten — auch auf dieser — können Sie sich zusätzlich Hilfetexte zu den Parametern anzeigen lassen. Wählen Sie dazu im Help-Menü den Eintrag Toggle inline help. Die gewählte Einstellung bleibt auch auf anderen Seiten aktiv, bis Sie die Hilfe wieder abschalten.

Aber nun zu den Eingaben, um den ersten Host zu erstellen. Sie müssen nur ein einziges Feld ausfüllen, nämlich Hostname bei den Basic Settings. Diesen Namen können Sie frei vergeben. Er dient im Monitoring an allen Stellen als interne ID (oder Schlüssel) und eindeutige Bezeichnung für den Host.

Falls der Host unter seinem Namen im DNS auflösbar ist, sind Sie mit diesem Formular bereits fertig. Falls nicht, oder falls Sie kein DNS verwenden möchten, können Sie die IP-Adresse aber auch von Hand im Feld IPv4 Address eintragen.

Hinweis: Damit Checkmk immer stabil und performant laufen kann, unterhält es einen eigenen Cache für die Auflösung der Host-Namen. Daher führt der Ausfall des DNS-Dienstes nicht zum Ausfall des Monitorings. Die DNS-Abfrage geschieht nur einmalig, wenn der Host ins Monitoring aufgenommen wird.

Der Cache wird automatisch jeden Tag um 00:05 Uhr erneuert. Falls Sie den DNS-Cache neu aufbauen wollen, damit eine Änderung in Ihrem DNS sofort wirksam wird, bietet Ihnen Checkmk auch diese Möglichkeit, und zwar in den Eigenschaften eines Hosts mit dem Knopf icon update Update site DNS cache. Genauere Informationen dazu finden Sie im Artikel über die Host-Verwaltung.

Um aber die Eigenschaften eines Hosts aufrufen zu können, muss der erste Host zuerst einmal komplett erstellt werden — und soweit sind wir noch nicht, auch wenn wir kurz davor stehen.

Diagnose

Murphys Gesetz („Alles, was schiefgehen kann, wird auch schiefgehen.“) kann leider auch von Checkmk nicht außer Kraft gesetzt werden. Schiefgehen kann vor allem dann etwas, wenn man es zum ersten Mal probiert. Daher sind gute Möglichkeiten zur Fehlerdiagnose wichtig.

Bereits bei der Erstellung eines Hosts bietet Checkmk an, nicht nur die Eingaben (Host-Name und IP-Adresse) auf der Seite Create new host zu sichern, sondern zusätzlich die Verbindung zum Host zu testen. In der Aktionsleiste der Seite Create new host finden Sie unter anderem den Knopf Save & go to connection tests. Klicken Sie auf diesen.

Die Seite Test connection to host wird angezeigt und Checkmk versucht, den Host auf den verschiedensten Wegen zu erreichen. Für Linux- und Windows-Hosts sind dabei nur die beiden oberen Kästen interessant:

host diagnostics

Durch die Ausgabe im Kasten "Agent" erhalten Sie die Gewissheit, dass der neu erstellte Host in Checkmk erfolgreich mit dem Agent kommunizieren kann, den Sie zuvor auf dem Host manuell installiert hatten.

In weiteren Kästen versucht Checkmk per SNMP Kontakt aufzunehmen. Das führt in diesem Beispiel erwartbar zu SNMP-Fehlern, ist aber sehr nützlich für Netzwerkgeräte, die wir weiter unten besprechen werden.

Auf dieser Seite können Sie im Kasten Host Properties bei Bedarf eine andere IP-Adresse ausprobieren, den Test erneut durchführen und die geänderte IP-Adresse mit Save & go to host properties sogar direkt in die Host-Eigenschaften übernehmen.

Klicken Sie diesen Knopf (ob Sie die IP-Adresse geändert haben oder nicht) und Sie landen auf der Seite Properties of host.

3.6. Die Services konfigurieren

Nachdem der Host selbst aufgenommen wurde, kommt das eigentlich Interessante: die Konfiguration seiner Services. Auf der oben genannten Seite der Host-Eigenschaften klicken Sie Save & go to service configuration und die Seite Services of host wird angezeigt.

Auf dieser Seite legen Sie fest, welche Services Sie auf dem Host überwachen möchten. Wenn der Agent auf dem Host erreichbar ist und korrekt läuft, findet Checkmk automatisch eine Reihe von Services und schlägt diese für das Monitoring vor (hier gekürzt dargestellt):

new host services

Für jeden dieser Services gibt es prinzipiell drei Möglichkeiten:

  • Undecided : Sie haben sich noch nicht entschieden, ob dieser Service überwacht werden soll.

  • Monitored : Der Service wird überwacht.

  • Disabled : Sie haben sich dafür entschieden, den Service grundsätzlich nicht zu überwachen.

Die Seite zeigt alle Services nach diesen Möglichkeiten in drei Tabellen an. Da Sie noch keinen Service konfiguriert haben, sehen Sie nur die Tabelle Undecided. Für den Anfang ist es am einfachsten, wenn Sie jetzt auf Monitor undecided services klicken. Dann werden alle Services direkt in das Monitoring übernommen und alle Undecided zu Monitored Services.

Sie können diese Seite jederzeit später aufrufen, um die Konfiguration der Services anzupassen. Manchmal entstehen durch Änderungen an einem Host neue Services, z.B. wenn Sie eine Logical Unit Number (LUN) als Dateisystem einbinden oder eine neue Oracle Datenbankinstanz konfigurieren. Diese Services erscheinen dann wieder als Undecided, und Sie können sie einzeln oder alle auf einmal in das Monitoring aufnehmen.

Umgekehrt können Services auch verschwinden, z.B. weil ein Dateisystem entfernt wurde. Diese erscheinen dann im Monitoring als UNKNOWN und auf dieser Seite als Vanished und können mit Remove vanished services aus dem Monitoring entfernt werden.

Der Knopf Add missing, remove vanished macht alles auf einmal: fehlende Services hinzufügen und überflüssige entfernen.

3.7. Änderungen aktivieren

Checkmk speichert alle Änderungen, die Sie vornehmen, zunächst nur in einer vorläufigen „Konfigurationsumgebung“, die das aktuell laufende Monitoring noch nicht beeinflusst. Erst durch das „Aktivieren der aufgelaufenen Änderungen“ werden diese in Monitoring übernommen. Mehr über die Hintergründe dazu erfahren Sie im Artikel über die Konfiguration von Checkmk.

Wie wir schon oben erwähnt hatten, finden Sie auf jeder Seite rechts oben die Information, wie viele Änderungen sich bisher angesammelt haben, die noch nicht aktiviert sind. Klicken Sie auf den Link mit der Anzahl der Änderungen. Dies bringt Sie auf die Seite Activate pending changes, die unter anderem bei Pending changes die noch nicht aktivierten Änderungen auflistet:

activate changes

Klicken Sie jetzt auf den Knopf Activate on affected sites, um die Änderungen anzuwenden.

Kurz danach können Sie das Resultat in der Seitenleiste im Tactical overview sehen, das nunmehr die Zahl der Hosts (1) und die Zahl der zuvor von Ihnen ausgewählten Services anzeigt. Auch im Standard-Dashboard, das Sie mit einem Klick auf das Checkmk-Logo links oben in der Navigationsleiste erreichen, können Sie jetzt sehen, dass sich das System mit Leben gefüllt hat.

Damit haben Sie den ersten Host mit seinen Services erfolgreich ins Monitoring übernommen: Gratulation!

3.8. Windows überwachen

Ebenso wie für Linux hat Checkmk auch für Windows einen eigenen Agenten. Dieser ist als MSI-Paket verpackt. Sie finden ihn an der gleichen Stelle wie auch den Linux-Agenten (in der CRE Checkmk Raw Edition knapp daneben unter Setup > Hosts > Windows). Sobald Sie das MSI-Paket heruntergeladen und auf Ihren Windows-Rechner kopiert haben, können Sie es wie bei Windows üblich per Doppelklick installieren.

Hinweis: Es kann sein, dass Sie die Firewall-Einstellungen unter Windows anpassen müssen, damit Checkmk über das Netzwerk zugreifen kann.

Sobald der Agent installiert ist, können Sie den Host ins Monitoring aufnehmen. Dabei gehen Sie nach dem gleichen Ablauf vor, wie oben für den Linux-Host beschrieben, allerdings sollten Sie den Host im dafür vorgesehenen Ordner Windows erstellen. Da Windows anders aufgebaut ist als Linux, findet der Agent natürlich andere Services. Die detaillierte Einführung ins Thema finden Sie im Artikel zur Überwachung von Windows.

3.9. Mit SNMP überwachen

Professionelle Switches, Router, Drucker und viele andere Geräte und Appliances haben bereits vom Hersteller eine eingebaute Schnittstelle für das Monitoring: das Simple Network Management Protocol (SNMP). Solche Geräte lassen sich sehr einfach mit Checkmk überwachen — und Sie müssen noch nicht einmal einen Agenten installieren.

Das grundsätzliche Vorgehen ist dabei immer gleich:

  1. In der Management-Oberfläche des Geräts schalten Sie SNMP frei für lesende Zugriffe von der IP-Adresse des Checkmk-Servers.

  2. Vergeben Sie dabei eine Community. Das ist nichts anderes als ein Passwort für den Zugriff. Da dieses im Netzwerk in der Regel im Klartext übertragen wird, ist es nur begrenzt sinnvoll, das Kennwort sehr kompliziert zu wählen. Die meisten Anwender verwenden für alle Geräte innerhalb eines Unternehmens einfach diegleiche Community. Das vereinfacht auch die Konfiguration in Checkmk sehr.

  3. Erstellen Sie in Checkmk den Host für das SNMP-Gerät wie oben beschrieben, diesmal im dafür vorgesehenen Ordner Network.

  4. In den Eigenschaften des Hosts, im Kasten Data sources aktivieren Sie Checkmk Agent und wählen Sie No agent aus.

  5. Im gleichen Kasten Data sources aktivieren Sie SNMP und wählen Sie SNMP v2 or v3 aus.

  6. Falls die Community nicht public lautet, aktivieren Sie wieder unter Data sources den Eintrag SNMP credentials, wählen Sie SNMP community (SNMP Versions 1 and 2c) aus und tragen Sie im Eingabefeld darunter die Community ein.

Für die letzten 3 Punkte sollte das Ergebnis so aussehen wie im folgenden Bild:

host snmp configuration

Tipp: Wenn Sie alle SNMP-Geräte in einem eigenen Ordner angelegt haben, führen Sie die Konfiguration der Data sources einfach für den Ordner aus. Damit gelten die Einstellungen automatisch für alle Hosts in diesem Ordner.

Der Rest läuft wie gehabt. Wenn Sie möchten, können Sie noch mit dem Knopf Save & go to connection tests einen Blick auf die Seite Test connection to host werfen. Dort sehen Sie auch sofort, ob der Zugriff via SNMP funktioniert, hier z.B. für einen Switch vom Typ Cisco Catalyst 4500:

snmp diagnostics

Klicken Sie auf der Seite Properties of host anschließend auf Save & go to service configuration, um die Liste aller Services angezeigt zu bekommen. Diese sieht natürlich komplett anders aus als bei Linux oder Windows. Auf allen Geräten überwacht Checkmk per Default alle Ports, die aktuell in Benutzung sind. Dies können Sie später nach Belieben anpassen. Auch zeigt es Ihnen in je einem Service, der immer OK ist, die allgemeinen Informationen zu dem Gerät sowie seine Uptime an.

Die ausführliche Beschreibung finden Sie im Artikel zur Überwachung via SNMP.

3.10. Cloud, Container und virtuelle Maschinen

Auch Cloud-Dienste, Container und virtuelle Maschinen (VM) können Sie mit Checkmk überwachen, selbst wenn Sie keinen Zugriff auf die eigentlichen Server haben. Checkmk nutzt dafür die von den Herstellern vorgesehenen Anwendungsprogrammierschnittstellen (API). Diese verwenden für den Zugriff durchgehend HTTP bzw. HTTPS.

Das Grundprinzip ist immer das Folgende:

  1. In der Management-Oberfläche des Herstellers richten Sie einen Account für Checkmk ein.

  2. Erstellen Sie in Checkmk einen Host für den Zugriff auf die API.

  3. Richten Sie für diesen Host eine Konfiguration zum Zugriff auf die API ein.

  4. Für die überwachten Objekte wie VMs, EC2-Instanzen, Container usw. legen Sie weitere Hosts in Checkmk an bzw. automatisieren die Erstellung.

Sie finden im Handbuch Schritt-für-Schritt-Anleitungen zur Einrichtung der Überwachung von Amazon Web Services (AWS), Microsoft Azure, Docker, Kubernetes und VMWare ESXi.

4. Die Monitoring-Werkzeuge

4.1. Die Statusoberfläche

Jetzt, da wir unserem Monitoring-System endlich etwas zu tun gegeben haben, ist es an der Zeit, dass wir uns näher mit den Elementen der Checkmk-Benutzeroberfläche befassen, die Ihnen im täglichen Leben beim Monitoring (oder Operating) helfen. In Checkmk wird dieser Teil auch manchmal als Statusoberfläche bezeichnet, weil es meist darum geht, den aktuellen Status von allen Hosts und Services zu sehen. Dazu gehören Snapins der Statusleiste, Dashboards, aber auch die Darstellung und Aufbereitung von Messwerten.

4.2. Tactical overview

Prominent oben in der Seitenleiste platziert finden Sie das Snapin Tactical overview:

tactical overview

In der ersten Spalte dieser kleinen Tabelle sehen Sie zunächst die Anzahl Ihrer überwachten Hosts und Services. Die dritte Zeile zeigt Events. Diese werden für Sie erst dann relevant, wenn Sie eine Überwachung von Meldungen konfiguriert haben. Damit sind z.B. Meldungen aus Syslog, SNMP-Traps und Logdateien gemeint. Dafür hat Checkmk ein eigenes sehr mächtiges Modul: die Event Console, die aber im Leitfaden für Einsteiger nicht besprochen wird.

Die zweite Spalte zeigt die Probleme. Das sind die Objekte, die gerade im Status WARN/CRIT/UNKNOWN bzw. DOWN/UNREACH sind. Sie können auf die Zahl in der Zelle klicken und kommen dann direkt zu einer Liste der Objekte, die hier gezählt wurden. Das funktioniert übrigens bei allen Zellen des Tactical overview.

Die Zahlen in der dritte Spalte können nie größer werden als die der zweiten, denn sie zeigen von allen Problemen diejenigen, die noch nicht quittiert wurden. Die Quittierung (acknowledgment) ist eine Art „zur Kenntnisnahme“ eines Problems, das wir später besprechen werden.

Die letzte Spalte zeigt Hosts oder Services, deren Information „veraltet“ (stale) ist, da über sie zurzeit keine aktuellen Monitoring-Daten vorliegen. Wenn z.B. ein Host aktuell gar nicht erreichbar ist, kann Checkmk auch keine Neuigkeiten über dessen Services ermitteln. Das bedeutet aber nicht automatisch, dass diese ein Problem haben. Deswegen nimmt Checkmk nicht einfach einen neuen Status für diese Services an, sondern setzt sie auf den Pseudostatus „Stale“. Die Spalte Stale wird von Checkmk weggelassen, wenn sie überall 0 zeigen würde.

Übrigens können auch Sie im Tactical overview mit dem Knopf button showmore bestimmen, ob sie alle oder nur die wichtigsten Informationen sehen wollen.

4.3. Quicksearch

Das Snapin Quicksearch sucht für Sie Hosts und Services in der Monitoring-Umgebung. Die Suche ist sehr interaktiv: Sobald Sie etwas getippt haben, sehen Sie sofort Vorschläge für eine Vervollständigung.

quicksearch h s

Hier ein paar Tipps für die Suche:

  • Groß- und Kleinschreibung ist bei der Suche nicht relevant.

  • Wenn Sie nach Host- und Servicemustern suchen möchten, können Sie mit h: und s: arbeiten. Eine Suche nach h:win s:cpu zeigt Ihnen alle Services an, die cpu enthalten, auf Hosts, die ihrerseits win enthalten.

  • Sie müssen keinen Eintrag aus der Vorschlagsliste auswählen. Drücken Sie nach Eingabe Ihres Suchbegriffs einfach die Eingabetaste und Sie erhalten in der Hauptseite das passende Ergebnis mit allen Hosts bzw. Services.

  • Die Suchanfrage können Sie in einem Lesezeichen speichern.

Genauere Informationen zur Suche mit Schlagwörtern oder auch regulären Ausdrücken mit diesem Snapin erhalten Sie im Artikel zur Benutzeroberfläche.

Tipp: Die Quicksearch-Suche steht Ihnen zusätzlich im Monitor-Menü zur Verfügung. Für die Suche in der Konfigurationsumgebung können Sie die Suchfunktion im Setup-Menü nutzen.

4.4. Bookmarks

Für Seiten, die Sie immer wieder aufsuchen, können Sie mit dem Snapin Bookmarks Lesezeichen anlegen.

Braucht man die wirklich? Immerhin gibt es ja auch Lesezeichen im Web-Browser. Nun, die Checkmk-Lesezeichen haben ein paar Vorteile:

  • Ein aufgerufenes Lesezeichen ändert nur den Inhalt auf der Hauptseite, ohne die Seitenleiste neu zu laden.

  • Sie können Lesezeichen mit anderen Benutzern teilen.

  • Beim Setzen von Lesezeichen wird automatisch das Wiederausführen von Aktionen verhindert.

Am Anfang ist das Bookmarks-Snapin noch leer:

empty bookmarks

Wenn Sie nun auf Add Bookmark klicken, wird für den Inhalt, der gerade auf der Hauptseite angezeigt wird, ein neues Lesezeichen erzeugt und automatisch unter dem neuen Thema (topic) My Bookmarks abgelegt.

bookmarks

Einerseits gehört ein Lesezeichen zu einem Thema (so wie es im Snapin Bookmarks zu sehen ist), andererseits zu einer Liste. Thema und Liste können den gleichen Namen haben, aber es handelt sich um unterschiedliche Objekte. Intern werden die Lesezeichen nämlich als Listen organisiert. In die Verwaltung der Lesezeichenlisten steigen Sie übrigens mit dem Knopf Edit ein.

Sie können pro Liste entscheiden, ob diese anderen Benutzern bereitgestellt wird oder für Sie privat bleibt. Jedem Lesezeichen einer Liste können Sie individuell ein Thema zuweisen. Damit haben Sie die Möglichkeit auch in einer freigegebenen Liste die Lesezeichen zu Themen zu gruppieren.

Sofern Sie (noch) nicht die Freigabe von Lesezeichen an andere Benutzer planen, reicht es für den Anfang aus, sich zu merken, dass Ihre persönlichen Lesezeichen unter My Bookmarks gespeichert werden. Wenn Sie dann tiefer in das Thema einsteigen wollen, können Sie das im Artikel zur Benutzeroberfläche tun.

4.5. Master Control

Im Snapin Master Control können Sie verschiedene Funktionen des Monitorings einzeln aus- und wieder einschalten, wie z.B. die Alarmierung (Notifications). Letzteres ist sehr nützlich, wenn Sie am System größere Umbauarbeiten vornehmen und Ihre Kolleginnen nicht mit sinnlosen Meldungen ärgern möchten.

master control

Wichtig: Achten Sie darauf, dass im Normalbetrieb alle Schalter auf ON stehen, da sonst wichtige Funktionen des Monitorings abgeschaltet sein können.

4.6. Views (Statusansichten)

Das wichtigste Snapin für das Monitoring ist neben der Tactical overview jenes mit dem Titel Views. Mit diesem Snapin stehen Ihnen in der Seitenleiste alle Funktionen zur Verfügung, die Sie auch im Monitor-Menü haben. Das Snapin Views ist standardmäßig nicht in der Seitenleiste enthalten. Sie können es aber einfach durch Anklicken von button sidebar add snapin aus der Liste der verfügbaren Snapins in die Seitenleiste aufnehmen.

Eine View ist eine vordefinierte Statusansicht, die Ihnen den aktuellen Zustand von Hosts oder Services (oder teilweise auch anderen Objekten) unter einer bestimmten Perspektive anzeigt.

So eine Statusansicht kann einen Kontext haben, z.B. wenn sie alle Services des Hosts myhost012 zeigt. Andere Ansichten funktionieren global, z.B. diejenige, die Ihnen alle Services anzeigt, die gerade ein Problem haben.

All die globalen Statusansichten sind in diesem Snapin erreichbar. Die Ansichten sind dort zu Themen (topics) zusammengefasst, die einzel auf- und zuklappbar sind:

snapin views

Nach Anklicken eines Views wird Ihnen der zugehörige Inhalt in der Hauptseite angezeigt, im folgenden Beispiel die Statusansicht Service problems:

view service problems

In einer Statusansicht haben Sie zahlreiche Bedienmöglichkeiten, unter anderem:

  • Sie können zu anderen Ansichten navigieren, indem Sie bestimmte Zellen anklicken (im obigen Beispiel etwa den Host-Namen oder einen der Services).

  • Durch einen Klick auf einen Spaltentitel können Sie nach dieser Spalte sortieren.

  • Der Knopf Filter öffnet eine Suchleiste am rechten Rand, über die Sie die gezeigten Objekte filtern können — was im gezeigten Beispiel nicht wirklich notwendig, aber bei langen Listen sehr hilfreich ist.

  • Das Menü View > Modify display options blendet einige Einstellungen ein zur Anpassung der Ansicht: In der Liste Number of columns können Sie die Anzahl der angezeigten Spalten ändern (z.B. um Ihren breiten Bildschirm voll auszunutzen) und in der Liste Refresh interval stellen Sie die Anzahl an Sekunden ein, nach denen die Ansicht automatisch neu geladen wird (schließlich können sich Statusdaten jederzeit ändern).

Die Views haben noch viele weitere Möglichkeiten, und Sie können sie auch anpassen und sogar ganz eigene Ansichten selbst bauen. Wie das geht, erfahren Sie im Artikel über Views.

4.7. Messwerte (Metriken)

Die große Mehrheit der Services liefert nicht nur einen Zustand, sondern zusätzlich auch Messwerte. Nehmen wir als Beispiel den Service, der auf einem Windows-Server das Dateisystem C: prüft:

filesystem c

Neben dem Status OK sehen wir, dass ca. 38 GByte von insgesamt 50 GByte des Dateisystems belegt sind, was ca. 76 % ausmacht. Die Angaben sehen Sie in der Spalte Summary. Der wichtigste Wert davon — die Prozentangabe — wird außerdem auf der rechte Seite in der Spalte Perf-O-Meter visualisiert.

Das ist aber nur eine grobe Übersicht. Eine detaillierte Tabelle aller Messwerte eines Services finden Sie, nachdem Sie den Service angeklickt haben, in dessen Detailansicht in der Zeile Service Metrics:

service metrics

Noch interessanter ist aber, dass Checkmk automatisch den Zeitverlauf aller solcher Messwerte standardmäßig für bis zu vier Jahren aufbewahrt (in den sogenannten RRD-Dateien). Innerhalb der ersten 48 Stunden werden die Werte minutengenau gespeichert. Dargestellt werden die Zeitverläufe in Graphen wie diesem, wie er z.B. für den Service Check_MK in den CEE Checkmk Enterprise Editions dargestellt wird:

example graph

Hier ein paar Tipps, was Sie mit diesen Graphen anstellen können:

  • Zeigen Sie mit der Maus in den Graphen und ein Tooltip zeigt die genauen Messwerte für den aktuellen Zeitpunkt.

  • Mit dem Mausrad können Sie in die Zeitachse zoomen.

  • Drücken Sie mit der linken Maustaste in eine beliebigen Stelle des Graphen und ziehen Sie nach links oder rechts um das angezeigte Zeitintervall zu verändern.

  • Ziehen Sie mit gedrückter linker Maustaste nach oben oder unten, um in die vertikale Achse zu zoomen.

  • Mit dem Symbol resize graph in der Ecke rechts unten können Sie den Graphen in seiner Größe ändern.

Auch in der CRE Checkmk Raw Edition gibt es ein System zum Anzeigen von Graphen. Es basiert auf dem Nagios Add-on PNP4Nagios und ist nicht interaktiv.

Das System für die Aufzeichnung, Auswertung und Darstellung von Messdaten in Checkmk kann noch viel mehr — vor allem in den CEE Checkmk Enterprise Editions. Details dazu finden Sie im Artikel über Messwerte und Graphing.

5. Checkmk im Monitoring

5.1. Wichtige Aufgaben im Monitoring

Sie haben Hosts aufgenommen, und wir haben uns wichtige Werkzeuge angesehen: Jetzt können wir loslegen mit dem eigentlichen Monitoring. Denn der Sinn von Checkmk ist es ja nicht, sich ständig mit der Konfiguration zu befassen, sondern eine Unterstützung beim IT-Betrieb zu leisten.

Zwar zeigen Ihnen bereits die standardmäßig verfügbaren Ansichten wie z.B. das Snapin Tactical overview sehr genau, wie viele und welche Probleme es gerade gibt. Zur Abbildung eines Arbeitsablaufs (workflow), d.h. dem „richtigen Arbeiten“ mit dem Monitoring, benötigen wir aber noch etwas mehr Informationen über:

  • die Quittierung von Problemen

  • das Senden von Alarmen im Falle von Problemen

  • das Setzen von Wartungszeiten

In diesem Kapitel befassen wir uns nur mit den ersten und dem letzten Punkt. Die Alarmierung behandeln wir später in einem eigenen Kapitel, da für dieses Thema einige spezielle Vorbereitungen zu treffen sind.

5.2. Probleme quittieren

In der Tactical Overview hatten wir schon gesehen, dass Probleme entweder unbehandelt (unhandled) oder bearbeitet (handled) sein können. Das Quittieren ist nun genau die Aktion, die aus einem unbehandelten Problem ein bearbeitetes macht. Das muss nicht unbedingt heißen, dass sich wirklich jemand darum kümmert. Manche Probleme verschwinden ja auch von selbst wieder. Aber das Quittieren hilft, einen Überblick zu behalten und einen Workflow zu etablieren.

Was passiert beim Quittieren eines Problems genau?

  • In der Tactical overview wird das Problem in der Spalte Unhandled beim Host oder Service nicht mehr gezählt.

  • Das Standard-Dashboard listet das Problem ebenfalls nicht mehr auf.

  • Das Objekt (Host oder Service) wird in Statusansichten mit dem Symbol icon ack markiert.

  • Ein Eintrag erfolgt in die Objekt-History, so dass die Aktion später nachvollzogen werden kann.

  • Wiederholte Alarmierungen (falls konfiguriert) werden gestoppt.

Wie quittieren Sie nun ein Problem?

Rufen Sie zunächst eine Statusansicht auf, in der das Problem enthalten ist. Am einfachsten ist der Einstieg über die vordefinierten Statusansichten im Menü Monitor > Problems > Host & service problems, Host problems oder Service problems. Zu den letzten beiden gelangen Sie übrigens fast noch schneller, wenn Sie in der Tactical overview die Zahl der Probleme anklicken.

Sie können in der Liste den problematischen Host oder Service anklicken und dann auf der Seite mit den Details die Quittierung nur für diesen einzelnen Host oder Service durchführen. Wir bleiben aber auf der Seite mit der Liste, da Sie hier alle Optionen haben, um nur ein Problem oder gleich mehrere auf einmal zu quittieren.

Es ist gar nicht so selten, dass Sie eine Reihe (zusammengehöriger) Probleme auf einmal quittieren wollen. Das geht einfach, indem Sie sich mit einem Klick auf Show checkboxes eine neue erste Spalte in der Liste einblenden lassen, die eine Checkbox vor jeder Zeile enthält. Die Checkboxen sind alle nicht markiert, denn die Auswahl treffen Sie: Markieren Sie die Checkbox für jeden gewünschten Host oder Service.

Wichtig: Wenn Sie auf einer Seite mit einer Liste eine Aktion durchführen, ohne dass Sie Checkboxen eingeblendet haben, dann wird diese Aktion für alle Listeneinträge durchgeführt.

Klicken Sie nun auf Acknowledge problems. Dies blendet am Beginn der Seite den folgenden Bereich ein:

command acknowledge

Tragen Sie einen Kommentar ein und klicken Sie auf Acknowledge — und mit der Bestätigung der „Sind Sie sicher?“-Frage …​

really acknowledge

… gelten alle vorher ausgewählten Probleme als quittiert.

Abschließend noch einige Hinweise:

  • Mit dem Knopf Remove acknowledgement können Sie eine Quittierung auch wieder entfernen.

  • Quittierungen können automatisch ablaufen. Dazu dient die Option Expire acknowledgement after.

Weitere Informationen zu allen Quittierungsparametern erhalten Sie im Artikel zur Quittierung.

5.3. Wartungszeiten einrichten

Manchmal gehen Dinge nicht aus Versehen kaputt, sondern mit Absicht — oder etwas vorsichtiger ausgedrückt, ein Ausfall wird absichtlich in Kauf aufgenommen. Denn jedes Stück Hard- oder Software muss gelegentlich gewartet werden, und während der dazu notwendigen Umbauarbeiten wird der betroffene Host oder Service im Monitoring sehr wahrscheinlich in den Zustand DOWN oder CRIT gehen.

Für diejenigen, die auf Probleme in Checkmk reagieren sollen, ist es dabei natürlich sehr wichtig, dass sie über geplante Ausfälle Bescheid wissen und nicht wertvolle Zeit mit „Fehlalarmen“ verlieren. Um dies zu gewährleisten, kennt Checkmk das Konzept der (geplanten) Wartungszeit (in Englisch scheduled downtime oder kürzer downtime).

Wenn also für ein Objekt eine Wartung ansteht, können Sie dieses in den Wartungszustand versetzen — entweder sofort oder aber auch für einen Zeitraum in der Zukunft.

Die Einrichtung von Wartungszeiten ist sehr ähnlich zum Ablauf der Quittierung von Problemen: Sie starten wieder mit einer Statusansicht, in der das gewünschte Objekt (Host oder Service) enthalten ist, für das Sie eine Wartungszeit einrichten wollen. Zum Beispiel können Ihnen wieder die vordefinierten Statusansichten gute Dienste leisten: in Monitor > Overview > Host search oder Service search.

In der dann angezeigten Liste blenden Sie mit Show checkboxes die Checkboxen ein und wählen alle relevanten Einträge aus.

Klicken Sie nun Schedule downtimes. Dies blendet am Beginn der Seite den folgenden Bereich ein:

command downtime

Bei den Wartungszeiten gibt es einen ganzen Haufen von Optionen. Einen Kommentar müssen Sie in jedem Fall eingeben. Durch Anklicken eines Knopfs wählen Sie Beginn und Ende der Wartungszeit. So werden z.B. mit dem Knopf 2 hours die ausgewählten Objekte vom aktuellen Zeitpunkt an für zwei Stunden als „in Wartung“ deklariert. Im Gegensatz zu den Quittungen haben Wartungszeiten grundsätzlich ein Ende, das vorher festgelegt wird.

Hier noch ein paar Hinweise:

  • Wenn Sie einen Host in die Wartung schicken, werden automatisch auch alle seine Services mitgeschickt. Sparen Sie sich daher die Arbeit, dies doppelt zu tun.

  • Die flexiblen Wartungszeiten beginnen tatsächlich erst dann, wenn das Objekt in einen anderen Zustand als OK wechselt.

  • Wenn Sie die CEE Checkmk Enterprise Editions nutzen, können Sie auch regelmäßige Wartungszeiten definieren (z.B. wegen eines obligatorischen Reboots einmal in der Woche).

  • Einen Überblick über aktuell laufende Wartungszeiten erhalten Sie in Monitor > Overview > Scheduled downtimes.

Die Auswirkungen einer Wartungszeit sind folgende:

  • In der Tactical overview tauchen die betroffenen Objekte (Hosts und Services) nicht mehr als Probleme auf.

  • Die Objekte werden in Statusansichten mit dem Symbol icon derived downtime markiert.

  • Die Alarmierung über Probleme ist während der Wartung abgeschaltet.

  • Zu Beginn und Ende einer Wartungszeit wird eine spezielle Alarmierung ausgelöst.

  • In der Verfügbarkeitsanalyse werden geplante Wartungszeiten gesondert berücksichtigt.

Eine detaillierte Beschreibung zu allen genannten und weiteren Aspekten finden Sie im Artikel zu Wartungszeiten.

6. Das Monitoring feinjustieren

6.1. Fehlalarme — der Tod jedes Monitorings

Ein Monitoring ist nur dann wirklich nützlich, wenn es präzise ist. Das größte Hindernis für die Akzeptanz bei Kollegen (und wohl auch bei Ihnen selbst) sind dabei false positives — oder auf gut deutsch Fehlalarme.

Bei einigen Checkmk-Einsteigern haben wir erlebt, wie diese in kurzer Zeit sehr viele Systeme in die Überwachung aufgenommen haben — vielleicht deswegen, weil das in Checkmk so einfach geht. Als sie dann kurz danach die Alarmierung für alle aktiviert haben, wurden die Kolleginnen mit Hunderten von E-Mails pro Tag überflutet, und bereits nach wenigen Tagen war die Begeisterung für das Monitoring nachhaltig zerstört.

Auch wenn Checkmk sich wirklich Mühe gibt, für alle möglichen Einstellungen sinnvolle und vernünftige Standardwerte zu definieren, kann es einfach nicht präzise genug wissen, wie es in Ihrer IT-Umgebung unter Normalzuständen zugehen soll. Deswegen ist von Ihrer Seite ein bisschen Handarbeit erforderlich, um das Monitoring fein zu justieren (fine-tuning) bis auch der letzte Fehlalarm gar nicht erst gesendet wird. Abgesehen davon wird Checkmk auch etliche wirkliche Probleme finden, von denen Sie und Ihre Kolleginnen noch nichts geahnt haben. Auch die gilt es zuerst einmalig zu beheben — und zwar in der Realität, nicht im Monitoring!

Bewährt hat sich folgender Grundsatz: erst Qualität, dann Quantität — oder anders ausgedrückt:

  • Nehmen Sie nicht zu viele Hosts auf einmal ins Monitoring auf.

  • Sorgen Sie dafür, dass alle Services, bei denen nicht wirklich ein Problem besteht, zuverlässig auf OK sind.

  • Aktivieren Sie die Alarmierung per E-Mail oder SMS erst, wenn Checkmk eine Zeit lang zuverlässig ohne oder mit sehr wenigen Fehlalarmen läuft.

Hinweis: Fehlalarme können natürlich nur bei eingeschalteter Alarmierung entstehen. Worum es im folgenden also geht, ist es die Vorstufe der Alarmierung abzustellen und die kritischen Zustände DOWN, WARN oder CRIT für unkritische Probleme zu vermeiden.

Welche Möglichkeiten zum Fine-Tuning Sie haben (damit all das grün wird, was keine Probleme verursacht), und wie Sie gelegentliche Aussetzer in den Griff bekommen, zeigen wir Ihnen in den folgenden Kapiteln zur Konfiguration.

6.2. Regelbasiert konfigurieren

Bevor wir ans Konfigurieren gehen, müssen wir uns zuerst kurz mit den Einstellungen von Hosts und Services in Checkmk auseinandersetzen. Da Checkmk für große und komplexe Umgebungen entwickelt wurde, geschieht das anhand von Regeln. Dieses Konzept ist sehr leistungsfähig und bringt auch in kleineren Umgebungen viele Vorteile.

Die Grundidee ist, dass Sie nicht für jeden Service jeden einzelnen Parameter explizit festlegen, sondern so etwas umsetzen wie: „Auf allen produktiven Oracle-Servern werden Dateisysteme mit dem Präfix /var/ora bei 90 % Füllgrad _WARN und bei 95 % _CRIT.“

So eine Regel kann mit einem Schlag Schwellwerte für Tausende von Dateisystemen festlegen. Gleichzeitig dokumentiert sie auch sehr übersichtlich, welche Überwachungsrichtlinien in Ihrem Unternehmen gelten.

Basierend auf einer Grundregel können Sie dann Ausnahmen für Einzelfälle gesondert festlegen. Eine passende Regel könnte so aussehen: „Auf dem Oracle-Server srvora123 wird das Dateisystem /var/ora/db01 bei 96 % Füllgrad WARN _und bei 98 % _CRIT.“ Diese Ausnahmeregel wird in Checkmk in der gleichen Art und Weise wie die Grundregel festgelegt.

Jede Regel hat den gleichen Aufbau. Sie besteht immer aus einer Bedingung und einem Wert. Zusätzlich können Sie noch eine Beschreibung und einen Kommentar hinterlegen, um den Sinn der Regel zu dokumentieren.

Die Regeln sind in Regelsätzen (rulesets) organisiert. Für jede Art von Parameter hat Checkmk einen passenden Regelsatz parat, so dass Sie aus mehreren hundert Regelsätzen auswählen können. So gibt es etwa einen mit dem Namen Filesystems (used space and growth), der die Schwellwerte für alle Services festlegt, die Dateisysteme überwachen. Um das obige Beispiel umzusetzen, würden Sie aus diesem Regelsatz die Grundregel und die Ausnahmeregel festlegen. Um festzustellen, welche Schwellwerte für ein bestimmtes Dateisystem gültig sind, geht Checkmk alle für den Check gültigen Regeln der Reihe nach durch. Die erste Regel, bei der die Bedingung zutrifft, legt den Wert fest — also in diesem Fall den Prozentwert, bei dessen Erreichen der Dateisystemcheck WARN oder CRIT wird.

6.3. Regeln finden

Sie haben verschiedene Möglichkeiten zum Zugriff auf das Regelwerk von Checkmk.

Zum einen finden Sie die Regelsätze im Setup-Menü unter den Themen der Objekte, für die es Regelsätze gibt (Hosts, Services und Agents) in verschiedenen Kategorien. Für Services gibt es die folgenden Einträge mit Regelsätzen: Service monitoring rules, Discovery rules, Enforced services, HTTP, TCP, Email, …​ und Other services. Wenn Sie einen dieser Einträge auswählen, werden Ihnen die zugehörigen Regelsätze auf der Hauptseite aufgelistet. Das können eine Handvoll sein, aber auch sehr, sehr viele wie bei den Service monitoring rules. Daher haben Sie auf der Ergebnisseite die Möglichkeit zu filtern: im Filter-Feld der Menüleiste.

Wenn Sie sich unsicher sind, in welcher Kategorie der Regelsatz zu finden ist, können Sie auch gleich alle Regeln durchsuchen, indem Sie über Setup # > [.guihint]#General > Rule search die Seite zur Regelsuche öffnen. Wir werden diesen Weg im folgenden Kapitel gehen, in der wir die Erstellung einer Regel vorstellen.

Bei der großen Anzahl der verfügbaren Regelsätze ist es mit oder ohne Suche nicht immer einfach, den richtigen zu finden. Es gibt aber noch einen anderen Weg, mit dem Sie auf die passenden Regeln für einen bereits existierenden Service zugreifen können. Klicken in einer Statusansicht mit dem Service auf das icon menu Menü und wählen Sie den Eintrag Parameters for this service:

service rule icon

Sie erhalten eine Seite, von der aus Sie Zugriff auf alle Regelsätze dieses Services haben:

parameters of this service

Im ersten Kasten mit dem Titel Check origin and parameters führt Sie der Eintrag Filesystems (used space and growth) direkt zum Regelsatz für die Schwellwerte der Dateisystemüberwachung. Sie können aber in der Übersicht sehen, dass Checkmk bereits Standardwerte festgelegt hat, so dass Sie eine Regel nur dann erstellen müssen, wenn Sie diese ändern wollen.

6.4. Regeln erstellen

Wie sieht das mit den Regeln nun in der Praxis aus? Am besten starten Sie damit, die Regel, die Sie umsetzen wollen, in einem Satz zu formulieren, etwa in diesem: „Auf allen produktiven Oracle-Servern werden die Tablespaces DW20 und DW30 bei 90 % Füllgrad _WARN und bei 95 % _CRIT.“

Dann suchen Sie sich den passenden Regelsatz — in diesem Beispiel über die Regelsuche: Setup # > [.guihint]#General > Rule search. Dies öffnet die folgende Seite, in der Sie nach „Oracle“ oder nach „tablespace“ suchen können (Groß- und Kleinschreibung spielen keine Rolle) und alle Regelsätze finden, die diesen Text im Namen oder in der (hier unsichtbaren) Beschreibung enthalten:

ruleset search tablespace

Der Regelsatz Oracle Tablespaces wird in zwei Kategorien gefunden. Klicken Sie auf den Namen in der Kategorie Service monitoring rules, so landen Sie in der Übersichtsseite des Regelsatzes:

ruleset oracle tablespaces

Der Regelsatz enthält noch keine Regeln. Sie können die erste mit dem Knopf Create rule in folder erstellen. Dabei legen Sie bereits den ersten Teil der Bedingung der Regel fest, nämlich in welchem Ordner diese gelten soll. Wenn Sie die Voreinstellung Main directory z.B. auf Windows ändern, so gilt die neue Regel nur für Hosts die direkt im oder unterhalb vom Ordner Windows liegen.

Das Anlegen (und auch das spätere Bearbeiten) der Regel bringt Sie zu einem Formular mit drei Kästen Rule Properties, Value und Conditions. Wir werden uns die drei nacheinander vornehmen.

rule ora properties

Im Kasten Rule Properties sind alle Angaben optional. Neben den informativen Texten haben Sie hier auch die Möglichkeit, eine Regel vorübergehend zu deaktivieren. Das ist praktisch, denn so vermeiden Sie manchmal ein Löschen und Neuanlegen, wenn Sie eine Regel vorübergehend nicht benötigen.

Was Sie im Kasten Value finden, hängt individuell vom Inhalt dessen ab, was gerade geregelt wird:

rule ora value

Wie Sie sehen, kann das schon eine ganze Menge an Parametern sein. Das Beispiel zeigt einen typischen Fall: Jeder einzelne Parameter kann per Checkbox aktiviert werden, und die Regel legt dann auch nur diesen fest. Sie können z.B. einen anderen Parameter von einer anderen Regel bestimmen lassen, wenn das Ihre Konfiguration vereinfacht. Im Beispiel werden nur die Schwellwerte für den prozentualen freien Platz im Tablespace definiert.

Der Kasten Conditions zur Festlegung der Bedingung sieht auf den ersten Blick etwas unübersichtlicher aus:

rule ora condition

Wir gehen nur auf die Parameter ein, die wir für die Festlegung der Beispielregel unbedingt benötigen:

Den Ordner (Folder) haben Sie beim Erstellen der Regel bereits ausgewählt, aber hier können Sie ihn nochmal ändern.

Die Host-Merkmale (Host tags) sind ein ganz wichtiges Feature von Checkmk, deshalb widmen wir ihnen gleich im Anschluss an dieses ein eigenes Kapitel. An dieser Stelle nutzen Sie eines der vordefinierten Host-Merkmale aus, um festzulegen, dass die Regel nur für Produktivsysteme gelten soll: Wählen Sie zunächst in der Liste die Host-Merkmalgruppe Criticality aus und klicken Sie danach auf Add tag condition und wählen den Wert Productive system aus.

Sehr wichtig für das Beispiel sind die Explicit Tablespaces, welche die Regel auf ganz bestimmte Services einschränken. Dazu sind zwei Anmerkungen wichtig:

  • Der Name dieser Bedingung passt sich dem Regeltyp an. Wenn hier Explicit Services steht, geben Sie die Namen der betroffenen Services an. Ein solcher könnte z.B. Tablespace DW20 lauten — also inklusive des Worts Tablespace. Im gezeigten Beispiel hingegen möchte Checkmk von Ihnen lediglich den Namen des Tablespaces selbst wissen, also z.B. DW20.

  • Die eingegebenen Texte werden immer gegen den Anfang gematcht. Die Eingabe von DW20 greift also auch auf einen fiktiven Tablespace DW20A. Wenn Sie das verhindern möchten, hängen Sie das Zeichen $ an das Ende an, also DW20$, denn es handelt sich hier um sogenannte reguläre Ausdrücke.

Hinweis: Die detaillierte Beschreibung aller anderen Parameter und eine ausführliche Erklärung zum wichtigen Konzept der Regeln finden Sie im Artikel über Regeln. Mehr zu den Service labels, dem letzten Parameter im obigen Bild, erfahren Sie übrigens im Artikel über Labels.

Nachdem alle Eingaben zur Festlegung komplett sind, sichern Sie die Regel mit Save. Nach dem Speichern findet sich im Regelsatz genau die eine neue Regel:

ruleset ora one rule

Tipp: Wenn Sie statt mit einer später mit Hunderten von Regeln arbeiten, droht die Gefahr, den Überblick zu verlieren. Checkmk bietet auf jeder Seite, die Regeln auflisten, im Menü Rules sehr hilfreiche Einträge an, um den Überblick zu behalten: Sie können sich die in der aktuellen Instanz genutzten Regeln anzeigen lassen (Used rulesets) und umgekehrt auch die, die gar nicht genutzt werden (Ineffective rules).

6.5. Host-Merkmale (host tags)

So funktionieren Host-Merkmale

Im vorherigen Kapitel haben wir ein Beispiel für eine Regel gesehen, die nur für „produktive“ Systeme gelten soll. Genauer gesagt haben wir in der Regel eine Bedingung über das Host-Merkmal (host tag) Productive system definiert. Warum haben wir die Bedingung als Merkmal definiert und sie nicht einfach für den Ordner festgelegt? Nun, Sie können nur eine einzige Ordnerstruktur definieren, und jeder Host kann nur in einem Ordner sein. Es gibt aber viele unterschiedliche Merkmale, die ein Host haben kann. Dafür ist die Ordnerstruktur zu beschränkt und nicht flexibel genug.

Dagegen können Sie Host-Merkmale den Hosts völlig frei und beliebig zuordnen — egal, in welchem Ordner sich die Hosts befinden. In Ihren Regeln können Sie sich dann auf diese Merkmale beziehen. Das macht die Konfiguration nicht nur einfacher, sondern auch leichter verständlich und weniger fehleranfällig, als wenn Sie für jeden Host alles explizit festlegen würden.

Aber wie und wo legt man nun fest, welche Hosts welche Merkmale haben sollen? Und wie können Sie eigene Merkmale definieren?

Host-Merkmale definieren

Beginnen wir mit der Antwort auf die zweite Frage nach eigenen Merkmalen. Zunächst müssen Sie wissen, dass Merkmale in Gruppen organisiert sind, den sogenannten Host-Merkmalsgruppen (host tag groups). Nehmen wir als Beispiel den Standort (location). Eine Merkmalsgruppe könnte Location heißen, und diese Gruppe könnte die Merkmale Munich, Austin und Singapore enthalten. Grundsätzlich gilt dabei, dass jedem Host aus jeder Merkmalsgruppe genau ein Merkmal zugewiesen wird. Sobald Sie also eine eigene Merkmalsgruppe definieren, trägt jeder Host eines der Merkmale aus dieser Gruppe. Hosts, bei denen Sie kein Merkmal aus der Gruppe gewählt haben, bekommen einfach per Default das erste zugewiesen.

Die Definition der Host-Merkmalsgruppen finden Sie im Setup-Menü: Setup > Hosts > Tags:

wato tag groups

Wie Sie sehen, sind einige Merkmalsgruppen bereits vordefiniert. Die meisten davon können Sie nicht ändern. Wir empfehlen Ihnen außerdem, die beiden vordefinierten Beispielgruppen Criticality und Networking Segment nicht anzutasten. Definieren Sie lieber Ihre eigenen Gruppen:

Klicken Sie auf Add tag group. Dies öffnet die Seite zum Erstellen einer neuen Merkmalsgruppe. Im ersten Kasten Basic settings vergeben Sie — wie so oft in Checkmk — eine interne ID, die als Schlüssel dient und später nicht mehr geändert werden kann. Zusätzlich zur ID legen Sie einen sprechenden Titel fest, den Sie später jederzeit ändern können. Mit Topic können Sie bestimmen, wo das Merkmal bei den Eigenschaften des Hosts später angeboten wird. Wenn Sie hier ein neues Topic erstellen, wird das Merkmal bei den Host-Eigenschaften in einem eigenen Kasten angezeigt.

new taggroup basic

Im zweiten Kasten Tag choices geht es um die eigentlichen Merkmale, also die Auswahlmöglichkeiten der Gruppe. Klicken Sie Add tag choice um ein Merkmal zu erstellen und vergeben Sie auch hier pro Merkmal eine interne ID und einen Titel:

new taggroup choices

Hinweise:

  • Die IDs müssen über alle Gruppen hinweg eindeutig sein.

  • Auch Gruppen mit nur einer einzigen Auswahl sind erlaubt und sogar sinnvoll. Diese erscheinen dann als Checkboxen. Jeder Host hat dann das Merkmal —  oder eben nicht.

  • An dieser Stelle können Sie die Hilfsmerkmale (auxiliary tags) erstmal ignorieren. Sie erhalten alle Informationen zu Hilfsmerkmalen im speziellen und zu Host-Merkmalen im allgemeinen im Artikel über Regeln.

Sobald Sie mit Save die neue Host-Merkmalsgruppe gesichert haben, können Sie sie nutzen.

Ein Merkmal einem Host zuordnen

Wie Sie einem Host Merkmale zuordnen, haben Sie schon gesehen: in den Host-Eigenschaften beim Erstellen oder Bearbeiten eines Hosts. Im Kasten Custom attributes (oder in einem eigenen, falls Sie ein Topic erstellt haben) taucht nun die neue Host-Merkmalsgruppe auf, und Sie können für den Host die Auswahl treffen und das Merkmal festlegen:

host custom attributes

Nachdem Sie jetzt die wichtigen Prinzipien der Konfiguration mit Regeln und Host-Merkmalen kennengelernt haben, möchten wir Ihnen in den restlichen Kapiteln einige konkrete Empfehlungen geben, um in einem neuen Checkmk-System Fehlalarme zu reduzieren.

6.6. Dateisystem-Schwellwerte anpassen

Überprüfen Sie die Schwellwerte für die Überwachung von Dateisystemen und passen Sie diese gegebenenfalls an. Die Standardwerte hatten wir bereits weiter oben bei der Suche nach Regeln kurz gezeigt.

Per Default nimmt Checkmk beim Füllgrad von Dateisystemen die Schwellen 80 % für WARN und 90 % für CRIT. Nun sind 80 % bei einer 2 TByte großen Festplatte immerhin 400 GByte — vielleicht ein bisschen viel Puffer für eine Warnung. Daher hier ein paar Tipps zum Thema Dateisysteme:

  • Legen Sie Ihre eigenen Regeln an im Regelsatz Filesystem (used space and growth).

  • Die Parameter erlauben Schwellwerte, die von der Größe des Dateisystems abhängen. Wählen Sie dazu Levels for filesystems > Levels for filesystem used space > Dynamic levels. Mit dem Knopf Add new element definieren Sie jetzt pro Plattengröße eigene Schwellwerte.

  • Noch einfacher geht es mit dem Magic factor, den wir im Best Practises Kapitel vorstellen.

6.7. Hosts in die Wartung schicken

Manche Server werden turnusmäßig neu gestartet — sei es, um Patches einzuspielen oder einfach, weil das so vorgesehen ist. Sie können Fehlalarme zu diesen Zeiten auf zwei Arten vermeiden:

CRE In der CRE Checkmk Raw Edition definieren Sie zunächst eine Zeitperiode (timeperiod), welche die Zeiten des Reboots abdeckt. Wie das geht, erfahren Sie im Artikel über Zeitperioden. Danach legen Sie jeweils eine Regel in den Regelsätzen Notification period for hosts und Notification period for services für die betroffenen Hosts an und wählen dort die zuvor definierte Zeitperiode aus. Die zweite Regel für die Services ist nötig, damit auch Services, die in dieser Zeit auf CRIT gehen, keinen Alarm auslösen. Falls nun während dieser Zeiten Probleme auftreten (und rechtzeitig wieder verschwinden), wird keine Alarmierung ausgelöst.

CEE In den CEE Checkmk Enterprise Editions gibt es regelmäßige Wartungszeiten für diesen Zweck, die Sie für die betroffenen Hosts setzen können.

Tipp: Eine Alternative zur Erstellung von Wartungszeiten für Hosts, die wir im Kapitel zu Wartungszeiten oben schon beschrieben haben, ist in den Enterprise Editions der Regelsatz Recurring downtimes for hosts. Dieser hat den großen Vorteil, dass auch Hosts, die erster später in die Überwachung aufgenommen werden, automatisch diese Wartungszeiten erhalten.

6.8. Abgeschaltete Hosts ignorieren

Nicht immer ist es ein Problem, wenn ein Rechner abgeschaltet wird. Ein klassisches Beispiel sind Drucker. Diese mit Checkmk zu überwachen ist durchaus sinnvoll. Manche Anwender organisieren sogar die Nachbestellung von Toner mit Checkmk. In aller Regel ist aber das Ausschalten eines Druckers vor Feierabend kein Problem. Dumm ist nur, wenn Checkmk hier alarmiert, weil der entsprechende Host DOWN ist.

Sie können Checkmk mitteilen, dass es völlig in Ordnung ist, wenn ein Host ausgeschaltet ist. Dazu suchen Sie den Regelsatz Host check command und setzen Sie den Wert auf Always assume host to be up:

host check command

Stellen Sie im Kasten Conditions sicher, dass diese Regel wirklich nur auf die passenden Hosts angewendet wird — je nach der von Ihnen gewählten Struktur. Sie können dazu z.B. ein Host-Merkmal definieren und hier nutzen oder Sie können die Regel über einen Ordner festlegen, in dem sich alle Drucker befinden.

Jetzt werden alle Drucker grundsätzlich als UP angezeigt — egal, wie ihr Status tatsächlich ist.

Die Services des Druckers werden allerdings weiterhin geprüft und ein Timeout würde zu einem CRIT Zustand führen. Um auch dies zu vermeiden, konfigurieren Sie für die betroffenen Hosts im Regelsatz Status of the Checkmk services eine Regel, in der Sie Timeouts und Verbindungsprobleme jeweils auf OK setzen:

rule status of cmk services

6.9. Switchports konfigurieren

Wenn Sie mit Checkmk einen Switch überwachen, dann werden Sie feststellen, dass bei der Service-Konfiguration automatisch für jeden Port, der zu dem Zeitpunkt UP ist, ein Service angelegt wird. Dies ist eine sinnvolle Standardeinstellung für Core- und Distribution-Switches — also solche, an denen nur Infrastrukturgeräte oder Server angeschlossen sind. Bei Switches, an denen Endgeräte wie Arbeitsplätze oder Drucker angeschlossen sind, führt das aber einerseits zu ständigen Alarmen, falls ein Port auf DOWN geht, und andererseits zu ständig neu gefundenen Services, weil ein bisher nicht überwachter Port umgekehrt UP geht.

Hier haben sich zwei Vorgehensweisen bewährt: So können Sie erstens die Überwachung auf die Uplink-Ports beschränken. Dazu legen Sie eine Regel bei den deaktivierten Services an, welche die anderen Ports von der Überwachung ausschließt.

Viel interessanter ist jedoch die zweite Methode: Hier überwachen Sie zwar alle Ports, erlauben aber den Zustand DOWN als gültigen Zustand. Der Vorteil: Auch für Ports, an denen Endgeräte hängen, haben Sie eine Überwachung der Übertragungsfehler und erkennen so sehr schnell schlechte Patchkabel oder Fehler in der Autonegotiation. Um das umzusetzen, benötigen Sie zwei Regeln:

Der erste Regelsatz Network interface and switch port discovery legt fest, unter welchen Bedingungen Switchports überwacht werden sollen. Legen Sie eine Regel für die gewünschten Switches an und wählen Sie aus, ob einzelne Interfaces (Configure discovery of single interfaces) oder Gruppen (Configure grouping of interfaces) gefunden werden sollen. Aktivieren Sie dann unter Conditions for this rule to apply > Match port states zusätzlich zu 1 - up auch 2 - down:

port discovery

In der Service-Konfiguration der Switches werden nun auch die Ports mit dem Zustand DOWN angeboten, und Sie können sie zur Liste der überwachten Services hinzufügen. Bevor Sie die Änderung aktivieren, benötigen Sie noch die zweite Regel, die dafür sorgt, dass dieser Zustand als OK gewertet wird.

Der Regelsatz heißt Network interfaces and switch ports. Erstellen Sie eine neue Regel und aktivieren Sie die Option Operational state, deaktivieren Sie darunter Ignore the operational state und aktivieren Sie dann bei den Allowed operational states die Zustände 1 - up und 2 - down (und eventuell weitere Zustände).

6.10. Services dauerhaft deaktivieren

Bei manchen Services, die einfach nicht zuverlässig auf OK zu bekommen sind, ist es am Ende besser, sie gar nicht zu überwachen. Hier könnten Sie nun einfach bei den betroffenen Hosts in der Service-Konfiguration (auf der Seite Services of host) die Services manuell aus der Überwachung herausnehmen, indem Sie sie auf Undecided setzen. Dies ist aber umständlich und fehleranfällig.

Viel besser ist es, wenn Sie Regeln definieren, nach denen bestimmte Services systematisch nicht überwacht werden. Dafür gibt es den Regelsatz Disabled services. Hier können Sie z.B. eine Regel anlegen, nach der Dateisysteme mit dem Mount-Punkt /var/test grundsätzlich nicht überwacht werden sollen.

Tipp: Wenn Sie in der Service-Konfiguration eines Hosts einen einzelnen Service durch Klick auf icon service to disabled deaktivieren, wird für den Host automatisch eine Regel in eben diesem Regelsatz angelegt. Diese Regel können Sie manuell bearbeiten und z.B. den expliziten Hostnamen entfernen. Dann wird der betroffene Service auf allen Hosts abgeschaltet.

Weitere Informationen können Sie im Artikel zur Konfiguration von Services nachlesen.

6.11. Durch Mittelwert Ausreißer abfangen

Ein Grund für sporadische Alarmierungen sind oft Schwellwerte auf Auslastungsmetriken, wie z.B. die CPU-Auslastung (CPU utilization), die nur kurzfristig überschritten werden. In der Regel sind solche kurzen Spitzen kein Problem und sollten vom Monitoring auch nicht bemängelt werden.

Aus diesem Grund haben eine ganze Reihe von Check-Plugins in ihrer Konfiguration die Möglichkeit, dass die Messwerte vor der Anwendung der Schwellen über einen längeren Zeitraum gemittelt werden. Ein Beispiel dafür ist der Regelsatz für die CPU-Auslastung für nicht-Unix-Systeme mit dem Namen CPU utilization for simple devices. Hier gibt es den Parameter Averaging for total CPU utilization:

cpu util average

Wenn Sie diesen aktivieren und 15 eintragen, wird die CPU-Auslastung zunächst über einen Zeitraum von 15 Minuten gemittelt und die Schwellwerte erst danach auf diesen Mittelwert angewendet.

6.12. Sporadische Fehler kontrollieren

Wenn alles nichts hilft und Services immer wieder gelegentlich für einen einzelnen Check (also für eine Minute) auf WARN oder CRIT gehen, gibt es eine letzte Methode, die Fehlalarme verhindert: den Regelsatz Maximum number of check attempts for service.

Legen Sie dort eine Regel an und setzen Sie den Wert z.B. auf 3, so wird ein Service, der z.B. von OK auf WARN geht, zunächst noch keine Alarmierung auslösen und auch in der Tactical overview noch nicht als Problem angezeigt werden. Erst wenn der Status in drei aufeinanderfolgenden Checks (was insgesamt dann knapp über zwei Minuten dauert) nicht OK ist, wird das hartnäckige Problem gemeldet.

Das ist zugegeben keine schöne Lösung. Sie sollten immer versuchen, das Problem an der Wurzel zu packen, aber manchmal sind die Dinge einfach so, wie sie sind, und mit den „check attempts“ haben Sie für solche Fälle zumindest einen gangbaren Weg zur Umgehung.

6.13. Liste der Services aktuell halten

In einem Rechenzentrum wird ständig gearbeitet, und so wird die Liste der zu überwachenden Services nie konstant bleiben. Damit Sie dabei möglichst nichts übersehen, richtet Checkmk für Sie automatisch einen besonderen Service auf jedem Host ein. Dieser heißt Check_MK Discovery:

discovery service

Dieser prüft in der Voreinstellung alle zwei Stunden, ob neue (noch nicht überwachte) Services gefunden oder bestehende weggefallen sind. Ist dies der Fall, so geht der Service auf WARN. Sie können dann die Service-Konfiguration aufrufen (auf der Seite Services of host) und die Services wieder auf den aktuellen Stand bringen.

Tipp: Über Monitor > Analyze > Unmonitored services können Sie sich eine Statusansicht aufrufen, die Ihnen die neuen und weggefallenen Services anzeigt. Diese können Sie dann regelmäßig abarbeiten.

7. Benuter einrichten

7.1. Benutzer in Checkmk

Sobald Sie Ihr Monitoring in einem Zustand haben, wo es beginnt, für andere nützlich zu werden, ist es an der Zeit, sich mit der Benutzerverwaltung von Checkmk zu befassen. Falls Sie das System lediglich alleine betreiben, ist das Arbeiten mit cmkadmin völlig ausreichend, und Sie können einfach beim nächsten Kapitel über die Alarmierung weiterlesen.

Gehen wir also davon aus, dass Sie Kollegen haben, die gemeinsam mit Ihnen Checkmk nutzen sollen. Warum arbeiten dann nicht einfach alle als cmkadmin? Nun, theoretisch geht das schon, aber es entsteht dabei eine Reihe von Schwierigkeiten. Wenn Sie pro Person ein Konto (account) anlegen, haben Sie etliche Vorteile:

  • Unterschiedliche Benutzer können unterschiedliche Berechtigungen haben.

  • Sie können die Zuständigkeit eines Benutzers auf bestimmte Hosts und Services beschränken, so dass nur noch diese im Monitoring sichtbar sind.

  • Benutzer können eigene Lesezeichen anlegen, ihre Seitenleiste individuell einrichten und auch andere Dinge für sich anpassen.

  • Sie können ein Konto löschen, wenn ein Mitarbeiter die Firma verlässt, ohne dass das die anderen Konten beeinflusst.

Sie finden im Artikel zur Benutzerverwaltung alle Details, die über die Einführung in diesem Leitfaden für Einsteiger hinausgehen.

7.2. Rollen für Berechtigungen

Vor allem auf die beiden Punkte zu Berechtigungen und Zuständigkeiten wollen wir näher eingehen. Beginnen wir mit den Berechtigungen — also mit der Frage, wer was tun darf. Dafür verwendet Checkmk das Konzept der Rollen. Eine Rolle ist dabei nichts anderes als eine Sammlung von Berechtigungen. Jede der Berechtigungen erlaubt eine ganz bestimmte Handlung. So gibt es etwa eine Berechtigung für das Ändern der globalen Einstellungen.

Checkmk wird mit drei vordefinierten Rollen ausgeliefert, die Sie einem neuen Benutzer zuweisen:

RolleKürzelBedeutung

Administrator

admin

Ein Administrator kann alle Funktionen in Checkmk ausführen. Seine Hauptaufgabe ist die generelle Konfiguration von Checkmk, nicht das Monitoring. Dies schließt auch das Anlegen von Benutzern und Anpassen von Rollen ein.

Normal monitoring user

user

Diese Rolle ist für den Operator gedacht, der das Monitoring durchführt. Der Operator sollte grundsätzlich nur solche Hosts und Services sehen, für die er zuständig ist. Zudem besteht die Möglichkeit, dass Sie als Administrator ihm die Berechtigung geben, seine Hosts selbst zu verwalten.

Guest user

guest

Ein Gastbenutzer darf alles sehen, aber nichts ändern. Diese Rolle ist z.B. nützlich, wenn Sie einen Statusmonitor an die Wand hängen möchten, der immer eine Gesamtübersicht des Monitoring zeigt. Da ein Gastbenutzer nichts ändern kann, ist es auch möglich, dass mehrere Kollegen ein Konto mit dieser Rolle gleichzeitig verwenden.

Wie Sie die vordefinierten Rollen anpassen können, erfahren Sie im Artikel zur Benutzerverwaltung.

7.3. Kontaktgruppen für Zuständigkeiten

Der zweite wichtige Aspekt der Benutzerverwaltung ist die Festlegung von Zuständigkeiten: Wer ist für den Host mysrv024 zuständig und wer für den Service Tablespace FOO auf dem Host ora012? Wer soll den Host und Service im Monitoring sehen und eventuell alarmiert werden, wenn es ein Problem gibt?

Zuständigkeiten werden in Checkmk nicht über Rollen, sondern über Kontaktgruppen definiert. Das Wort „Kontakt“ ist im Sinne einer Alarmierung gemeint: Wen soll das Monitoring kontaktieren, wenn es ein Problem gibt?

Das Grundprinzip ist wie folgt:

  • Jeder Benutzer kann Mitglied von beliebig vielen Kontaktgruppen sein.

  • Jeder Host und jeder Service ist Mitglied von mindestens einer oder mehreren Kontaktgruppen.

Hier ist ein Beispiel für so eine Zuordnung:

contactgroup example

Wie Sie sehen, kann sowohl ein Benutzer als auch ein Host (oder Service) Mitglied mehrerer Kontaktgruppen sein. Die Mitgliedschaft in den Gruppen hat folgende Auswirkungen:

  • Ein Benutzer der Rolle user sieht im Monitoring genau die Objekte, die sich in seinen Kontaktgruppen befinden.

  • Gibt es ein Problem mit einem Host oder Service, werden (per Default) alle Benutzer alarmiert, die in mindestens einer seiner Kontaktgruppen sind.

Wichtig: Es gibt in Checkmk keine Möglichkeit, einen Host oder Service direkt einem Benutzer zuzuordnen. Das ist absichtlich nicht gewollt, da es in der Praxis zu Problemen führt — z.B. dann, wenn ein Kollege Ihr Unternehmen verlässt.

7.4. Kontaktgruppen erstellen

Zur Verwaltung der Kontaktgruppen geht es hier entlang: Setup > Users > Contact groups. Eine Kontaktgruppe mit dem Namen Everything ist bereits vordefiniert. Dieser sind automatisch alle Hosts und Services zugewiesen. Sie ist für einfache Setups gedacht, in denen es (noch) keine Aufgabenteilung gibt und Sie vorerst für alles alleine zuständig sind.

Mit Add group legen Sie eine neue Kontaktgruppe an. Hier brauchen Sie, wie gewohnt, die interne ID (Name) und den Titel (Alias), den Sie später ändern können:

wato new contact group

Im Beispiel sehen Sie eine neue Kontaktgruppe, die offensichtlich für die Windows und Linux Server zuständig sein soll.

7.5. Hosts zuordnen

Nachdem Sie alle Ihre Kontaktgruppen angelegt haben, müssen Sie einerseits Hosts und Services zuordnen und andererseits die Benutzer. Letzteres machen Sie in den Eigenschaften der Benutzer selbst: wir kommen in einem späteren Kapitel noch dazu.

Für die Zuordnung von Hosts zu Kontaktgruppen gibt es zwei Wege, die Sie auch parallel wählen können: über Regeln oder über die Eigenschaften der Hosts (oder ihrer Ordner).

Mit Regeln zuordnen

Die benötigte Regelsatz heißt Assignment of hosts to contact groups. Sie finden ihn z.B. auf der Seite Contact groups, die Sie im letzten Kapitel geöffnet hatten, im Menü Contact groups > Rules.

Auch bei einer frischen Checkmk-Installation ist der Regelsatz übrigens nicht leer. Sie finden hier eine Regel, die alle Hosts der oben erwähnten Kontaktgruppe Everything zuweist.

Legen Sie hier also selbst neue Regeln an und wählen Sie die jeweilige Kontaktgruppe, die Sie den in der Bedingung ausgewählten Hosts zuweisen wollen:

host group assignment rule

Wichtig: Greifen für einen Host mehrere Regeln, so werden alle ausgewertet und der Host bekommt auf diese Art mehrere Kontaktgruppen.

Mit Host-Eigenschaften zuzuordnen

Öffnen Sie die Eigenschaften des Hosts, z.B. über Setup > Hosts > Hosts. Klicken Sie den Host an, um die Seite Properties of host anzuzeigen. Aktivieren Sie im Kasten Basic settings die Checkbox Permissions.

host permissions

Wählen Sie in der Liste Available eine oder mehrere Kontaktgruppen aus und verschieben Sie diese mit dem Pfeil nach rechts in die Liste Selected. Aktivieren Sie die Checkbox Add these contact groups to the host.

Die Checkbox Always add host contact groups also to its services müssen Sie in der Regel nicht auswählen, denn Services erben automatisch die Kontaktgruppen ihrer Hosts. Mehr dazu erfahren Sie gleich im nächsten Kapitel.

Hinweis: Sie können den Parameter Permissions analog statt auf Host- auch auf Ordner-Ebene festlegen. Für einen Ordner werden einige zusätzliche Optionen angeboten, bei denen es darum geht, ob die Rechte auch für Unterordner gelten sollen.

7.6. Services zuordnen

Services müssen Sie nur dann Kontaktgruppen zuordnen, wenn diese von denen ihrer Hosts abweichen sollen. Dabei gilt allerdings ein wichtiger Grundsatz: Hat ein Service mindestens eine Kontaktgruppe explizit zugewiesen erhalten, dann erbt er keine Kontaktgruppen vom Host mehr.

Die Zuordnung auf Service-Ebene ermöglicht Ihnen z.B. eine Trennung von Server- und Anwendungsbetrieb: Stecken Sie z.B. den Host srvwin123 in die Kontaktgruppe Windows & Linux Servers, aber alle Services, die mit dem Präfix Oracle beginnen, in die Kontaktgruppe Oracle Administration, so werden die Windows-Administratoren die Oracle-Services nicht sehen, und die Oracle-Administratoren erhalten umgekehrt keine Details zu den Services des Betriebssystems — was oft eine sehr sinnvolle Aufteilung ist.

Sollten Sie diese Trennung nicht benötigen, dann beschränken Sie sich einfach auf die Zuordnungen für Hosts — und sind fertig.

Für die Zuordnung auf Service-Ebene ist der Regelsatz Assignment of services to contact groups zuständig. Bei der Erstellung der Regel gehen Sie analog vor, wie es im vorherigen Kapitel für die Host-Zuordnung beschrieben ist. Zusätzlich geben Sie noch Bedingungen für die Service-Namen an.

7.7. Benutzer anlegen

In die Benutzerverwaltung steigen Sie ein mit Setup > Users > Users:

wato module users

Wundern Sie sich nicht, wenn es dort außer dem Eintrag cmkadmin auch noch einen Benutzer automation gibt. Dieser „Automationsbenutzer“ ist für Zugriffe von außen gedacht (z.B. per Skript oder REST-API) und wird im Artikel zur Benutzerverwaltung genau beschrieben.

Einen neuen Benutzer legen Sie mit dem Knopf Add user auf der Seite gleichen Namens an:

wato new user identity

Im Kasten Identity geben Sie die interne ID (Username) und einen Titel (Full name) ein — hier den ausgeschriebenen Namen des Benutzers. Die Felder Email address und Pager address sind optional und dienen der Alarmierung via E-Mail bzw. SMS.

Hinweis: Tragen Sie hier vorerst noch keine E-Mail-Adresse ein. Lesen Sie zunächst die Hinweise im Kapitel über Alarmierung.

wato new user security

Im Kasten Security lassen Sie die Defaulteinstellung auf Normal user login with password und vergeben nur ein initiales Passwort. Ganz unten bei Roles können Sie dem Benutzer die Rollen zuordnen. Ordnen Sie mehr als eine Rolle zu, so erhält der Benutzer einfach das Maximum an Berechtigungen aus diesen Rollen. Für die drei vordefinierten Rollen ist das allerdings nicht sehr sinnvoll.

wato new user contact groups

Unter Contact groups können Sie jetzt aus den zuvor erstellten Kontaktgruppen auswählen. Wählen Sie die vordefinierte Gruppe Everything aus, so wird der Benutzer für alles zuständig sein, da in dieser Gruppe alle Hosts und Services enthalten sind.

Übrigens: Die beiden letzten Kästen Personal settings und Interface settings der Seite enthalten genau die Einstellungen, die ein Benutzer auch selbst in seinem Profil ändern kann über das Menü User > Edit profile. Nur Gastbenutzer (mit der Rolle Guest user) können diese Einstellungen ihres Profils nicht ändern.

Tipp: Auf der Übersichtsseite der Benutzerverwaltung Users finden Sie im Menü Related den Eintrag icon ldap LDAP & Active Directory. Wenn Sie in Ihrer Firma Active Directory oder einen anderen LDAP-Dienst einsetzen, haben Sie auch die Möglichkeit, Benutzer und Gruppen aus diesen Diensten einzubinden. Die Details dazu finden Sie im Artikel zu LDAP/Active Directory.

8. Alarmierung einschalten

8.1. Grundlegendes zur Alarmierung

Alarmierung (notification) bedeutet in Checkmk, dass Benutzer aktiv darüber benachrichtigt werden, wenn sich der Zustand eines Hosts oder Services ändert. Nehmen wir an, zu einem bestimmten Zeitpunkt geht auf dem Host mywebsrv17 der Service HTTP foo.bar von OK auf CRIT. Checkmk erkennt dies und sendet standardmäßig an alle Kontaktpersonen dieses Services eine E-Mail mit den wichtigsten Daten zu diesem Ereignis. Später ändert sich der Zustand wieder von CRIT auf OK, und die Kontakte bekommen eine erneute E-Mail — diesmal zu dem Ereignis, das Recovery genannt wird.

Dies ist aber nur die einfachste Art der Alarmierung. Es gibt zahlreiche Möglichkeiten, wie Sie das verfeinern können:

  • Sie können per SMS, Pager, Slack und anderen Internetdiensten alarmieren.

  • Sie können Alarmierungen an bestimmten Zeitfenstern festmachen, z.B. um Bereitschaftsdienste zu berücksichtigen.

  • Sie können Eskalationen definieren, falls der zuständige Kontakt nicht schnell genug aktiv wird.

  • Benutzer können selbständig Alarme „abonnieren“ oder abbestellen, wenn Sie das zulassen möchten.

  • Sie können generell über Regeln festlegen, wer wann über was alarmiert werden soll.

Bevor Sie jedoch mit der Alarmierung beginnen, sollten Sie noch Folgendes beachten:

  • Die Alarmierung ist ein optionales Feature. Manche Anwender verzichten auf die Alarmierung, da Sie einen Leitstand haben, der rund um die Uhr besetzt ist und nur mit der Statusoberfläche arbeitet.

  • Aktivieren Sie die Alarmierung zunächst nur für sich selbst und machen Sie sich für alles zuständig. Beobachten Sie mindestens ein paar Tage, wie groß das Volumen an Alarmen ist.

  • Aktivieren Sie die Alarmierung für andere Benutzer erst dann, wenn Sie die Fehlalarme (<I>false positives_) auf ein Minimum reduziert haben. Was Sie dafür tun können, haben wir im Kapitel zur Feinjustierung des Monitoring beschrieben.

8.2. Mailversand vorbereiten

Der einfachste und bei weitem üblichste Weg ist die Alarmierung per E-Mail. In einer E-Mail ist genug Platz, um auch die Graphen von Messdaten mitzusenden.

Bevor Sie per E-Mail alarmieren können, muss Ihr Checkmk-Server für das Versenden von Mails eingerichtet sein. Bei allen unterstützten Linux-Distributionen läuft das auf Folgendes hinaus:

  1. Installieren Sie einen SMTP-Serverdienst. Dies geschieht meist automatisch bei der Installation der Distribution.

  2. Geben Sie einen Smarthost an. Nach diesem werden Sie meist bei der Installation des SMTP-Servers gefragt. Der Smarthost ist ein Mailserver in Ihrem Unternehmen, der für Checkmk die Zustellung der E-Mails übernimmt. Sehr kleine Unternehmen haben meist keinen eigenen Smarthost. In diesem Fall verwenden Sie den SMTP-Server, der Ihnen von Ihrem E-Mail-Provider bereitgestellt wird.

Wenn der Mailversand korrekt eingerichtet ist, sollten Sie in der Lage sein, auf der Kommandozeile eine E-Mail zu versenden, z.B. über diesen Befehl:

OMD[mysite]:~$ echo "Testcontent" | mail -s Test harry.hirsch@example.com

Die E-Mail sollte ohne Verzögerung zugestellt werden. Falls das nicht klappt, finden Sie Hinweise in der Logdatei des SMTP-Servers im Verzeichnis /var/log. Mehr Details zum Einrichten des Mailversands unter Linux finden Sie im Artikel zur Alarmierung.

8.3. E-Mail-Alarmierung aktivieren

Wenn der E-Mail-Versand grundsätzlich funktioniert, ist das Aktivieren der Alarmierung sehr einfach. Damit ein Benutzer Alarme per E-Mail erhält, müssen die folgenden zwei Voraussetzungen erfüllt sein:

  • Dem Benutzer ist eine E-Mail-Adresse zugeordnet.

  • Der Benutzer ist für Hosts oder Services zuständig — über die Zuweisung von Kontaktgruppen.

E-Mail-Adresse und Kontaktgruppen weisen Sie über die Eigenschaften des Benutzers zu, wie wir es weiter oben im Kapitel zur Benutzerverwaltung gezeigt haben, z.B. indem Sie Ihrem Benutzerkonto cmkadmin Ihre E-Mail-Adresse hinzufügen und die Kontaktgruppe Everything.

8.4. Alarmierung testen

Es wäre ein bisschen umständlich, zum Test der Alarmierung auf ein echtes Problem zu warten oder gar eines zu provozieren. Einfacher geht das mit Fake check results, einem Kommando, mit dem Sie testweise den Zustand eines Hosts oder Services manuell verändern können — sofern Sie ein Checkmk-Administrator sind, d.h., die Rolle admin besitzen.

Sie finden Fake check results auf einem ähnlichen Weg wie die Kommandos zum Quittieren von Problemen und zur Festlegung von Wartungszeiten: Öffnen Sie eine Statusansicht mit einer Service-Liste (am schnellsten über die Tactical overview), blenden Sie die Checkboxen ein und wählen die einen Service aus — am besten einen, der gerade OK ist. Klicken Sie im Menü Commands > Fake check results:

fake check results

Klicken Sie auf Critical und bestätigen Sie die Nachfrage, um den Service auf CRIT zu setzen. Dies sollte sofort eine Alarmierung auslösen. Nach spätestens einer Minute — wenn der nächste reguläre Check ausgeführt wird — geht der Service dann von selbst wieder auf OK und eine zweite Alarmierung zum Recovery sollte ausgelöst werden.

Falls Sie keine E-Mail bekommen haben, muss das nicht gleich ein Fehler sein, denn es gibt Situationen, in denen die Alarmierung von Checkmk absichtlich unterdrückt wird, z.B.:

  • wenn die Alarmierung im Snapin Master Control ausgeschaltet ist;

  • wenn ein Host oder Service sich in einer Wartungszeit befindet;

  • wenn ein Host DOWN ist und daher keine Alarmierungen seiner Services ausgelöst werden;

  • wenn der Status in letzter Zeit zu oft gewechselt hat und der Service deswegen als icon flapping „unstetig“ (flapping) markiert wurde. Dies kann übrigens schnell passieren, wenn Sie mittels Fake check results den Zustand häufig gewechselt haben.

8.5. Alarmierung feinjustieren

Sie können Sie Alarmierung in Checkmk auf unterschiedlichste Art mit komplexen Regeln an Ihre Bedürfnisse (bzw. die Ihrer Firma) anpassen. Alle Einzelheiten dazu erfahren Sie im Artikel zur Alarmierung.

8.6. Fehlersuche

Das Alarmierungsmodul in Checkmk ist sehr komplex — einfach weil es sehr viele, sehr unterschiedliche Anforderungen abdeckt, die sich in langjähriger Praxiserfahrung als wichtig herausgestellt haben. Die Frage „Warum hat Checkmk hier nicht alarmiert?“ wird Ihnen deswegen gerade am Anfang öfter gestellt werden, als Sie vielleicht vermuten. Deswegen finden Sie hier ein paar Tipps zur Fehlersuche.

Wenn ein Alarm von einem bestimmten Service nicht ausgelöst wurde, ist der erste Schritt, die History der Alarmierung für diesen Service zu kontrollieren. Dazu öffnen Sie die Detailseite des Services (indem Sie im Monitoring auf den Service klicken). Wählen Sie im Menü Service > Service Notifications. Dort finden Sie alle Ereignisse zur Alarmierung für diesen Service chronologisch von neu nach alt aufgelistet:

service notifications broken alarm

Hier ist ein Beispiel eines Services, für den die Alarmierung versucht wurde, aber der Mailversand gescheitert ist, weil kein SMTP-Server installiert ist.

Noch mehr Informationen finden Sie in der Datei var/log/notifiy.log. Diese können Sie als Instanzbenutzer z.B. mit dem Befehl less auslesen:

OMD[mysite]:~$ less var/log/notify.log

Falls Sie less noch nicht kennen: Mit der Tastenkombination Shift + G springen Sie ans Ende der Datei (was bei Logdateien nützlich ist), und mit der Taste Q beenden Sie less.

Mit dem Kommando tail -f können Sie den Dateiinhalt auch fortlaufend beobachten. Das ist dann sinnvoll, wenn Sie nur an neuen Meldungen interessiert sind, also solchen, die erst nach der Eingabe von tail entstehen.

Hier ist ein Ausschnitt aus notify.log für eine erfolgreich ausgelöste Alarmierung:

/var/log/notify.log
2019-09-05 10:21:48 Got raw notification (server-linux-3;CPU load) context with 71 variables
2019-09-05 10:21:48 Global rule 'Notify all contacts of a host/service via HTML email'...
2019-09-05 10:21:48  -> matches!
2019-09-05 10:21:48    - adding notification of martin via mail
2019-09-05 10:21:48 Executing 1 notifications:
2019-09-05 10:21:48   * notifying martin via mail, parameters: (no parameters), bulk: no
2019-09-05 10:21:48 Creating spoolfile: /omd/sites/mysite/var/check_mk/notify/spool/cbe1592e-a951-4b70-9bac-0141d3d74986

Mit dem Einrichten der Alarmierung haben Sie den letzten Schritt vollzogen: Ihr Checkmk-System ist einsatzbereit! Damit sind die Möglichkeiten von Checkmk natürlich noch nicht ansatzweise ausgereizt. Es gibt zahlreiche Möglichkeiten zum Ausbau des Monitoring, von denen wir im nächsten Kapitel einige kurz vorstellen werden inklusive der Verweise in die Artikel, die die detaillierten Informationen zu den Themen bieten.

9. Das Monitoring weiter ausbauen

9.1. Sicherheit optimieren

Auch wenn im Monitoring „nur“ geschaut wird, ist das Thema IT-Sicherheit auch hier sehr wichtig, insbesondere bei der Anbindung und Einrichtung ferner Systeme. Im Artikel zur Sicherheit finden Sie eine Übersicht von Themen, mit denen Sie die Sicherheit Ihres Systems optimieren können.

9.2. Sehr große Umgebungen überwachen

Wenn Ihr Monitoring eine Größenordnung erreicht hat, in der Sie Tausende oder noch mehr Hosts überwachen, werden Fragen der Architektur und der Optimierung dringlicher. Ein wichtigstes Thema ist dabei das verteilte Monitoring. Dabei arbeiten Sie mit mehreren Checkmk-Instanzen, die zu einem großen System zusammengeschaltet sind und bei Bedarf global verteilt sein können.

distributed monitoring

9.3. Verfügbarkeit und SLAs

Checkmk kann sehr präzise berechnen, wie hoch die Verfügbarkeit (availability) von Hosts oder Services in bestimmten Zeiträumen war, wie viele Ausfälle es gegeben hat, wie lang diese waren und vieles mehr.

avail screenshot neu

Auf den Verfügbarkeitsdaten aufbauend ermöglicht das in den CEE Checkmk Enterprise Editions enthaltene SLA Software-Modul eine wesentlich detailliertere Auswertung zur Einhaltung von Service Level Agreements, die sogar aktiv überwacht werden können.

sla view example modern

9.4. Hardware und Software inventarisieren

Die Hardware-/Software-Inventur gehört eigentlich nicht mehr zum Monitoring, aber Checkmk kann mit den bereits vorhanden Agenten umfangreiche Informationen zu Hardware und Software Ihrer überwachten Systeme ermitteln. Dies ist sehr hilfreich für die Wartung, das Lizenzmanagement oder das automatische Befüllen von Configuration Management Databases.

inventory example

9.5. Meldungen und Ereignisse überwachen

Bisher haben wir uns nur mit der Überwachung der aktuellen Zustände von Hosts und Services befasst. Ein ganz anderes Thema ist die Auswertung spontaner Meldungen, die z.B. in Logdateien auftauchen oder per Syslog oder SNMP-Traps versendet werden. Checkmk filtert aus den eingehenden Meldungen die relevanten Ereignisse (events) heraus und hat dafür ein komplett integriertes System mit dem Namen Event Console.

ec open events

9.6. Auf Karten und Diagrammen visualisieren

Mit dem in Checkmk integrierten Add-on NagVis können Sie auf beliebigen Karten oder Diagrammen Zustände darstellen. Dies eignet sich hervorragend, um ansprechende Gesamtübersichten zu erstellen, z.B. auf einem Monitor in einem Leitstand.

nagvis map 2

9.7. Business-Intelligence (BI)

Mit dem in Checkmk integrierten Software-Modul Business-Intelligence können Sie aus den vielen einzelnen Statuswerten den Gesamtzustand von geschäftskritischen Anwendungen ableiten und übersichtlich darstellen.

bi downtimes

9.8. PDF-Berichte erstellen

Die in Checkmk zur Verfügung stehenden Informationen (Ansichten, Verfügbarkeitstabellen, Graphen, Logos, und vieles mehr) können zu Berichten zusammengestellt und als druckfähige PDF-Dokumente exportiert werden. PDF-Berichte können nur in den CEE Checkmk Enterprise Editions erstellt werden.

9.9. Agenten automatisch updaten

Wenn Sie viele Linux- und Windows-Server überwachen, können Sie den in den CEE Checkmk Enterprise Editions enthaltenen Agent-Updater benutzen, um Ihre Monitoring-Agenten und deren Konfiguration zentralisiert auf dem gewünschten Stand zu halten.

9.10. Eigene Plugins entwickeln

Auch wenn Checkmk fast 2000 Check-Plugins mit ausliefert, kann es trotzdem vorkommen, dass ein konkretes Plugin fehlt. Eine Einführung in die Entwicklung eigener Plugins erhalten Sie im Artikel zum Schreiben von Check-Plugins.

10. Best Practises, Tipps & Tricks

10.1. CPU-Auslastung aller Kerne einzeln überwachen

Checkmk richtet sowohl unter Linux als auch unter Windows automatisch einen Service ein, der die durchschnittliche Auslastung der CPU-Leistung über die letzte Minute überwacht. Dies ist einerseits sinnvoll, erkennt aber andererseits einige Fehler nicht, beispielsweise den, dass ein einzelner Prozess Amok läuft und permanent eine CPU mit 100 % belastet. Bei einem System mit 16 CPUs trägt eine CPU aber nur mit 6.25 % zur Gesamtleistung bei, und so wird selbst im geschilderten Extremfall nur eine Auslastung von 6.25 % gemessen — was dann nicht zu einer Alarmierung führt.

Deswegen bietet Checkmk die Möglichkeit (für Linux und für Windows), alle vorhandenen CPUs einzeln zu überwachen und festzustellen, ob einer der Kerne über längere Zeit permanent ausgelastet ist. Diesen Check einzurichten, hat sich als gute Idee herausgestellt.

Um diese Überprüfung für Ihre Windows-Server einzurichten, benötigen Sie für den Service CPU utilization den Regelsatz CPU utilization for simple devices, der für die Überwachung aller CPUs zuständig ist, aber auch diesen Parameter im Angebot hat: Levels over an extended time period on a single core CPU utilization.

Erstellen Sie eine neue Regel und aktivieren Sie in dieser nur diesen Parameter:

cpu single core

Definieren Sie die Bedingung so, dass sie nur für die Windows-Server greift, z.B. durch einen geeigneten Ordner oder ein Hostmerkmal. Diese Regel wird andere Regeln im gleichen Regelsatz nicht beeinflussen, wenn diese andere Parameter festlegen, z.B. die Schwellwerte für die Gesamtauslastung.

Bei Linux-Servern ist dafür die Regelsatz CPU utilization on Linux/UNIX zuständig, in dem Sie den gleichen Parameter setzen können.

10.2. Windows-Dienste überwachen

In der Voreinstellung überwacht Checkmk auf Ihren Windows-Servern keine Dienste. Warum nicht? Nun, weil Checkmk nicht weiß, welche Dienste für Sie wichtig sind.

Wenn Sie sich nicht die Mühe machen wollen, für jeden Server von Hand festzulegen, welche Dienste dort wichtig sind, können Sie auch einen Check einrichten, der einfach überprüft, ob alle Dienste mit der Startart „automatisch“ auch wirklich laufen. Zusätzlich können Sie sich informieren lassen, ob Dienste laufen, die manuell — quasi außer der Reihe — gestartet wurden. Diese werden nach einem Reboot nicht mehr laufen, was ein Problem sein kann.

Um dies umzusetzen, benötigen Sie zunächst eine Regel aus dem Regelsatz Windows Services, den Sie z.B. über die Suchfunktion Setup > General > Rule search finden können. Der entscheidende Parameter in der neuen Regel lautet Service states. Aktivieren Sie diesen und fügen Sie drei neue Elemente für die Zustände der Dienste hinzu:

windows services rule

Dadurch erreichen Sie folgende Überwachung:

  • Ein Dienst mit der Startart auto, der läuft, gilt als OK.

  • Ein Dienst mit der Startart auto, der nicht läuft, gilt als CRIT.

  • Ein Dienst mit der Startart demand, der läuft, gilt als WARN.

Diese Regel gilt allerdings nur für Services, die auch wirklich überwacht werden. Daher benötigen wir noch einen zweiten Schritt und eine zweite Regel, diesmal aus dem Regelsatz Windows service discovery, mit der Sie festlegen, welche Windows-Dienste Checkmk als Services überwachen soll.

Wenn Sie diese Regel anlegen, können Sie zunächst beim Parameter Services (Regular Expressions) den regulären Ausdruck .* eingeben, der auf alle Services zutrifft.

Nach dem Sichern der Regel wechseln Sie für einen passenden Host in die Service-Konfiguration. Dort werden Sie eine große Zahl von neuen Services finden — für jeden Windows-Dienst einen.

Um die Anzahl der überwachten Services auf die für Sie interessanten einzuschränken, kehren Sie zu der Regel zurück und verfeinern die Suchausdrücke nach Bedarf. Dabei wird Groß- und Kleinschreibung unterschieden. Hier ist ein Beispiel für eine angepasste Service-Auswahl:

windows service discovery

Sollten Sie Services, die den neuen Suchausdrücken nicht entsprechen, zuvor schon in die Überwachung aufgenommen haben, erscheinen diese jetzt in der Service-Konfiguration als fehlend. Mit dem Knopf Full service scan können Sie reinen Tisch machen und die ganze Service-Liste neu erstellen lassen.

10.3. Internetverbindung überwachen

Der Zugang Ihrer Firma zum Internet ist sicherlich für alle sehr wichtig. Die Überwachung der Verbindung zu „dem Internet“ ist dabei etwas schwierig umzusetzen, da es um Milliarden von Rechnern geht, die (hoffentlich) erreichbar sind — oder eben nicht. Sie können aber trotzdem effizient eine Überwachung einrichten, nach folgendem Bauplan:

  1. Wählen Sie mehrere Rechner im Internet, die normalerweise per ping-Kommando erreichbar sein sollten, und notieren Sie deren IP-Adressen.

  2. Legen Sie in Checkmk einen neuen Host an, etwa mit dem Namen internet und konfigurieren diesen wie folgt: Als IPv4 Address geben Sie eine der notierten IP-Adressen ein. Unter Additional IPv4 addresses tragen Sie die restlichen IP-Adressen ein. Aktivieren Sie die Datenquelle Checkmk Agent und setzen Sie sie auf No agent. Speichern Sie den Host ohne Serviceerkennung.

  3. Erstellen Sie eine neue Regel aus dem Regelsatz Check hosts with PING (ICMP Echo Request), die nur für den neuen Host internet greift (z.B. über die Bedingung mit Explicit hosts oder einem passenden Hostmerkmal). Konfigurieren die Regel wie folgt: Aktivieren Sie Service description und geben Sie Internet connection ein. Aktivieren Sie Alternative address to ping und wählen Sie dort Ping all IPv4 addresses aus. Aktivieren Sie Number of positive responses required for OK state und tragen Sie 1 ein.

  4. Erstellen Sie eine weitere Regel, die ebenfalls nur für den Host internet gilt, diesmal aus dem Regelsatz Host check command. Wählen Sie dort als Host check command die Option Use the status of the service…​ und tragen Sie als Namen Internet connection ein, den Sie im vorherigen Schritt als Service-Namen gewählt haben.

Wenn Sie jetzt die Änderungen aktivieren, erhalten Sie im Monitoring den neuen Host internet mit dem einzigen Service Internet connection.

Wenn mindestens eines der Ping-Ziele erreichbar ist, hat der Host den Status UP und der Service den Status OK. Gleichzeitig erhalten Sie beim Service für jede der eingetragenen IP-Adressen Messdaten für die typische Paketumlaufzeit (round trip time) und den Paketverlust. Damit erhalten Sie einen Anhaltspunkt für die Qualität Ihrer Verbindung im Laufe der Zeit:

service internet

Der letzte Schritt 4 ist notwendig, damit der Host nicht den Zustand DOWN erhält, falls die erste IP-Adresse nicht per ping erreichbar ist. Stattdessen übernimmt der Host den Status seines einzigen Services.

Wichtig: Da ein Service grundsätzlich nicht alarmiert wird, wenn dessen Host DOWN ist, ist es wichtig, dass Sie die Alarmierung über den Host steuern — und nicht über den Service. Außerdem sollten Sie in diesem speziellen Fall einen Alarmierungsweg verwenden, der keine Internetverbindung voraussetzt.

10.4. HTTP/HTTPS-Dienste überwachen

Nehmen wir an, Sie wollen die Erreichbarkeit einer Website oder eines Web-Dienstes prüfen. Der normale Checkmk-Agent bietet hier keine Lösung, da er diese Information nicht anzeigt — und außerdem haben Sie vielleicht gar nicht die Möglichkeit, den Agenten auf dem Server zu installieren.

Die Lösung ist ein sogenannter aktiver Check. Das ist einer, der nicht per Agent durchgeführt wird, sondern direkt durch das Kontaktieren eines Netzwerkprotokolls beim Ziel-Host — in diesem Fall HTTP(S). Das Vorgehen ist wie folgt:

Legen Sie zuerst in Checkmk einen neuen Host für den Webserver an, z.B. für tribe29.com. Aktivieren Sie die Datenquelle Checkmk Agent und setzen Sie sie auf No agent. Speichern Sie den Host ohne Serviceerkennung.

Erstellen Sie anschließend eine neue Regel aus dem Regelsatz Check HTTP service, die nur für den neuen Host greift (z.B. über die Explicit hosts Bedingung).

Im Kasten Check HTTP service finden Sie zahlreiche Parameter zur Durchführung des Checks. Beachten Sie dabei die folgenden Punkte:

  • Geben Sie bei Service name dem Service einen Namen, z.B. Homepage.

  • Bei Host settings > Virtual host müssen Sie eventuell die Domäne des Servers angeben, wenn dieser mehr als eine Domäne hostet.

  • Mode of the Check > Use SSL/HTTPS for the connection ermöglicht die Überwachung von HTTPS.

  • Mit Mode of the Check > Expected response time können Sie den Service auf WARN oder sogar CRIT setzen lassen, wenn die Antwortzeit zu langsam ist.

  • Mit Fixed string to expect in the content können Sie prüfen lassen, ob in der Antwort — also in der gelieferten Seite — ein bestimmter Text vorkommt. Damit können Sie einen relevanten Teil des Inhalts prüfen, damit nicht eine simple Fehlermeldung des Servers als positive Antwort gewertet wird.

Speichern Sie die Regel und aktivieren Sie die Änderungen. Sie bekommen jetzt einen neuen Host mit einem Service, der einen Zugriff per HTTP(S) prüft.

http service

Sie können diesen Check natürlich auch auf einem Host durchführen, der bereits mit Checkmk per Agent überwacht wird. In diesem Fall entfällt das Anlegen des Hosts und Sie müssen nur die Regel für den Host erstellen.

10.5. Dateisystem-Schwellwerte magisch anpassen

Gute Schwellwerte für die Überwachung von Dateisystemen zu finden, kann mühsam sein. Denn eine Schwelle von 90 % ist bei einer sehr großen Festplatte viel zu niedrig und bei einer kleinen vielleicht schon zu knapp. Wir hatten bereits im Kapitel zur Feinjustierung des Monitoring die Möglichkeit vorgestellt, Schwellwerte in Abhängigkeit von der Dateisystemgröße festzulegen — und angedeutet, dass Checkmk eine weitere, noch schlauere Option im Angebot hat: den Magic Factor.

Den Magic Factor richten Sie so ein:

  1. Im Regelsatz Filesystems (used space and growth) legen Sie nur eine einzige Regel an.

  2. In dieser Regel aktivieren Sie Levels for filesystem und lassen den Standard der Schwellwerte 80.0 % bzw. 90.0 % unverändert.

  3. Zusätzlich aktivieren Sie Magic factor (automatic level adaptation for large filesystems) und akzeptieren auch hier den Standardwert von 0.8.

  4. Aktivieren Sie ferner Reference size for magic factor. Übernehmen Sie auch hier den Standardwert von 20 GByte.

Das Ergebnis sieht dann so aus:

magic factor

Wenn Sie jetzt die Regel sichern und die Änderung aktivieren, erhalten Sie Schwellwerte, die automatisch von der Größe des Dateisystems abhängen:

  1. Dateisysteme, die genau 20 GByte groß sind, erhalten die Schwellwerte 80 %/90 %.

  2. Dateisysteme, die kleiner als 20 GByte sind, erhalten niedrigere Schwellwerte.

  3. Dateisysteme, die größer als 20 GByte sind, erhalten höhere Schwellwerte.

Wie hoch die Schwellwerte genau sind ist — nun ja — magisch! Über den Faktor (hier 0.8) bestimmen Sie, wie stark die Werte verbogen werden. Ein Faktor von 1.0 ändert gar nichts, und alle Dateisysteme bekommen die gleichen Werte. Kleinere Werte verbiegen die Schwellwerte stärker. Die in diesem Kapitel angewendeten Standardwerte von Checkmk haben sich in der Praxis bei sehr vielen Installationen bewährt.

Welche Schwellen genau gelten, können Sie bei jedem Service in seiner Zusammenfassung (Summary) sehen:

magic factor services

Die folgende Tabelle zeigt einige Beispiele für die Auswirkung des Magic Factors (mf) bei einer Referenz von 20 GByte / 80 %:

Dateisystemgrößemf = 1.0mf = 0.9mf = 0.8mf = 0.7mf = 0.6mf = 0.5

5 GByte

80 %

77 %

74 %

70 %

65 %

60 %

10 GByte

80 %

79 %

77 %

75 %

74 %

72 %

20 GByte

80 %

80 %

80 %

80 %

80 %

80 %

50 GByte

80 %

79 %

77 %

75 %

74 %

72 %

100 GByte

80 %

83 %

86 %

88 %

89 %

91 %

300 GByte

80 %

85 %

88 %

91 %

93 %

95 %

800 GByte

80 %

86 %

90 %

93 %

95 %

97 %

Mit dem Magic Factor schließen wir den Leitfaden für Einsteiger ab. Wir hoffen, dass Sie es geschafft haben, Ihr Checkmk grundlegend einzurichten — mit oder ohne Magie. Für fast alle Themen, die wir in diesem Leitfaden behandelt haben, finden Sie im Referenzteil für Experten vertiefende Informationen. Wir wünschen viel Erfolg mit Checkmk!

Auf dieser Seite