Wir nutzen Cookies, um Ihnen eine optimale Nutzung dieser Webseite zu ermöglichen. Mehr Informationen finden Sie im Datenschutzhinweis. Wir nehmen an, dass Sie damit einverstanden sind, falls Sie diese Webseite weiter besuchen.

Ihre Cookie-Einstellungen
Ihre Einstellungen wurden aktualisiert.
Damit die Änderungen wirksam werden, löschen Sie bitte Ihre Browser-Cookies und den Cache und laden dann die Seite neu.

Leitfaden für Einsteiger

Checkmk Manual

Auf dieser Seite

Suche im Handbuch

Dieser Artikel ist noch nicht fertig und nur ein Entwurf!

Liebe Anwender*innen von Checkmk,

der reibungslose Betrieb von IT-Systemen war schon immer eine Herausforderung. Aber sowohl die Komplexität der Hardware- und Softwarestacks als auch die Ansprüche der Anwender nehmen immer weiter zu – und zwar egal, ob Sie mit echter Hardware oder mit Cloudlösungen arbeiten. Und so kommt einem detaillierten und umfassenden IT-Monitoring heute eine zentrale Rolle zu.

Und 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 das in der Praxis beutet. Daher ist der Umfang von Checkmk für einen Einsteiger erstmal überwältigend.

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

  1. einen Leitfaden für Einsteiger – diesen Artikel
  2. einen umfassenden Referenzteil

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 Abschnitt zeigen wir Ihnen dann noch ein paar sehr nützliche Tipps und Tricks unserer erfahrenen Consultants, die sich in jeder Checkmk-Installation bewährt haben.

Natürlich lässt unser Einsteigerhandbuch noch viele Fragen offen. Diese finden Sie im ausführlichen Referenzteil des Handbuchs beantwortet. Dort finden Sie zu jedem Thema alle Hintergründe und Details, um tiefer einzusteigen.

1. Checkmk aufsetzen

1.1. Auswahl der Edition

Bevor Sie daran gehen, Checkmk zu installieren, müssen Sie sich erstmal mit der Frage befassen, welches Checkmk Sie denn möchten. Es gibt drei verschiedene Editionen:

Die  Checkmk Raw Edition ist kostenlos und 100 % Open Source und enthält Nagios als Kern. Sie können damit komplexe Umgebungen umfassend überwachen. Support erhalten Sie durch die Community auf unseren Mailinglisten und in Zukunft auch in einem Community-Portal.

Die  Checkmk Enterprise Edition richtet sich vor allem an professionelle Anwender und bietet über den Umfang der Raw Edition hinaus eine Reihe von interessanten Features, wie z. B. einen sehr performanten eigenen Kern, der Nagios ersetzt, ein Reporting, ein ausgefeiltes System für die Visualisierung von Messwerten, ein flexibles Agent-Deployment und vieles mehr. Für die Enterprise Edition erhalten Sie von uns und unseren Partnern professionellen Support. Eine Aufstellung der wichtigsten Unterschiede zur Raw Edition finden Sie auf unserer Homepage.

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

Die  Checkmk Managed Services Edition ist für Sie die richtige Edition, wenn Sie Dienste wie ein Managed-Service-Provider anbieten. Sie ist eine mandantenfähige Erweiterung der Enterprise Edition.

1.2. Auswahl der Version

Natürlich entwickeln wir alle Editionen von Checkmk ständig weiter, und so gibt es von jeder Edition verschiedene Versionen. Für den Einstieg empfehlen wir Ihnen grundsätzlich die jeweils neueste stabile Version von Checkmk. Einen detaillierten Überblick, welche Arten von anderen Versionen es noch gibt, erfahren Sie in einem eigenen 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 Betriebssyteme problemlos ü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:

Möglichkeit 1: Installation auf einem Linux-Server

Die Installation von Checkmk auf einem Linux-Server, egal, ob auf einer „echten“ oder auf einer virtuellen Maschine, ist sozusagen die „normale“ Methode. Wenn sie Linux-Grundkenntnisse, ist diese Methode sehr einfach, und alle Software, die Sie benötigen, ist entweder in Ihrer Distribution oder in unserem Paket enthalten.

Wir unterstützen die Distributionen von Red Hat, CentOS, SLES, Debian und Ubuntu. Für jede Edition und Version von Checkmk gibt es für jede dieser Distributionen ein eigenes angepasstes Paket von uns. Dies finden Sie auf unserer Downloadseite. Sie installieren es direkt mit dem Paketmanager Ihrer Distribution. Bitte folgen Sie der Anleitung im Artikel Installation auf Linux-Systemen.

Möglichkeit 2: Die Virtuelle Appliance virt1

Mit der virtuellen Appliance Checkmk virt1 erhalten Sie eine komplett eingerichtet virtuelle Maschine, die Sie in VMware, HyperV oder VirtualBox verwenden können. Neben Checkmk enthält sie auch ein komplettes Betriebssystem auf Basis von Debian GNU/Linux. Der Vorteil der Appliance ist der, dass Sie hier auch das Betriebssystem komplett über die grafische Oberfläche konfigurieren können. So ist eine Verwaltung von Checkmk auch ohne fundierte Linux-Kenntnisse möglich. Auch sind das Update von Checkmk und viele andere Operationen komplett ohne Kommandozeile möglich.

Die virtuelle Appliance ist nur im Rahmen einer Subskription erhältlich. Wenn Sie dort die Option virtuelle Appliance gebucht haben, gehen Sie bitte vor, wie in der passenden Installationsanleitung beschreiben. Die virtuelle Appliance für die Free Edition ist kostenlos erhältlich.

Möglichkeit 3: Die Hardware-Appliances rack1 und rack4

Falls Sie eine physische Hardware-Appliance bevorzugen, können Sie bei uns zwischen mehreren Modellen mit verschiedenen Supportleveln wählen. Auf diesen ist Checkmk fertig eingerichtet und sofort nutzbar. Mit der Hardware-Appliance erhalten Sie ein komplettes System, das Sie direkt in Ihrem Rechenzentrum einbauen können. Zwei Hardware-Appliances können Sie mit wenigen Handgriffen zu einem hochverfügbaren HA-Cluster zusammenschalten. Die Anleitung zur Inbetriebnahme der Appliances finden Sie in einem eigenen Artikel.

Möglichkeit 4: Checkmk im Docker-Container

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

Eine genaue Anleitung zum Deployen von Checkmk finden Sie in einem eigenen Artikel.

1.4. Erstellen einer Instanz

Checkmk hat eine Besonderheit, die Ihnen zu Beginn vielleicht überflüssig 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 schöne Feature:

  • unkompliziertes Ausprobieren einer neuen Checkmk-Version
  • Parallelbetrieb einer Testinstanz zum Überwachen von Hosts, die noch nicht operativ sind

Wenn Sie Checkmk gerade installiert haben, kommt es noch komplett ohne Instanzen daher. Wir zeigen Ihnen hier, wie Sie bei einer normalen Installation von Checkmk eine Instanz anlegen.

Falls Sie Checkmk auf Linux oder via Docker betreiben, wird für Sie automatisch eine Instanz angelegt. Die Checkmk-Appliances werden über eine Weboberfläche administriert, die auch das Anlegen von Instanzen abdeckt. Dies wird im Artikel über die Appliance erklärt.

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 Bespielen den Namen mysite. Setzen Sie dort immer Ihren eigenen Instanznamen ein, wenn Sie darauf stoßen.

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
Restarting Apache...OK
Created new site mysite with version 1.6.0.cee.

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

  The admin user for the web applications is cmkadmin with password: ZBdHdkl2
  (It can be changed with 'htpasswd -m ~/etc/htpasswd cmkadmin' as site user.)
  Please do a su - mysite for administration of this site.

Beim Anlegen einer neuen Instanz passieren die folgenden Dinge:

  • Es wird ein Linux-Benutzer und eine Linux-Gruppe im System angelegt, die den Namen der Instanz tragen. Der Benutzer heißt Instanzbenutzer (Site user).
  • Für die Instanz wird ein Datenverzeichnis unterhalb von /omd/sites angelegt, z. B. /omd/sites/mysite.
  • Eine sinnvolle Defaultkonfiguration wird in das neue Verzeichnis kopiert.
  • Für die Weboberfläche von Checkmk wird ein Benutzer mit dem Namen cmkadmin und einem zufälligen Passwort angelegt.

Hinweis: Wenn Sie den Fehler Group 'foobar' already existing. erhalten, dann existiert bereits ein Linux-Benutzer mit dem gewünschten 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 Befehl su - mysite:

root@linux# su - 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 Datenverzeichnis der Instanz (Instanzverzeichnis):

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 Anmweldung an der Weboberfläche (GUI) vom Checkmk gedacht und hat ein zufälliges Passwort bekommen. 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 Instanzverzeichnis. Wenn Sie sich in ihm 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/passwd ist und welche die Passwörter der Checkmk-Benutzer enthält. Verwechseln Sie diese bitte nicht mit /etc/htpasswd!

1.5. Starten und Stoppen von Instanzen

Eine Instanz kann gestartet oder gestoppt sein. Die „Startart“ ist dabei automatisch, was bedeutet, dass alle Instanzen nach einem Reboot vom System automatisch starten. 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, welche 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

Da die Raw Edition nicht über alle Features der Enterprise Edition verfügt, sehen Sie dort einige Dienste weniger. Außerdem ist cmc durch nagios ersetzt:

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

Der Befehl omd hat noch viele weitere Möglichkeiten zur Steuerung und Konfiguration von Instanzen. Alle Details erfahren Sie im zugehörigen Artikel über Instanzen.

Auch für weitere Details zur Verzeichnisstruktur der Instanz und zu den Möglichkeiten von Checkmk auf der Kommandozeile gibt es einen eigenen Artikel.

1.6. An der Instanz 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 aus der IP-Adresse oder dem Hostnamen Ihres Monitoring-Servers, einem Schrägstrich und dem Namen der Instanz zusammen, z. B. http://mycmkserver/mysite/. Dort finden Sie das folgende Anmeldefenster:

Falls Ihre Instanz nicht gestartet ist, sehen Sie dort stattdessen folgende Fehlermeldung:

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

Melden Sie sich nun mit dem Benutzer cmkadmin und dem anfangs ausgewürfelten bzw. von Ihnen geänderten Passwort an. Dadurch landen Sie auf der Startseite von Checkmk:

Wichtig: Sobald Sie Checkmk produktiv betreiben, empfehlen wir Ihnen aus Sicherheitsgründen den ausschließlichen Zugriff auf die Oberfläche über HTTPS. Wie das geht, erfahren Sie in einem eigenen Artikel.

1.7. Erster Überblick über die Oberfläche

In der Oberfläche sehen Sie natürlich eine ganze Menge von Elementen, die wir zu diesem Zeitpunkt noch nicht benötigen. Viele davon sind sowieso leer oder zeigen lauter Nullen, weil wir noch keine Objekte ins Monitoring aufgenommen habe.

Trotzdem sollten Sie sich zunächst mit den Grundelementen der Oberfläche vertraut machen. Am wichtigsten ist die Aufteilung in die Seitenleiste (Englisch: Sidebar) auf der linken Seite und den Hauptbereich auf der rechten. Was Sie im Hauptbereich sehen, hängt natürlich davon ab, wo Sie in Checkmk gerade unterwegs sind. Nach der Anmeldung starten Sie zunächst im Default-Dashboard, das einen groben Überblick über den aktuellen Zustand und die kürzlichen Ereignisse der überwachten Objekte zeigt.

Die Seitenleiste

Wichtiger ist erstmal die Seitenleite. Hier finden Sie eine Reihe von Elementen, die auch als Snapins bezeichnet werden. Je nach Größe Ihres Bildschirms werden nicht alle Snapins sichtbar sein. Aber wie verschiebt man nun die Sidebar ohne Rollbalken? Hier haben Sie zwei Möglichkeiten:

  1. Rollen Sie einfach mit dem Mausrad auf und ab, 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.
  2. „Packen“ Sie einfach eines der Snapins mit der Maus außerhalb seiner Titelzeile und schieben es auf- oder abwärts.

In der Standardeinstellung (natürlich ist die Seitenleiste anpassbar!) finden Sie folgende Elemente:

  • Tactical Overview – Übersicht über alle überwachten Objekte
  • Quicksearch – Suchfeld
  • Views – Verzeichnis verschiedener Statusansichten
  • Reporting – Erstellen von PDF-Reports
  • Bookmarks – Ihre persönlichen Lesezeichen innerhalb von Checkmk
  • WATO - Configuration – Das wichtigste: Die Konfiguration des Monitorings
  • Master Control – verschiedene Hauptschalter für das Monitoring

Über der Seitenleiste finden Sie neben der Angabe von Edition und Version auch das Checkmk-Logo. Ein klick auf das Logo bringt Sie immer zur Startseite von Checkmk.

Und unter der Seitenleiste finden Sie das Symbol , das Sie zu Ihren persönlichen Einstellungen bringt. Dort können Sie Ihr Passwort ändern. Und meldet Sie von der Oberfläche ab.

2. Das Monitoring einrichten

2.1. Hosts und Services, Agenten

So, Checkmk steht bereit. Doch bevor wir mit dem eigentlichen Monitoring beginnen, sollten wir noch kurz einige wichtige Betriffe erläutern. Das beginnt mit dem Host. Ein Host ist in Checkmk in der Regel ein Server, eine VM, ein Netzwerkgerät, eine Appliance oder generell irgendetwas mit einer IP-Adresse, was von Checkmk überwacht wird. Jeder Host hat immer einen der Zustände UP, DOWN oder UNREACH. Es gibt auch Hosts ohne IP-Adresse, z. B. Docker-Container.

Auf jedem Host werden eine Anzahl von Services überwacht. Ein Service kann dabei alles Mögliche sein, z. B. ein Dateisystem, ein Prozess, ein Hardwaresensor, ein Switchport, aber auch einfach nur eine 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 ist und auf Anfrage Daten über die Gesundheit des Hosts liefert. Bei Netzwerkgeräten und vielen Appliances hat meist der Hersteller bereits einen Agenten eingebaut, den Checkmk ohne Weiteres mit dem standardisierten Protokoll SNMP abgefragen kann. Cloud-Dienste wie AWS oder Azure haben ebenfalls so etwas wie Agenten – allerdings werden sie dort „API“ genannt und von Checkmk per HTTP abgefragt. 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.

2.2. Vorüberlegungen zu DNS

Auch wenn Checkmk keine Namensauflösung von Hosts voraussetzt, ist ein gut gepflegtes DNS doch eine umgemeine Erleichterung bei der Konfiguration und vermeidet Fehler. Denn Checkmk kann dann die Namen der Hosts selbständig auflösen, so dass Sie keine IP-Adressen in Checkmk fest eintragen müssen.

Der Aufbau des Monitorings ist also ein guter Anlass, Ihr DNS bei der Gelegenheit auch mal wieder auf den neuesten Stand zu bringen und dort fehlende Einträge zu ergänzen!

2.3. Ordnerstruktur für Hosts

Checkmk verwaltet Ihre Hosts in einem hierarchischen Baum von Ordnern – ganz analog, wie Sie das von Dateien in Ihrem Betriebssystem kennen. Wenn Sie nur eine Handvoll Hosts überwachen, mag das für Sie vielleicht nicht so wichtig sein. Aber erinnern Sie sich: Checkmk ist für das Überwachen von Tausenden und Zigtausenden Hosts geschaffen. Und hier ist Ordnung die halbe Miete!

Bevor Sie die ersten Hosts in Checkmk aufnehmen, ist es daher gut, wenn Sie sich Gedanken über die Strukturierung dieser Ordner machen. Denn diese ist nicht nur für Ihre eigene Übersicht nützlich. Es ist auch grundsätzlich so, dass Sie alle Konfigurationsattribute von Hosts auch in einem Ordner definieren können. Diese werden dann automatisch an dort enthaltene Unterordner und Hosts vererbt.

Natürlich können Sie die Ordnerstruktur jederzeit verändern. Dann müssen Sie allerdings sehr gewissenhaft vorgehen. Denn das Verschieben eines Hosts in einen anderen Ordner kann zur Folge haben, dass sich dessen Attribute ä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 einteilen möchten. Dies kann in jeder Ebene des Baums ein anderes sein. So können Sie z. B. in der ersten Ebene nach Standorten unterscheiden und in der zweiten Ebene darunter 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 Frage der Organisation – also „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 egal, 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 wiederum einfach zu konfigurieren, dass alle Hosts unterhalb vom diesem Ordner 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. Dies wiederum vereinfacht eine Konfiguration nach dem Schema „auf allen Linux-Servern muss der Prozess sshd laufen“. Ein anderes Beispiel dafür ist die Überwachung von Geräten via SNMP, wie z. B. Switches oder Router. Hier kommt kein 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 z. B. die Community vornehmen.

Da eine Baumstruktur natürlich nicht die ganze Komplexität der Wirklichkeit abbilden kann, bietet Checkmk mit den Host-Merkmalen (Tags) eine weitere Strukturmöglichkeit, welche die Bäume intelligent ergänzt. Doch dazu später mehr. Weiterführende Informationen zur Strukturierung der Ordner finden Sie im Referenzteil.

2.4. Anlegen von Ordnern

Die Verwaltung von Ordnern und Hosts finden Sie im Modul WATO ➳ Hosts, das Sie über das Seitenleistenelement WATO - Configuration erreichen:

Einen Ordner – den Wurzelordner – gibt es auch in einem frisch aufgesetzten Checkmk-System. Dieser hat den Namen Main Directory, aber wenn Ihnen das nicht gefällt, können ihn mit dem Knopf Folder properties leicht umbenennen. Sie können neue Hosts direkt hier anlegen. Aber besser ist es, wenn Sie zunächst einige passende Unterordner anlegen.

Für unser Einsteigerhandbuch verwenden wir ein einfaches Beispiel, und zwar die drei Ordner Windows, Linux und Network. Legen Sie diese drei Ordner an, indem Sie jeweils auf den Knopf New folder klicken und im ersten Kasten mit dem Namen General properties den jeweiligen Namen eintragen:

Tipp: Wenn Sie zu faul sind, zum Knopf Save & Finish zu scrollen, drücken Sie einfach Eingabe, während der Cursor noch im Texteingabefeld steht. Das bewirkt ebenfalls ein Speichern und Verlassen der Maske.

Danach sieht die Situation so aus:

Tipp: In vielen Fenstern (wie auch hier beim Anlegen eines neuen Ordners) sehen Sie oben rechts in der Ecke ein kleines Symbol eines Buches . Mit diesem können Sie eine Onlinehilfe ein- und ausschalten. Die Hilfe erklärt die einzelnen Eingebefelder.

2.5. Aufnehmen der ersten Hosts

Jetzt ist alles dafür bereit, 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- oder Windows-Hosts ist immer gleich:

  1. Checkmk-Agenten herunterladen
  2. Checkmk-Agenten auf dem Zielhost installieren
  3. Host mit WATO in einen passenden Ordner aufnehmen
  4. Service-Konfiguration durchführen
  5. Änderungen aktivieren

Checkmk-Agent herunterladen

Da der Checkmk-Server ein Linux-Rechner ist, benötigen Sie den Checkmk-Agenten für Linux. Diesen finden Sie direkt in der Oberfläche unter WATO ➳ Monitoring Agents.

In der Enterprise Edition gelangen Sie hier zur Agent Bakery. Diese ermöglicht das „Backen“ von individuell konfigurierten Agentenpaketen. Aber es wird auch immer ein generischer Agent bereitgestellt, ohne dass Sie dafür irgendetwas tun müssten:

Wählen Sie für Red Hat, CentOS oder SLES das RPM-Format und für Debian und Ubuntu das DEB-Format. Laden Sie die Datei herunter und kopieren Sie sie auf den Checkmk-Server.

Die Raw Edition verfügt über keine Agentenbäckerei. Hier gelanden Sie nach einem Klick auf WATO ➳ Monitoring Agents direkt auf eine Downloadseite, auf der Sie vorkonfigurierte Agenten und Agenten-Plug-ins finden. (Diese Seite finden Sie in der Enterprise Edition unter Agent files.)

Wählen Sie aus dem ersten Kasten Packaged Agents eines der beiden Linux-Pakete (RPM/DEB) und kopieren Sie es auf den Checkmk-Server.

Checkmk-Agent auf dem Zielhost 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 später wieder löschen.

Die Installation erfolgt als root auf der Kommandozeile entweder mit rpm, am besten mit der Option -U...

root@linux# rpm -U check-mk-agent-1.6.0-3a83e51d5c12619c.noarch.rpm

... oder für DEB entsprechend mit dem Befehl dpkg -i:

root@linux# dpkg -i check-mk-agent_1.6.0-3a83e51d5c12619c_all.deb

Wichtig: Der Agent benötigt zum Funktionieren entweder systemd, der bei neueren Distributionen Standard ist, oder den Hilfsdaemon xinetd. Was bei Ihnen der Fall ist, können das leicht an der Ausgabe beim Installieren des Agenten sehen:

Agent läuft... Ausgabe
mit xinetd Reloading xinetd...
mit systemd Enable Check_MK_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 lautet der Befehl:

root@linux# zypper install xinetd

Und bei Debian/Ubuntu:

root@linux# apt install xinetd

Checkmk-Agent ausprobieren

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

RPM:check_mk_agent
<<<check_mk>>>
Version: 1.6.0
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
...

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

root@linux# telnet mycmkserver 6556
Trying 192.168.56.100...
Connected to mycmkserver.example.net.
Escape character is '^]'.
<<<check_mk>>>
Version: 1.6.0
AgentOS: linux
Hostname: linux
...

Hinweis: Der Agent ist standardmäßig aus dem ganzen Netz erreichbar und ohne Passwort abfragbar. Da der Agent 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 mit WATO in einen passenden Ordner aufnehmen

Nachdem der Agent auf dem Zielhost installiert ist, können Sie diesen ins Monitoring aufnehmen. In unserem Beispiel war das ja der Checkmk-Server selbst, aber das macht eigentlich keinen Unterschied.

Gehen Sie also wieder in das Modul WATO ➳ Hosts und wechseln dort in den Ordner Linux, indem Sie einfach die Grafik des Ordners anklicken. Klicken Sie dort auf den Knopf New host.

Dort finden Sie eine Maske mit mehreren Kästen und vielen Eingabemöglichkeiten. Wie am Anfang erwähnt, ist Checkmk ein komplexes System, das auf jede Frage eine Antwort hat. Deswegen kann man bei einem Host auch sehr viel konfigurieren.

Die gute Nachricht ist: Sie müssen nur ein einziges Feld ausfüllen, nämlich das Feld Host name bei den Basic Settings. Diesen Namen können Sie frei vergeben. Er dient im Monitoring an allen Stellen als Schlüssel und eindeutige Bezeichnung für den Host:

Falls der Host unter seinem Namen im DNS auflösbar ist, sind Sie mit dieser Maske bereits fertig. Falls nicht, oder falls Sie kein DNS verwenden möchten, können Sie die 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 Hostnamen. 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.

Dieser Cache wird automatisch jeden Tag um 00:05 Uhr erneuert. Mit dem Knopf Update DNS cache in dem Fenster der Host-Eigenschaften eines Ihrer Hosts können Sie den gesamten DNS-Cache manuell neu aufbauen. Machen Sie dies, wenn Sie möchten, dass eine Änderung in Ihrem DNS sofort wirksam wird.

Detaillierte Informationen zur Namensauflösung beim Monitoring finden Sie im Artikel über die Host-Verwaltung.

2.6. Diagnose

Alles was schiefgehen kann, geht irgendwann einmal schief – und natürlich vor allem, wenn man Dinge zum ersten Mal macht! Deswegen sind gute Fehlerdiagnose-Möglichkeiten wichtig. Eine davon finden Sie in WATO, wenn Sie die Eigenschaften des Hosts mit Save & Test verlassen. Alternativ können Sie auch jederzeit in den Eigenschaften des Hosts mit dem Knopf Diagnostic zur gleichen Diagnoseseite kommen – in dem Fall allerdings ohne vorher zu speichern.

Scrollen Sie auf der Diagnoseseite etwas nach unten und drücken Sie dort Test. Nun wird Checkmk versuchen, den Host auf allen verschiedenen Wegen zu erreichen. Für Windows- und Linux-Hosts sind dabei nur die beiden oberen Kästen interessant:

Weitere Kästen versuchen, per SNMP Kontakt aufzunehmen, und sind für Netzwerkgeräte sehr nützlich, die wir weiter unten besprechen werden.

In der Diagnoseseite können Sie im Kasten Host properties bei Bedarf eine andere IP-Adresse ausprobieren und diese mit Save & Exit sogar direkt in die Host-Eigenschaften übernehmen.

2.7. Konfiguration der Services

Nachdem der Host selbst aufgenommen wurde, kommt das eigentlich Interessante: die Konfiguration der Services. Zu dieser gelangen Sie auf verschiedenen Wegen:

  • wenn Sie in den Host-Eigenschaften mit Save & go to Services speichern
  • wenn Sie in der Ordneransicht bei einem Host auf das Symbol klicken
  • wenn Sie in den Host-Eigenschaften oder einer anderen Seite des Hosts oben auf den Knopf Services klicken.

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

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

  • Undecided: Sie haben sich noch nicht entschieden, ob Sie diesen Service überwachen möchten.
  • Monitored: Der Service wird überwacht.
  • Disabled: Sie haben sich dafür entschieden, den Service grundsätzlich nicht zu überwachen.

Am Anfang beginnen alle Services als undecided. Für den Anfang ist es am einfachsten, wenn Sie jetzt auf Fix all missing/vanished klicken. Dann werden alle Services direkt in das Monitoring übernommen.

Sie können diese Ansicht jederzeit später aufrufen, um die Konfiguration der Services anzupassen. Manchmal entstehen durch Änderungen an einem Host neue Services, z. B. wenn Sie eine LUN als Dateisystem einbinden oder eine neue Instanz von Oracle konfigurieren. Diese Services erscheinen dann als undecided, und Sie können Sie einzeln oder alle auf einmal in das Monitoring aufnehmen.

Umgekehrt können Services verschwinden, z. B. weil ein Dateisystem entfernt wurde. Diese erscheinen dann im Monitoring als UNKNOWN und in der Konfigurationsseite als vanished. Diese können Sie hier aus dem Monitoring entfernen.

Der Knopf Fix all missing/vanished macht alles auf einmal: fehlende Services hinzufügen und überflüssige entfernen.

2.8. Änderungen aktivieren

WATO ist grundsätzlich so aufgebaut, dass alle Änderungen, die Sie machen, zunächst nur in einer vorläufigen „Konfigurationsumgebung“ stattfinden. Das aktuell laufende Operating wird noch nicht beeinflusst. Erst durch ein Aktivieren der Änderungen (Activate changes) werden diese in das operative Monitoring übernommen. Mehr über die Hintergründe dazu erfahren Sie im Artikel über WATO.

Klicken Sie jetzt auf den Knopf , um die Änderungen anzuwenden. Dies bringt Sie auf eine neue Seite, die unter anderem bei Pending changes die noch nicht aktivierten Änderungen auflistet:

Klicken Sie nun auf den Knopf Activate affected, um alle Änderungen zu übernehmen. Kurz danach sehen Sie in der Seitenleiste im Tactical Overview, wie dort der Host und seine Services erscheinen. Auch im Haupt-Dashboard, das Sie mit einem Klick auf das Checkmk-Logo ganz links oben erreichen, können Sie jetzt sehen, dass sich das System mit Leben gefüllt hat.

2.9. Überwachen von Windows

Ebenso wie für Linux hat auch 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. Sobald Sie das MSI-Paket 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. Das geschieht genauso wie beim Linux-Host von oben. Da Windows anders aufgebaut ist als Linux, findet der Agent allerdings andere Services. Weitere Details zur Überwachung von Windows finden Sie in einem eigenen Artikel.

2.10. Überwachen via SNMP

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 mal einen Agenten installieren.

Das grundsätzliche Vorgehen ist dabei immer gleich:

  1. Mittels der Management-Oberfläche des Gerätes schalten Sie SNMP für lesende Zugriffe für die IP-Adresse des Checkmk-Servers frei.
  2. Dabei vergeben Sie 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 dieselbe Community. Das vereinfacht auch die Konfiguration in Checkmk sehr.
  3. Legen Sie den Host wie gewohnt in Checkmk an.
  4. In den Eigenschaften des Hosts im Kasten Data sources setzen Sie Check_MK Agent auf No agent.
  5. Im gleichen Kasten aktivieren Sie den Punkt SNMP und wählen SNMP v2 or v3.
  6. Falls die Community nicht public lautet, aktivieren Sie SNMP credentials ➳ SNMP community (SNMP Versions 1 and 2c) und tragen Sie die Community hier ein.

Wenn Sie alle SNMP-Geräte in einem eigenen Ordner haben, führen Sie die Konfiguration der Data sources einfach direkt auf dem Ordner aus. Damit gelten die Einstellungen automatisch für alle Hosts in dem Ordner!

Der Rest läuft wie gehabt. Wenn Sie möchten, können Sie noch einen Blick auf die Diagnoseseite werden. Dort sehen Sie auch sofort, ob der Zugriff via SNMP funktioniert, hier z. B. für einen Switch vom Typ CISCO Catalyst 4500:

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

2.11. Cloud, Container und VMs

Auch Cloud- und Container-Dienste können Sie mit Checkmk problemlos überwachen, selbst wenn Sie keinen Zugriff auf die eigentlichen Server haben. Checkmk nutzt dafür die von den Herstellern vorgesehenen APIs. Diese verwenden durchgehend HTTP bzw. HTTPS. Das Grundprinzip ist immer das gleiche:

  1. Sie richten in der Management-Oberfläche des Herstellers einen Account für Checkmk ein.
  2. In Checkmk legen Sie für den Zugriff auf die API einen Host an.
  3. Für diesen Host erstellen Sie eine Konfiguration zum Zugriff auf die API.
  4. Für die überwachten Objekte wie VMs, EC2-Instanzen, Container usw. legen Sie weitere Hosts in Checkmk an bzw. automatisieren das.

Für all das gibt es im Handbuch Schritt-für-Schritt-Anleitungen:

3. Die Benutzeroberfläche

3.1. Die Statusoberfläche

Jetzt, da wir unserem Monitoring-System endlich etwas zu tun gegeben haben, ist es sinnvoll, dass wir uns näher mit der Oberfläche befassen. Uns interessieren hier vor allem die Dinge, die mit dem Operating zu tun haben, also mit dem täglichen Leben der Überwachung. 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.

3.2. Tactical Overview

Werfen wir zunächst einen näheren Blick auf die Tactical Overview:

In der linken 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. Messages aus Syslog, SNMP-Traps und Logdateien gemeint. Dafür hat Checkmk ein eigenes sehr mächtiges Modul: die Event Console, die im Einsteigerhandbuch nicht besprochen wird.

Die zweite Spalte zeigt die Probleme. Das sind die Objekte, die gerade den Status WARN/CRIT/UNKNOWN, bzw. DOWN/UNREACH haben. Sie können auf die Zahl in der Zelle klicken und kommen dann direkt zu den Objekten, die hier gezählt wurden.

Die dritte Spalte kann nie größer werden als die zweite. Denn sie zeigt diejenigen Probleme, die noch nicht quittiert wurden. Eine Quittierung (Acknowledgment) ist eine Art „zur Kenntnisnahme“ von Problemen, die wir weiter unten besprechen werden.

Die letzte Spalte zeigt Objekte, die gerade stale (veraltet) sind. Das sind Hosts oder Services, über die zur Zeit keine aktuellen Monitoringdaten vorliegen. Wenn z. B. ein Host aktuell gar nicht erreichbar ist, kann Checkmk natürlich auch keine Neuigkeiten über dessen Services ermitteln. Das bedeutet dann 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 fehlt, wenn sie überall 0 zeigen würde.

3.3. Lesezeichen (Bookmarks)

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

Aber wozu braucht man das? Immerhin gibt's ja auch Lesezeichen im Browser! Nun, die Checkmk-Lesezeichen haben ein paar Vorteile:

  • Sie ändern nur den Inhalt auf der rechten Seite, ohne die Sidebar neu zu laden.
  • Sie können Lesezeichen mit anderen Benutzern teilen.
  • Beim Setzen von Lesezeichen wird automatisch das Wiederausführen von Aktionen verhindert.

Die Lesezeichen sind in Listen organisiert. So eine Liste ist eine Sammlung von Lesezeichen, die Sie als Ganzes verwalten können. So können Sie pro Liste entscheiden, ob diese anderen Benutzern bereitgestellt wird oder für Sie privat bleibt.

Daneben hat jedes Lesezeichen ein Topic. Dies ist der Ordner, unter dem es sich in der Seitenleiste einordnet.

Wichtig: Eine Liste kann Lesezeichen in unteschiedliche Topics einsortieren! Oder umgekehrt kann ein Topic auch Lesezeichen oder unterschiedliche Listen beinhalten.

Am Anfang ist das Snapin für die Bookmarks noch leer:

Wenn Sie nun auf Add Bookmark klicken, wird von dem, was gerade im Hauptbereich angezeigt wird, ein neues Lesezeichen erzeugt und automatisch im Ordner (Topic) My bookmarks abgelegt.

Wenn Sie tiefer in das Thema der Lesezeichen einsteigen wollen, können Sie mehr Details im Referenzartikel zur GUI nachlesen.

3.4. Quicksearch

Das Element Quicksearch sucht für Sie Hosts und Services in der Statusoberfläche (nicht in WATO!). Es ist sehr interaktiv. Sobald Sie etwas getippt haben, sehen Sie sofort Vorschläge für eine Vervollständigung. Hier dazu ein paar Tipps:

  • Groß-/Kleinschreibung ist bei der Suche nicht relevant.
  • Sie müssen keinen Eintrag aus der Vorschlagsliste auswählen. Drücken Sie einfach Eingabe, so finden Sie eine Ansicht mit allen Hosts bzw. Services, auf die der Suchausdruck passt.
  • Das Ergebnis der Suche können Sie in einem Lesezeichen speichern.
  • Wenn Sie nach Host- und Servicemuster 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 allen Hosts, die win enthalten.

3.5. Master Control

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

Bitte achten Sie darauf, dass im Normalbetrieb alle Schalter auf on stehen. Sonst können wichtige Funktionen des Monitorings abgeschaltet sein!

3.6. Anpassen der Seitenleiste

Jedes der Elemente können Sie aus der Seitenleiste entfernen und zusammenklappen. Dazu haben Sie oben rechts in der Ecke jedes Elements zwei Symbole. Ein Klick auf das Kreuz entfernt das Element. Ein Klick auf den kleinen Strich klappt das Element zusammen. Ist ein Element zusammengeklappt, ändert sich der kleine Strich in ein Quadrat. Klicken Sie auf das Quadrat, wird das Element wieder aufgeklappt.

Am unteren Rand der Seitenleiste finden Sie ganz links das Symbol . Mit diesem können Sie die Seitenleiste um weitere Snapins erweitern. Ein Klick auf das Symbol zeigt Ihnen alle verfügbaren Elemente, die Sie dann mit einem einfach Klick hinzufügen können. Beachten Sie, dass diese am Ende erscheinen und Sie eventuell die Leiste nach unten scrollen müssen, damit Sie sie sehen.

Die Reihenfolge der Snapins in der Sidebar können Sie ganz einfach mit der Maus verändern. Klicken Sie mit der linken Maustaste an den oberen Rand des Snapins, halten Sie die Maustaste gedrückt und verschieben Sie das Snapin an die gewünschte Position.

Wenn Sie einmal die Seitenleiste ausblenden wollen, um die Ansicht der anderen Fenster zu vergrößern, brauchen Sie lediglich mit der Maus ganz links an den Rand der Seitenleiste zu klicken und schon wird die Seitenleiste zugeklappt. Sie sehen dann nur noch eine schwarze senkrechte Linie. Wenn Sie später auf diese klicken, können Sie damit die Sidebar wieder aufklappen.

3.7. Statusansichten (Views)

Das Views-Snapin

Das wichtigste Snapin für das Operating ist neben dem Tactical Overview jenes mit dem Titel Views. Eine View ist eine Statusansicht, die Ihnen den aktuellen Zustand von Hosts oder Services (oder teilweise auch anderen Objekten) anzeigt.

So eine Ansicht 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.

Alle diese globalen Ansichten sind über das Views-Snapin erreichbar. Die Ansichten sind dort zu Topics (Ordnern) zusammengefasst, die einzel auf- und zuklappbar sind:

Navigation in den Views

In den Statusansichten haben Sie zahlreiche Bedienmöglichkeiten:

  • Sie können zu anderen Ansichten navigieren, indem Sie bestimmte Zellen anklicken (hier im Bespiel den Hostnamen oder die Anzahl seiner Services im Zustand WARN).
  • Durch einen Klick auf einen Spaltentitel können Sie nach dieser Spalte sortieren.
  • Durch einen Klick auf sehen Sie eine ganze Reihe weiterer Knöpfe, die Sie zu verwandten Ansichten bringen.
  • Der Knopf öffnet eine Reihe von Suchfeldern, über die Sie die gezeigten Objekte filtern können.
  • Mit können Sie die Anzahl der angezeigten Spalten ändern (um Ihren breiten Bildschirm voll auszunutzen). Dies können Sie auch mit dem Mausrad umstellen, wenn sich der Zeiger über diesem Knopf befindet.
  • Mit 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 in einem eigenen Artikel.

3.8. Messwerte (Metriken)

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

Neben dem Status OK stehen wir noch, dass 68,67 GByte von insgesamt 135,78 GByte des Dateisystems belegt sind, was 50,57 % ausmacht. Die Angaben sehen Sie im Textteil der Statusausgabe. 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 in dessen Detailansicht in der Zeile Service Metrics:

Noch interessanter ist aber, dass Checkmk automatisch den Zeitverlauf aller solcher Messwerte für (natürlich einstellbar) bis zu vier Jahren aufbewahrt. Innerhalb der ersten 48 Stunden werden die Werte minutengenau gespeichert. Dargestellt werden die Zeitverläufe in Graphen wie diesem, wie er in der  Checkmk Enterprise Edition dargestellt wird:

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

  • Fahren Sie mit der Maus über einen Messwert, so öffnet sich ein kleines Pop-up mit den genauen Werten für diesen Zeitpunkt.
  • „Packen“ Sie den Graphen an einer beliebigen Stelle im Datenbereich an. Schieben Sie die Maus nach links oder rechts, um den Zeitbereich anzupassen.
  • Schieben Sie, während Sie die Maustaste immer noch gedrückt halten, nach oben und nach unten, um die Graphen vertikal zu skalieren.
  • Mit dem Mausrad können Sie in die Zeitachse rein- und rauszoomen.
  • Mit der Ecke rechts unten können Sie den Graphen in seiner Größe ändern.

Auch in der  Checkmk Raw Edition gibt es ein System zum Anzeigen von Graphen. Es basiert auf 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 der  Checkmk Enterprise Edition. Details dazu finden Sie in einem eigenen Artikel.

4. Checkmk im Operating

4.1. Wichtige Funktionen im Operating

Sie haben Hosts ins Monitoring aufgenommen, und wir haben uns die Bedienung der Statusoberfläche angesehen. Jetzt können wir loslegen mit dem eigentlichen Monitoring. Denn der Sinn von Checkmk ist ja nicht, sich ständig mit der Konfiguration zu befassen, sondern eine Unterstützung beim IT-Betrieb zu bekommen.

Nun zeigen Ihnen die verschiedenen Statusansichten ja sehr genau, wie viele und welche Probleme es gerade gibt. Aber für die Abbildung von Workflows und ein richtiges „Arbeiten“ mit dem Monitoring benötigen wir noch etwas mehr:

In diesem Kapitel befassen wir uns zunächst nur mit den ersten beiden. Die Alarmierung behandeln wird später separat – aus guten Gründen, wie wir noch sehen werden.

4.2. Quittieren von Problemen

Beim Tactical Overview haben wir schon gesehen, dass Probleme entweder unhandled oder handled sein können. Das Quittieren ist genau die Aktion, die aus einem unbehandelten Problem ein behandeltes 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 Workflows zu etablieren.

Was passiert also beim Quittieren eines Problems genau?

  • Der Host/Service wird in der Tactical Overview in der dritten Spalte nicht mehr gelistet.
  • Das Standard-Dashboard listet das Problem ebenfalls nicht mehr auf.
  • Das Objekt wird in Statusansichten mit dem Symbol markiert.
  • Beim Quittieren wird ein Eintrag in der Objekt-History gemacht, so dass man das später nachvollziehen kann.
  • Wiederholte Alarmierungen (falls konfiguriert) werden durch Quittierungen gestoppt.

Quittieren von einzelnen Problemen

Wie können Sie also ein Problem quittieren? Nun, rufen Sie es zunächst in einer Statusansicht auf. Nun gibt es zwei Wege. Der erste Weg ist dann der beste, wenn Sie nur ein einziges Problem quittieren möchten. Dazu klicken Sie sich bis zu den Details des Hosts/Services durch – also der Ansicht mit dem Titel...

  • Status of Host myhost123 im Falle eines Hosts
  • Service myhost123, FOO Service im Falle eines Services

Klicken Sie jetzt oben auf das Symbol . Dieses öffnet eine Reihe von Eingabefeldern, über die Sie zahlreiche Aktionen auf dem dargestellten Host/Service ausführen können. Gleich das oberste Feld ist das gesuchte:

Tragen Sie hier einen Kommentar ein und klicken Sie auf Acknowledge – und nach der obligatorischen „Sind Sie sicher?“-Frage ...

... gilt das Problem als quittiert. Dazu 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...

Quittieren von mehreren Problemen auf einmal

Es ist gar nicht so selten, dass Sie eine Reihe (zusammengehöriger) Probleme auf einmal quittieren werden wollen. Das geht fast genauso einfach. Rufen Sie dafür eine Statusansicht auf, die alle diese Probleme anzeigt. Manchmal geht das mit Quicksearch. Etwas flexibler ist die Ansicht Services ➳ Service Search.

Wenn Sie es schaffen, dass die Ansicht genau die zu quittierenden Services zeigt, gehen Sie einfach wie oben beschrieben vor. Das Kommando wird dann automatisch für alle gezeigten Services ausgeführt.

Brauchen Sie jedoch eine gezielte Auswahl, dann können Sie mit einem Klick auf vor jeder Zeile eine Checkbox herbeirufen. Kreuzen Sie gewünschten Hosts oder Services an und führen dann das Kommando aus.

Achtung: Vergessen Sie nie, dass Kommandos immer automatisch auf allen angezeigten Objekten ausgeführt werden, falls Sie keine Checkboxen aktiviert haben!

4.3. Wartungszeiten

Manchmal gehen Dinge nicht aus Versehen kaputt, sondern mit Absicht. Oder sagen wir eher, das wird absichtlich in Kauf genommen. 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 natürlich auch mal auf WARN oder CRIT gehen.

Für diejenigen, die auf Probleme in Checkmk reagieren sollen, ist es dabei natürlich sehr wichtig, dass sie darüber Bescheid wissen und nicht wertvolle Zeit mit „Fehlalarmen“ verlieren. Und um dies zu gewährleisten, kennt Checkmk das Konzept von Wartungszeiten. Diese heißen auf Englisch Scheduled Downtimes (allerdings trifft man an vielen Stellen gelegentlich auch auf das verkürzte Wort Downtimes, was ja eigentlich nur bedeutet, dass ein Host DOWN bzw. ein Service CRIT ist).

Wenn also für ein Objekt eine Wartung ansteht, können Sie dies in den Wartungszustand versetzen – entweder sofort oder aber auch für einen Zeitraum in der Zukunft. Dies geschieht genauso wie das Quittieren, allerdings diesmal im Feld Downtimes:

Bei den Wartungszeiten gibt es einen ganzen Haufen von Optionen. Einen Kommentar müssen Sie in jedem Fall eingeben. Durch die Auswahl des passenden Knopfes können Sie Beginn und Ende der Wartungszeit festlegen. So wird z. B. die Schaltfläche 2 hours das Objekt vom aktuellen Zeitpunkt an für zwei Stunden als „in Wartung“ deklarieren. 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 Wartung setzen, gelten alle seine Services automatisch als in Wartung. Sparen Sie sich daher die Arbeit, dies doppelt zu machen.
  • Wenn Sie die  Checkmk Enterprise Edition nutzen, können Sie auch regelmäßige Wartungszeiten definieren (z. B. wegen eines obligatorischen Reboots einmal in der Woche).
  • Die flexiblen Downtimes beginnen automatisch erst dann, wenn das Objekt tatsächlich einen nicht-OK-Zustand annimmt.

Und hier sind die Auswirkungen einer Wartungszeit:

  • In den Ansichten erscheint ein Symbol bei den betroffenen Hosts/Services.
  • Die Alarmierung über Probleme ist während der Wartung abgeschaltet.
  • Die betroffenen Hosts/Services tauchen in der Tactical Overview nicht mehr als Probleme auf.
  • In der Verfügbarkeitsanalyse werden geplante Wartungszeiten gesondert berücksichtigt.
  • Zu Beginn und Ende einer Wartungszeit wird eine spezielle Alarmierung ausgelöst, die darüber informiert.

Weitere Hinweise zu den Wartungszeiten finden Sie wie immer in einem eigenen Artikel.

5. Finetuning des Monitorings

5.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 Kollegen mit Hunderten von E-Mails pro Tag überflutet, und bereits nach wenigen Tagen war die Begeisterung für Monitoring nachhaltig zerstört.

Auch wenn Checkmk sich wirklich Mühe gibt, für alles vernünftige Voreinstellungen zu haben, kann es einfach nicht präzise genug wissen, wie es in Ihrer IT-Umgebung unter Normalzuständen zugehen soll. Und deswegen ist von Ihrer Seite ein bisschen Handarbeit erforderlich, um das Monitoring zu feinjustieren und die letzten falschen Positiven wegzubekommen. Abgesehen davon wird Checkmk natürlich auch etliches an wirklichen Problemen finden, von denen Sie und Ihre Kollegen noch nichts geahnt haben. Und auch die gilt es erstmal zu beheben – und zwar in der Realität, nicht im Monitoring!

Bewährt hat sich daher 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.

Welche Möglichkeiten zum Feintuning Sie haben (damit alles grün wird) und wie Sie gelegentlicht Aussetzer in den Griff bekommen, zeigen wir Ihnen in diesem Kapitel.

5.2. Die regelbasierte Konfiguration

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 schreiben 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 Überwachungs­policies in Ihrem Unternehmen gelten.

Natürlich können Sie auch Einzelfälle gesondert festlegen. Eine passende Regel könnte so aussehen: „Auf dem Server srvora123 wird das Dateisystem /var/ora/db01 bei 96 % Füllgrad WARN und bei 98 % CRIT.“ Dieses Beispiel kann man als Ausnahme bezeichnen – es ist aber trotzdem eine ganz normale Regel.

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

Die Regeln sind in Regelketten organisiert. Für jede Art von Parameter in Checkmk gibt es eine eigene Regelkette. So gibt es etwa eine mit dem Namen Filesystems (used space and growth), welche die Schwellwerte für alle Services festlegt, die Dateisysteme überwachen. Wenn Checkmk also feststellen möchte, welche Schwellwerte ein bestimmter Dateisystem­check bekommt, geht es alle Regeln dieser Kette der Reihe nach durch. Die erste Regel, bei der die Bedingung zutrifft, legt den Wert fest – also in diesem Fall die genauen Voraussetzungen, wann der Dateisystemcheck WARN oder CRIT wird.

5.3. Regeln konfigurieren

Wie sieht das nun in der Praxis aus? Der normale Weg geht über das WATO-Modul Host & Service Parameters, das Ihnen alle bekannten Regelketten anbietet:

Hier kommen Sie am einfachsten mit dem Suchfeld weiter. Tippen Sie hier z. B. tablespace, so finden Sie alle Regelketten, die diesen Text im Namen oder in der (hier unsichtbaren) Beschreibung haben:

Die Zahl dahinter (hier überall 0) zeigt die Anzahl der Regeln in der jeweiligen Kette. Klicken Sie auf den Namen der Regelkette, so landen Sie bei der Detailansicht:

Die hier abgebildete Regelkette enthält noch keine Regeln. Aber mit dem Knopf Create rule in folder können Sie eine Regel anlegen. Dabei können Sie bereits den ersten Teil der Bedingung der Regel festlegen: nämlich in welchem WATO-Ordner diese gelten soll. Wenn Sie die Einstellung 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 natürlich auch das spätere Bearbeiten) bringt Sie zu einer Eingabemaske mit drei Feldern: Allgemeines, Wert und Bedingung. 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 Value einer Regel finden, ist natürlich total individuell. Wie Sie hier im Beispiel sehen, kann das schon eine ganze Menge an Parametern sein. Ein typischer Fall ist wie hier: Jeder Einzelparameter wird per Checkbox aktiviert, 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 prozentualen freien Platz im Tablespace definiert:

Das Feld mit der Bedingung sieht erstmal etwas unübersichtlicher aus:

Der Condition type erlaubt das Verwenden von vordefinierten Bedingungen, die über den Knopf Predef. Conditions verwaltet werden. Das ist ein Feature für „Poweruser“, die sehr viele Regeln mit immer den gleichen Bedingungen verwenden. Lassen Sie das zunächst einfach auf Explicit conditions stehen.

Den Folder haben Sie ja gerade beim Anlegen bereits definiert, aber hier können Sie ihn nochmal ändern.

Die Host tags (Host-Merkmale) sind ein ganz wichtiges Feature von Checkmk: Hiermit können Sie eben z. B. sagen, dass eine Regel nur für Produktivsysteme gelten soll. Weil die Host-Tags so wichtig sind, widmen wir ihnen gleich im Anschluss einen eigenen Abschnitt. Um eine Tag-Bedingung hinzuzufügen, wählen Sie zunächst in der Auswahlliste eine Tag-Gruppe aus und drücken danach auf Add tag condition.

Mit den Explicit hosts können Sie die Regel auf einige ganz bestimmte Hosts beschränken.

Sehr wichtig 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. Diese kann z. B. Tablespace DW20 lauten – also inklusive des Wortes Tablespace. Im gezeigten Beispiel hingegen möchte man von Ihnen lediglich den Namen des Tablespaces selbst, also z. B. DW20.
  • Die Texte werden immer gegen den Anfang gematcht! Die Beispielregel greift also auch auf den fiktiven Tablespace DW20A. Wenn Sie das nicht möchten, hängen Sie ein $ ans Ende – z. B. DW20$. Denn es handelt sich hier um sogenannte reguläre Ausdrücke.

Die Labels, die Sie im Screenshot ebenfalls sehen, behandelt das Handbuch in einem eigenen Kapitel.

Nach dem Speichern findet sich in der Regelkette genau eine Regel:

5.4. Host-Merkmale (Host-Tags)

So funktionieren Host-Tags

Oben 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-Tag Productive system definiert. Warum macht man das nicht stattdessen einfach über Ordner? Nun, Sie können ja leider nur eine einzige Ordnerstruktur definieren, und jeder Host kann nur in einem Ordner sein. Es gibt aber viele ganz unterschiedliche Merkmale, die ein Host haben kann. Dafür sind die Ordner einfach nicht flexibel genug.

Tags hingegen können Sie den Hosts völlig frei und beliebig zuordnen – egal, in welchem Ordner die Hosts sind. Und danach können sich Regeln auf diese Tags 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?

Tag-Gruppen und Tags definieren

Beginnen wir mit der zweiten Frage: eigene Merkmale. Zunächst müssen Sie wissen, dass Merkmale in Gruppen organisiert sind: Tag-Gruppen (Merkmalsgruppen). Nehmen wir als Beispiel den Standort. Eine Merkmalsgruppe könnte also Standort heißen. Und diese Gruppe könnte die Merkmale München, Austin und Singapur enthalten. Grundsätzlich gilt dabei, dass jeder Host in jeder Gruppe genau ein Merkmal hat. Sobald Sie also eine eigene Tag-Gruppen definieren, hat jeder Host immer ohne Ausnahme eines der Merkmale aus dieser. Hosts, bei denen Sie kein Merkmal aus der Gruppe gewählt haben, bekommen einfach per Default das erste zugewiesen.

Die Definition der Tag-Gruppen finden Sie im WATO-Modul WATO ➳ Tags.

Wie Sie sehen, sind einige Tag-Gruppen bereits vordefiniert. Die meisten davon können Sie nicht ändern. Wir empfehlen Ihnen außerdem, die beiden vordefinierten Beispiele Criticality und Networking Segment einfach in Ruhe zu lassen. Definieren Sie lieber Ihre eigenen Gruppen. Das ist sehr einfach.

Klicken Sie auf New tag group. Das bringt Sie wie erwartet zu einer Maske mit mehreren Feldern. Im ersten vergeben Sie wie so oft in Checkmk eine interne ID – die als Schlüssel gilt und später nicht mehr geändert werden kann – und einen sprechenden Titel, den Sie später jederzeit anpassen können. Das Topic dient nur der Übersicht. Wenn Sie hier eines vergeben, wird das Merkmal bei den Host-Eigenschaften in einem eigenen Feld angezeigt.

Im zweiten Feld kommen die eigentlichen Tags, also die Auswahlmöglichkeiten der Gruppe. Auch hier vergeben Sie pro Tag eine interne ID und einen Titel:

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 entweder das Merkmal oder nicht.
  • Ignorieren Sie die Auxiliary Tags am besten.

Sobald Sie gespeichert haben, können Sie die neue Tag-Gruppe nutzen.

Tags den Hosts zuordnen

Wie Sie einem Host Tags zuordnen, haben Sie eigentlich schon gesehen: bei den Host-Eigenschaften beim Anlegen oder Bearbeiten eines Hosts. Im Feld Custom attributes (oder in einem eigenen, falls Sie ein Topic vergeben haben) taucht nun die neue Tag-Gruppe auf, und Sie können für den Host eine Auswahl treffen:

Wie immer können Sie das Tag auch beim Ordner festlegen und bei einzelnen Hosts nach Bedarf überschreiben.

5.5. Regelketten einfacher finden

Es gibt sehr viele Regelketten, und mit der Suche die richtige zu finden, ist nicht immer einfach. Es gibt aber noch einen anderen Weg: Wenn Sie einen bestimmten Service haben und dessen Check-Parameter anpassen möchten, klicken Sie auf das Menü und wählen den Eintrag Parameters for this services:

Sie gelangen zu einer Seite, in der Sie Zugriff auf alle Regelketten dieses Services haben:

Im ersten Feld mit dem Titel Check origin and parameters führt Sie der zweite Eintrag (hier CPU utilization on Linux/UNIX) direkt zur Regelkette, welche die Schwellwerte für diesen Service festlegt.

5.6. Schwellwerte für Dateisysteme

Nachdem Sie jetzt das Grundprinzip der Konfiguration von Services kennengelernt haben, möchte ich Ihnen im Rest des Kapitels einige wichtige Dinge zeigen, die Sie in einem neuen Checkmk-System konfigurieren sollten, um Fehlalarme zu reduzieren.

Das erste sind angepasste Schwellwerte für die Überwachung von Dateisystemen. Per Default nimmt Checkmk für belegten Plattenplatz die Schwellen 80 % für WARN und 90 % für CRIT. Nun sind 80 % bei einer 2 TByte großen Platte immerhin 400 GByte – vielleicht ein bisschen viel Puffer. Deswegen hier ein paar Tipps dazu:

  • Legen Sie Ihre eigenen Regeln in der Kette Filesystem (used space and growth) an.
  • 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's mit dem Magic factor, den wir im Kapitel Best practices vorstellen.

5.7. Hosts, die DOWN gehen dürfen

Nicht immer ist es ein Problem, wenn ein Rechner abgeschaltet wird. Der Klassiker ist das bei Druckern. Diese mit Checkmk zu überwachen, ist durchaus sinnvoll. Manche Anwender managen sogar die Nachbestellung von Tonern mit Checkmk. Aber das Ausschalten eines Druckers vor Feierabend ist ja kein Problem, sondern eher positiv. Dumm nur, wenn Checkmk hier alarmiert, weil der entsprechend Host DOWN ist.

Sie können Checkmk sagen, dass es völlig in Ordnung ist, wenn ein Host ausgeschaltet ist. Dazu suchen Sie in WATO ➳ ➳ Host & Service parameters nach dem Regelsatz Host check command. Legen Sie dort eine Regel für alle Drucker an (je nach Ihrer Struktur z. B. über einen Ordner oder über ein passendes Host-Merkmal) und setzen Sie den Wert auf Always assume host to be up:

Jetzt werden alle Drucker grundsätzlich als UP angezeigt – egal, wie der Status wirklich ist.

5.8. Switchports

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 Defaulteinstellung für Core- und Distribution-Switches – also solche, wo nur Infrastrukturgeräte oder Server angeschlossen sind. Bei Switches, an denen Endgeräte wie Arbeitsplätze oder Drucker angeschlossen sind, führt das aber zu ständigen Alarmen, weil wiedermal 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 Herangehensweisen etabliert. So können Sie die Überwachung auf die Upllink-ports beschränken. Dazu legen Sie eine Regel bei den disabled 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 Drucker oder Arbeitsplätze 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. Die erste ist in der Kette Parameters for discovered services ➳ Discovery – automatic service detection ➳ Network Interface and Switch Port Discovery. Diese legt fest, unter welchen Bedingungen Switchports überwacht werden sollen. Legen Sie eine Regel für die gewünschten Switches an und aktivieren Sie unter Network interface port states to discover neben 1 - up auch 2 - down:

In der Service-Konfiguration der Switches werden die Ports mit dem Zustand DOWN nun auch angeboten, und Sie können sie zur Serviceliste hinzufügen. Bevor Sie das Ganze aktivieren, benötigen Sie jetzt natürlich noch die zweite Regel, die dafür sorgt, dass dieser Zustand als OK gewertet wird. Die Regelkette heißt Network interfaces and switch ports. Aktivieren Sie die Option Operational state, deaktivieren Sie hier Ignore the operational state und aktivieren Sie bei den Allowed states die Zustände 1 - up und 2 - down (und eventuell weitere Zustände).

5.9. Hosts, die regelmäßig gebootet werden

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

In der  Checkmk Raw Edition definieren Sie zunächst eine Timeperiod, welche die Zeiten des Reboots abdeckt. Wie das geht, erfahren Sie im Artikel über die Timeperiods. Danach legen Sie jeweils eine Regel in den Ketten Notification period for hosts und Notification period for services für die betroffenen Hosts an und wählen dort die zuvor definierte Timeperiod aus. Die zweite Regel ist notwendig, 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.

In der  Checkmk Enterprise Edition gibt es Wartungszeiten, die sich automatisch regelmäßig wiederholen können, die Sie für die betroffenen Hosts einfach setzen können.

Tipp: Neben dem Weg über Kommandos, die wir bei den Wartungszeiten gezeigt haben, gibt es auch noch den Weg über den 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 bekommen.

5.10. Services dauerhaft ignorieren

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

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

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

Weitere Informationen zur Konfiguration von Services lesen Sie in einem eigenen Artikel im Referenzteil.

5.11. Mittelwerte

Ein Grund für sporadische Alarmierungen sind Schwellwerte auf Auslastungsmetriken, wie z. B. die CPU-Auslastung, 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-Plug-ins 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 die Regelkette für die CPU-Auslastung für nicht-Unix-Systeme mit dem Namen CPU utilization for simple devices. Hier gibt es die Option Averaging for total CPU utilization:

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

5.12. Sporadische Fehler in den Griff bekommen

Wenn alles nichts hilft und manche Services einfach gelegentlich für einen einzelnen Check (also für eine Minute) auf einen Problemstatus gehen, gibt es eine letzte Methode, die Fehlalarme verhindert. Dazu gibt es die Regelkette 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, gilt das Problem als „hart“ und wird gemeldet.

Das ist zugegeben keine schöne Lösung, und Sie sollten immer versuchen, das Problem an der Wurzel zu bekämpfen, aber manchmal sind die Dinge einfach wie sie sind, und mit den Check attempts haben Sie für solche Fälle zumindest einen gangbaren Workaround.

5.13. Neue und weggefallene Services

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;

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 in WATO die Service-Konfiguration aufrufen und diese wieder auf den aktuellsten Stand bringen.

Tipp: Manche Anwender speichern ein Lesezeichen für eine Ansicht, die alle Discovery-Services auf allen Hosts zeigt, die nicht im Zustand OK sind. Diese können Sie dann regelmäßig – z. B. einmal pro Tag – abarbeiten.

6. Arbeit mit mehreren Benutzern

6.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 entstehen dabei eine Reihe von Schwierigkeiten. Wenn Sie pro Person einen Account anlegen, haben Sie etliche Vorteile:

  • Benutzer können eigene Lesezeichen anlegen, ihre Seitenleiste individuell einrichten und auch andere Dinge für sich anpassen.
  • Unterschiedliche Benutzer können unterschiedliche Berechtigungen haben.
  • Benutzer können nur für bestimmte Hosts und Services zuständig sein und dann auch nur diese im Monitoring sehen.

Wie immer finden Sie alle Details zum Thema Benutzer, Rechte und Rollen in einem eigenen Artikel.

6.2. Rechte und Rollen

Vor allem die letzten beiden Punkte sind erklärungsbedürftig. Beginnen wir mit den Berechtigungen – also mit der Frage, welcher Benutzer welche Dinge tun darf. Dafür verwendet Checkmk das übliche 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 eine Berechtigung für das Ändern der globalen Einstellungen.

Checkmk wird mit drei Basisrollen ausgeliefert. Diese lauten:

Rolle Kürzel Bedeutung
Administrator admin Ein Benutzer mit dieser Rolle darf alles. Seine Hauptaufgabe ist das generelle Konfigurieren von Checkmk, nicht das Operating. Dies schließt natürlich auch das Anlegen von Benutzern und Anpassen von Rollen ein.
Normal monitoring user user Diese Rolle ist für einen „normalen“ Benutzer im Operating. Der darf grundsätzlich nur solche Hosts und Services sehen, für die er zuständig ist. Zudem besteht die Möglichkeit, dass Sie ihm das Recht geben, seine Hosts in WATO 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 Monitorings zeigt. Da ein Gastbenutzer nichts ändern kann, ist es auch möglich, dass mehrere Kollegen diesen Account gleichzeitig verwenden.

Wie Sie Rollen anpassen können, erfahren Sie im ausführlichen Artikel zur Benutzerverwaltung.

6.3. Kontakte und Zuständigkeiten

Der zweite wichtige Aspekt von Benutzern ist das Definieren von Zuständigkeiten. Wer ist für den Host mysrv024 oder für den Service Tablespace FOO auf dem Host ora012 zuständig? Wer soll diesen in der Statusoberfläche sehen und eventuell alarmiert werden, wenn es ein Problem gibt?

Dies geschieht in Checkmk nicht über Rollen, sondern über Kontaktgruppen. 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:

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

  • Ein Benutzer der Rolle user sieht im Monitoring genau die Objekte, die in einer seiner Kontakgruppen sind.
  • 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.

6.4. Anlegen von Kontaktgruppen

Das Erzeugen von neuen Kontaktgruppen ist sehr einfach und geschieht im WATO-Modul Contact groups. Eine Kontaktgruppe mit dem Namen Everything ist bereits vordefiniert. Dieser sind automatisch alle Hosts und Services zugewiesen. Der Sinn davon sind einfache Setups, in denen es noch keine Aufgabenteilung unter den Administratoren gibt (oder Sie sowieso alles alleine übernehmen).

Mit New contact group legen Sie eine neue Gruppe an. Hier brauchen Sie wie immer eine ID, die intern als Schlüssel verwendet wird, sowie einen Titel, den Sie später auch ändern können. Hier im Beispiel sehen Sie eine Kontaktgruppe mit der ID servers und dem Titel Windows & Linux Servers:

6.5. Hosts zuordnen

Nachdem Sie die Kontaktgruppen angelegt haben, müssen Sie einerseits Hosts und Services zuordnen und andererseits natürlich Benutzer. Letzteres machen Sie in den Eigenschaften der Benutzer selbst, was wir gleich im Anschluss sehen werden.

Für die Zuordnung von Hosts zu Kontaktgruppen gibt es zwei Wege, die Sie auch gleichzeitig wählen können:

  1. Zuweisung über Regeln mit dem Regelsatz Assignment of hosts to contact groups
  2. Zuweisung über die Eigenschaften der Hosts oder Ordner in WATO

Zuordnung über Regeln

Den Regelsatz, den Sie für die erste Methode bennötigen, finden Sie am einfachsten über den Knopf Rules im Modul Contact groups. Aber wie immer hilft auch die Suchfunktion unter Host & service parameters, wenn Sie einfach nach contactgroups suchen:

Auch bei einer frischen Checkmk-Installation ist der Regelsatz übrigens nicht leer. Sie finden hier eine Regel, die alle Hosts der oben erwähnten Gruppe Everything zuweist. Legen Sie hier also selbst neue Regeln an und wählen die jeweilige Gruppe, die Sie den per Regel gewählten Hosts zuweisen wollen:

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

Zuordnung über WATO-Eigenschaften

Die zweite Methode der Zuordnung geht über die Eigenschaften eines Hosts in WATO. Das Vorgehen ist wie folgt:

  1. Rufen Sie die Eigenschaften des Hosts in WATO auf.
  2. Aktivieren Sie im Kasten Basic settings die Checkbox Permissions.
  3. Wählen Sie im Kasten Available eine oder mehrere Gruppen aus und verschieben diese mit dem Pfeil nach rechts in das Feld Selected.
  4. Aktivieren Sie Add these contact groups to the Hosts.

Die Checkbox Always add host contact groups also to its services benötigen Sie in der Regel nicht, denn Services erben automatisch die Kontaktgruppen ihrer Hosts. Mehr dazu erfahren Sie gleich im Anschluss.

Natürlich können Sie wie immer diese Host-Eigenschaft auch im Ordner festlegen. Das Verfahren ist ähnlich, nur dass diesmal ein paar zusätzliche Checkboxen auftauchen, die Sie einfach in ihrem Defaultzustand belassen.

6.6. Services zuordnen

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

Das ermöglicht Ihnen z. B. eine Trennung von Serverbetrieb und Anwendung. Stecken Sie z. B. den Host srvwin123 in die Kontaktgruppe windows, aber alle Services, die mit dem Präfix Oracle beginnen, in die Kontaktgruppe oracle, so werden die Windows-Admins die Oracle-Services nicht sehen, und die Oracle-Admins bekommen umgekehrt keine Details zu den Services des Betriebssystems – eine oft sehr sinnvolle Aufteilung.

Sollten Sie diese Trennng nicht benötigen, dann legen Sie einfach Zuordnungen für die Hosts fest – fertig!

Benötigen Sie dennoch eine explizite Zuordnung, so geschieht das über den Regelsatz Assignment of services to contact groups. Das Verfahren ist analog zu dem oben beschriebenen, allerdings geben Sie wie gewohnt hier noch Bedingungen für die Service-Namen an.

6.7. Anlegen von Benutzern

Die Verwaltung der Benutzer finden Sie im WATO-Modul Users:

Wundern Sie sich nicht, wenn es dort nebem dem Eintrag cmkadmin auch einen Benutzer automation gibt! Dieser ist für Zugriffe von Prozessen und Skripten auf die HTTP-API gedacht und wird vom Checkmk-System selbst genutzt. Näheres dazu finden Sie im Referenzteil.

Und falls Sie über den Knopf LDAP Connections gestolpert sind: Wenn Sie in Ihrer Firma Active Directory oder einen anderen LDAP-Dienst einsetzen, haben Sie auch die Möglichkeit, Benutzer und Gruppen aus diese Diensten einzubinden. Dies wird in einem eigenen Artikel beschrieben.

Einen neuen Benutzer legen Sie mit dem Knopf New user an. Diese Maske ist natürlich fast identisch mit derjenigen, die Sie sehen, wenn Sie einen bestehenden Benutzer bearbeiten (das Symbol neben dem Benutzer), nur dass dort keine Änderung des Benutzernamens möglich ist:

Im ersten Feld geben Sie wie immer eine ID und einen Titel 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 Mailadresse ein. Lesen Sie zunächst die Hinweise im Kapitel über die Alarmierung.

Das zweite Feld betrifft Sicherheit und Berechtigungen:

Lassen Sie die Einstellung auf Normal user login with password und vergeben Sie hier in initiales Passwort. Ganz unten können Sie dem Benutzer Rollen zuordnen. Ordnen Sie mehr als eine Rolle zu, so bekommmt der Benutzer einfach das Maximum an Berechtigungen aus diesen Rollen (für die drei vordefinierten Rollen ist das allerdings nicht sehr sinnvoll).

Im dritten Feld wählen Sie aus, zu welchen Kontaktgruppen der Benutzer gehören soll. Wählen Sie die vordefinierte Gruppe Everything aus, so wird der Benutzer für alles zuständig sein, da in dieser Gruppe jeder Host und Service enthalten ist:

Übrigens: Das Feld Personal Settings enthält genau die Einstellungen (bis auf das Passwort), die der Benutzer auch selbst ändern kann. Benutzer der Rolle guest können ihre Einstellungen nicht ändern, und so gibt es hier die Möglichkeit, z. B. die Sprache oder das User interface theme einzustellen.

7. Alarmierung

7.1. Grundlegendes

Alarmierung (Notification) bedeutet in Checkmk, dass Benutzer aktiv darüber benachrichtigt werden, wenn sich der Zustand von einem Host oder Service ä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 z. B. 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, und es gibt zahlreiche Möglichkeiten, wie Sie das verfeinern können:

  • Sie können alarmieren per SMS, Pager, Slack und anderen Internetdiensten.
  • Sie können Alarmierungen an bestimmten Zeitfenstern festmachen (Bereitschaft).
  • 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 komplexe 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 haben einen Leitstand, der rund um die Uhr besetzt ist und lediglich mit der Statusansicht arbeitet.
  • Aktivieren Sie die Alarmierung zunächst nur für sich selbst und machen Sie sich für alles zuständig. Beobachten Sie ein paar Tage oder Wochen, wie groß das Volumen an Alarmen ist. Tunen Sie Ihr Monitoring.
  • Aktivieren Sie die Alarmierung für Ihre Kollegen erst dann, wenn Sie die falschen Positiven (Fehlalarme) auf ein Minimum reduziert haben.

7.2. Mailversand vorbereiten

Der einfachste und bei weitem üblichste Fall ist die Alarmierung per E-Mail. Das ist leicht einzurichten, und in einer E-Mail ist genug „Platz“, um auch die Graphen der 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 installieren. Dies geschieht meist automatisch bei der Installation der Distribution.
  2. Geben Sie einen Smarthost an. Auch hier werden Sie meist bei der Installation des 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 harri.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. Weitere Details zum Einrichten von Mailservices unter Linux finden Sie im Referenzteil des Handbuchs.

7.3. Alarmierung per E-Mail aktivieren

Wenn der Versand von E-Mail grundsätzlich funktioniert, dann ist das Aktivieren der Alarmierung sehr einfach – und vielleicht haben Sie es quasi schon ohne zu wissen beim Anlegen der Benutzer gemacht. Damit ein Benutzer Alarme bekommt, sind folgende zwei Schritte notwendig:

  • In den Eigenschaften des Benutzers muss eine Mailadresse eingetragen sein.
  • Der Benutzer muss für Hosts oder Services zuständig sein (über entsprechende Kontaktgruppen).

7.4. Alarmierung ausprobieren

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 dem Kommando Fake check results. Dies finden Sie auf dem gleichen Weg, wie die Quittierungen oder die Wartungszeiten.

Wichtig: Dieser Kasten ist nur dann sichtbar, wenn Sie die Rolle admin besitzen.

Wählen Sie am besten einen Service, der gerade OK ist, und setzen ihn per Hand auf CRIT. 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 sollte ausgelöst werden: die vom Recovery.

7.5. Unterdrückte Alarmierung

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

  • Wenn ein Host auf DOWN ist, werden keine Alarmierungen seiner Services ausgelöst!
  • Wenn Sie die Alarmierung im Snapin Master Control ausgeschaltet haben.
  • Wenn ein Service oder Host sich in einer Wartungszeit befindet.
  • Wenn der Zustand in letzter Zeit zu oft zwischen verschiedenen Zuständen gewechselt hat und der Service deswegen als unstetig (flapping) markiert wurde! Dies kann schnell passieren, wenn Sie mittels Fake check results den Zustand ständig wechseln!

7.6. Anpassen der Alarmierung

Sie können Sie Alarmierung in Checkmk auf unteschiedlichste Art anpassen und sehr komplexe Regelwerke definieren, wer wann auf welchem Weg benachrichtigt werden soll. Alle Einzelheiten dazu erfahren Sie im Referenzteil des Handbuchs.

7.7. Fehlersuche

Das Alarmierungsmodul in Checkmk ist sehr komplex – einfach weil es sehr viele sehr unterschiedliche Anforderungen abdeckt, die sich in über 10 Jahren Praxiserfahrung als wichtig herausgestellt haben. Die Frage „warum hat Checkmk hier nicht alarmiert“ wird Ihnen deswegen gerade am Anfang öfters 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 des Services zu betrachten. Diese finden Sie, wenn Sie in die Detailseite des Services in der Statusoberfläche gehen und dort auf den Knopf History klicken. Dort finden Sie alle Ereignisse dieses Services chronologisch von neu nach alt aufgelistet. Hier ist ein Beispiel von einem Service, wo zwar versucht wurde, die Alarmierung auszulösen, aber der Mailversand nicht funktioniert hat (weil kein SMTP-Server installiert ist):

Noch mehr Informationen finden Sie in der Datei var/log/notifiy.log. Diese können Sie z. B. im Terminal mit dem Befehl less auslesen oder mit dem Kommando tail -f fortlaufend beobachten. Letzteres ist dann sinnvoll, wenn Sie nur an neuen Meldungen interessiert sind, also solchen, die erst nach der Eingabe von tail entstanden sind. Vergessen Sie nicht, zunächst mit su - zu Ihrem Instanzbenutzer zu wechseln:

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

Jetzt können Sie die Datei mit less öffnen:

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

Falls Sie less noch nicht kennen: Mit Umschalt-G springen Sie ans Ende der Datei (bei Logdateien ist das ja immer nützlich), und mit Q beenden Sie less.

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

Falls Sie tiefer in das Thema Alarmierung einsteigen möchten, finden Sie alle Details im Referenzteil des Handbuchs.

8. Das Monitoring weiter ausbauen

Mit dem Einrichten der Alarmierung haben Sie den letzten Schritt vollzogen, und Ihr Checkmk-System ist einsatzbereit! Damit sind die Möglichkeiten von Checkmk natürlich noch nicht ansatzweise ausgereizt. Es gibt zahlreiche Möglichkeiten, Ihr Monitoring weiter auszubauen.

8.1. Sicherheit optimieren

Auch wenn Monitoring „nur schaut“, ist das Thema IT-Sicherheit auch hier wichtig. Im Referenzteil finden Sie dazu einen Übersichtsartikel, der Ihnen Tipps gibt, wie Sie die Sicherheit Ihres Systems optimieren können.

8.2. Sehr große Umgebungen überwachen

Wenn Ihr Monitoring eine Größenordnung erreicht hat, wo Sie Tausende oder noch mehr Hosts überwachen, werden Fragen der Architektur und des Tunings interessant. Das wichtigste Thema ist hier zunächst das verteilte Monitoring. Dabei arbeiten Sie mit mehreren Checkmk-Instanzen, die Sie zu einem großen System zusammenschalten und die vielleicht sogar global verteilt sind.

8.3. Verfügbarkeit und SLAs

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

Und mit dem in der  Checkmk Enterprise Edition enthaltenen SLA-Modul können Sie Checkmk die Einhaltung von Service-Level-Agreements überprüfen und sogar aktiv überwachen lassen.

8.4. Hardware-/Software-Inventur

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 übermitteln. Dies ist sehr hilfreich für die Wartung, das Lizenzmanagement oder das automatische Befüllen von Configuration Management Databases.

8.5. Überwachen von Meldungen und Events

Bisher haben wir uns nur mit der Überwachung der aktuellen Zustände von Hosts oder Services befasst. Ein ganz anderes Thema ist das Auswerten von spontanen Meldungen, die z. B. in Logdateien auftauchen oder per Syslog oder SNMP-Traps versendet werden. Checkmk hat dafür ein komplett integriertes System mit dem Namen Event Console.

8.6. Visualisierung auf Karten und Diagrammen

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. für Bildschirme in Leitständen.

8.7. Business Intelligence

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

8.8. PDF-Berichte erstellen

Das in der  Checkmk Enterprise Edition enthaltene Reporting-Modul von Checkmk erlaubt Ihnen das Erstellen von PDF-Berichten zu Zeiträumen in der Vergangenheit, die Ereignisse, Verfügbarkeiten und vieles mehr übersichtlich darstellen können.

8.9. Agenten automatisch updaten

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

8.10. Eigene Plug-ins entwickeln

Auch wenn Checkmk fast zweitausend Check-Plug-ins mit ausliefert, kann es immer sein, dass ein konkretes Plug-in fehlt. Wie Sie solche selbst entwickeln können, lesen Sie in einem eigenen Bereich im Handbuch.

9. Best Practises, Tipps & Tricks

9.1. CPU-Single-Core-Auslastung

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 natürlich sinnvoll, erkennt aber eine Reihe von Fehlern nicht, beispielsweise dass ein einzelner Prozess Amok läuft und permanent eine CPU mit 100 % belastet. Bei einem System mit 16 CPUs trägt eine CPU nur mit 6.25 % zur Gesamtleistung bei, und so wird im Extremfall selbst in diesem Fall nur eine Auslastung von 6.25 % gemessen – was natürlich nicht zu einer Alarmierung führt.

Deswegen bietet Checkmk die Möglichkeit (sowohl für Windows als auch für Linux), 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 das für Ihre Windows-Server einzurichten, legen Sie eine Regel in der Kette CPU utilization for simple devices an. Diese Regel ist eigentlich auch zuständig für die Überwachung aller CPUs. Es gibt hier aber eine Option mit dem Namem Levels over an extended time period on a single core CPU utilization. Aktivieren Sie in der Regel nur diese Option:

Definieren Sie die Regelbedingung so, dass sie nur für die Windows-Server greift, z. B. durch einen geeigneten Ordner oder ein Host-Tag. Diese Regel wird andere Regeln in der gleichen Kette nicht beeinflussen, wenn diese andere Optionen festlegen, z. B. die Schwellwerte für die Gesamtauslastung.

Die zusätzliche Überprüfung findet im bereits vorhandenen Service CPU utilization statt.

Bei Linux-Servern ist dafür die Regelkette CPU utilization on Linux/UNIX zuständig, wo Sie exakt die gleiche Option finden.

9.2. Windows-Dienste überwachen

In der Voreinstellung überwacht Checkmk auf Ihren Windows-Servern keine Dienste! Warum nicht? Nun, weil nicht automatisch klar ist, 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 von Hand – quasi außer der Reihe – gestartet wurden. Denn diese werden nach einem Reboot nicht mehr laufen, was natürlich ein Problem sein kann.

Dazu benötigen Sie zunächst eine Regel in der Kette Windows Services, die Sie wie immer bequem mit der Suchfunktion finden können. Die entscheidende Option in dieser Regel lautet Service states. Aktivieren Sie diese und fügen Sie drei Elemente hinzu:

Dadurch erreichen Sie folgende Überwachung:

  • Ein Dienst mit der Startart Automatisch, der läuft, gilt als OK.
  • Ein Dienst mit der Startart automatisch, 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! Deswegen benötigen wir jetzt noch einen zweiten Schritt: Erstellen Sie dazu eine neue Regel in der Kette Windows Service Discovery. Diese regelt, welche Windows-Dienste Checkmk automatisch als zu überwachende Services vorschlägt.

Wenn Sie diese Regel anlegen, können Sie zunächst im Feld Services (Regular Expressions) den regulären Ausdruck .* angeben, der auf alle Services matcht. Wenn Sie dann speichern und bei einem passenden Host in die Service-Konfiguration in WATO wechseln, werden Sie eine große Zahl von neuen Services finden – für jeden Windows-Service einen.

Um die Anzahl der überwachten Services einzuschränken, kehren Sie dann zu der Regel zurück und verfeinern die Suchausdrücke nach Bedarf. Dabei wird Groß-/Kleinschreibung unterschieden! Hier ist ein Beispiel:

Sollten Sie die Services vorhin schon in die Überwachung aufgenommen haben, erscheinen diese jetzt als fehlend. Mit dem Knopf Automatic refresh (tabula rasa), können Sie reinen Tisch machen und die ganze Liste neu generieren.

9.3. Überwachen der Internetverbindung

Der Zugang Ihrer Firma zum Internet ist natürlich für alle sehr wichtig. Die Überwachung desselben ist dabei etwas ungewöhnlich. Denn es gibt ja nicht „das Internet“, sondern Milliarden von Hosts. Sie können aber trotzdem sehr effizient eine Überwachung einrichten nach folgendem Bauplan:

  1. Wählen Sie mehrere Ping-Ziele im Internet, die normalerweise erreichbar sein sollten, und notieren deren IP-Adressen.
  2. Legen Sie in WATO einen Host, etwa mit dem Namen internet, an.
  3. Tragen Sie eine der IP-Adressen bei diesem Host als IPv4-Adresse ein.
  4. Tragen Sie die weiteren Adressen bei demselben Host unter der Option Network address ➳ Additional IPv4 addresses ein.
  5. Setzen Sie ferner Data sources ➳ Check_MK Agent auf No agent.
  6. Legen Sie eine Regel unter Active checks (HTTP, TCP, etc.) ➳ Check hosts with PING (ICMP Echo Request) an, die nur für diesen Host greift.
  7. Aktivieren Sie in dieser Regel die Option Service description und tragen Sie in das Feld als Service-Namen Internet connection ein.
  8. Aktivieren Sie außerdem die Option Alternative address to ping und wählen Sie dort Ping all IPv4 addresses aus.
  9. Aktivieren Sie Number of positive responses required for OK state und tragen Sie 1 ein.
  10. Legen Sie eine weitere Regel an – diesmal unter Monitoring Configuration ➳ Host check command, die ebenfalls nur für den Host internet gilt.
  11. Wählen Sie dort im Feld Host check command die Option Use the status of a service... und tragen Sie den Service-Namen Internet connection ein, den Sie im 7. Schritt definiert haben.

Wenn Sie jetzt die Änderungen aktivieren, erhalten Sie einen neuen Host mit dem Namen internet und 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 bei dem Service für jedes der Ping-Ziele Messdaten für die typische Round-Trip-Zeit sowie den Paketverlust und bekommen so auch einen Anhaltspunkt für die Qualität Ihrer Verbindung im Laufe der Zeit:

Die Schritte 10. und 11. sind notwendig, damit der Host nicht den Zustand DOWN bekommt, falls die erste IP-Adresse nicht per ping erreichbar ist. Stattdessen übernimt der Host als Zustand immer 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 machen – nicht über den Service. Außerdem sollten Sie einen Alarmierungsweg verwenden, der keine Internetverbindung voraussetzt!

9.4. Überwachen von HTTP/HTTPS-Diensten

Nehmen wir an, Sie wollen die Erreichbarkeit einer Website oder eines Webdienstes 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 Zielhost – in diesem Fall HTTP(S). Das Vorgehen ist wie folgt:

  1. Legen Sie den Zielserver als Host in WATO an. Nehmen wir an, er heißt tribe29.com.
  2. Wählen Sie bei Data sources ➳ Check_MK Agent die Einstellung No agent und speichern Sie ohne Service-Erkennung.
  3. Legen Sie jetzt eine Regel im Regelsatz Active Checks (HTTP, TCP, etc.) ➳ Check HTTP service an, die für diesen Host greift (z. B. mit Explicit hosts oder einem passenden Host-Tag).
  4. Im Kasten Check HTTP service finden Sie zahlreiche Optionen, wie der Check durchgeführt werden soll. Mehr dazu gleich im Anschluss.
  5. 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.

Bei den Optionen der Regel gibt es Folgendes zu beachten:

  • Eventell müssen Sie bei Virtual host die Domäne des Servers angeben, wenn dieser mehr als eine Domäne hostet.
  • Die Option Use SSL/HTTPS for the connection ermöglicht die Überwachung von HTTPS.
  • Bei Expected response time können Sie den Service auf WARN oder sogar CRIT setzen lassen, wenn die Antwortzeit zu schlecht ist.
  • Die Option Fixed string to expect in the content erlaubt das Prüfen, ob in der Antwort – also in der gelieferten Seite – ein bestimmter Text vorkommt. Damit sollten Sie immer einen relevanten Teil des Inhalts prüfen, damit nicht eine simple Fehlermeldung des Servers auch als positive Antwort gewertet wird.

Übrigens können Sie den HTTP-Check natürlich auch auf einem Host durchführen, der bereits normal mit Checkmk per Agent überwacht wird. In diesem Fall entfällt das Anlegen des Hosts und Sie benötigen einfach nur die passende Regel.

9.5. Intelligente Schwellwerte für Dateisysteme

Gute Schwellwerte für die Überwachung von Dateisystemen zu finden, kann etwas mühsam sein und viele Regeln erfordern. Denn eine Schwelle von 90 % ist bei einer sehr großen Platte viel zu niedrig und bei einer kleinen vielleicht schon zu knapp. Neben der im Kapitel über das Tuning erwähnten Methode, Schwellen in Abhängigkeit von der Plattengröße zu definieren, gibt es aber noch etwas Praktischeres: den Magic factor. Das funktioniert so:

  1. Im Regelsatz Filesystems (used space and growth) legen Sie nur einzige Regel an und zwar mit den Schwellwerten 80 % bzw. 90 %.
  2. In derselben Regel aktivieren Sie die Option Magic factor (automatic level adaptation for large filesystems) und tragen 0.8 ein.
  3. Aktivieren Sie ferner Reference size for magic factor und tragen als Größe 100 GByte ein.

Wenn Sie jetzt das Ganze aktivieren, erhalten Sie Schwellwerte, die automatisch von der Größe des Dateisystems abhängen:

  1. Dateisysteme, die genau 100 GByte groß sind, erhalten die Schwellwerte 80 %/90 %.
  2. Dateisysteme, die größer als 100 GByte sind, erhalten höhere Schwellwerte, also solche, die näher an 100 % sind.
  3. Dateisysteme, die kleiner als 100 GByte sind, erhalten niedrigere Schwellwerte, also solche, die unter 80 %/90 % sind.

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 Platten bekommen die gleichen Werte. Kleinere Werte verbiegen die Schwellwerte stärker. Welche Schwellen genau gelten, können Sie bei jedem Service einfach in seinem Statustext sehen:

Folgende Tabelle zeigt einige Beispiele für die sich ergebenden Schwellwerte bei einer Referenzgröße von 100 GByte:

Plattengröße mf = 1.0 mf = 0.9 mf = 0.8 mf = 0.7 mf = 0.6 mf = 0.5
800 GByte80 % 84 % 87 % 89 % 91 % 93 %
300 GByte80 % 82 % 84 % 86 % 87 % 88 %
100 GByte80 % 80 % 80 % 80 % 80 % 80 %
50 GByte80 % 82 % 83 % 85 % 86 % 87 %
5 GByte80 % 73 % 64 % 51 % 50 % 50 %