Das Monitoring feinjustieren

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 Benachrichtigungen für alle aktiviert hatten, wurden die Kolleginnen mit Hunderten von E-Mails pro Tag überflutet, und bereits nach wenigen Tagen war die Begeisterung für das Monitoring nachhaltig gestört.

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

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

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

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

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

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

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

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

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

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

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

Wenn Sie sich unsicher sind, in welcher Kategorie der Regelsatz zu finden ist, können Sie auch gleich alle Regeln durchsuchen, indem Sie entweder das Suchfeld im Setup-Menü nutzen oder über Setup > General > Rule search die Seite zur Regelsuche öffnen. Wir werden den letztgenannten Weg im folgenden Kapitel gehen, in dem wir die Erstellung einer Regel vorstellen.

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

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

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

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

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

Der Regelsatz Oracle Tablespaces wird in zwei Kategorien gefunden. Die Zahl hinter dem Titel (hier überall 0) zeigt die Anzahl der Regeln, die aus diesem Regelsatz bereits erstellt wurden.

In diesem Beispiel soll nicht die Einrichtung eines Services erzwungen werden (enforced service). Klicken Sie daher auf den Namen in der Kategorie Service monitoring rules. Sie landen Sie in der Übersichtsseite des Regelsatzes:

Der Regelsatz enthält noch keine Regeln. Sie können die erste mit dem Knopf Add rule erstellen. Das Anlegen (und auch das spätere Bearbeiten) der Regel bringt Sie zu einem Formular mit drei Kästen Rule properties, Value und Conditions. Wir werden uns die drei nacheinander vornehmen.

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

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

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

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

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

Mit Folder legen Sie fest, in welchem Ordner die Regel gelten soll. Wenn Sie die Voreinstellung Main z.B. auf Windows ändern, so gilt die neue Regel nur für Hosts die direkt im oder unterhalb vom Ordner Windows liegen.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

In der Service-Konfiguration der Switches werden nun auch die Ports mit dem Zustand down angeboten, und Sie können sie zur Liste der überwachten Services hinzufügen.

Bevor Sie die Änderung aktivieren, benötigen Sie noch die zweite Regel, die dafür sorgt, dass dieser Zustand als OK gewertet wird. Der Regelsatz heißt Network interfaces and switch ports. Erstellen Sie eine neue Regel und aktivieren Sie die Option Operational state, deaktivieren Sie darunter Ignore the operational state und aktivieren Sie dann bei den Allowed operational states die Zustände 1 - up und 2 - down (und eventuell weitere Zustände).

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

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

Weitere Informationen können Sie im Artikel über die Konfiguration von Services nachlesen.

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

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

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

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

Legen Sie dort eine Regel an und setzen Sie den Wert z.B. auf 3, so wird ein Service, der z.B. von OK auf WARN geht, zunächst noch keine Benachrichtigungen auslösen und auch im Overview noch nicht als Problem angezeigt werden. Der Zwischenzustand, in dem sich der Service befindet, wird als „weicher Zustand“ (soft state) bezeichnet. Erst wenn der Zustand in drei aufeinanderfolgenden Checks (was insgesamt dann knapp über zwei Minuten dauert) nicht OK ist, wird das hartnäckige Problem gemeldet. Nur ein harter Zustand (hard state) löst eine Benachrichtigung aus.

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

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 die Service-Konfiguration aufrufen (auf der Seite Services of host) und die Liste der Services wieder auf den aktuellen Stand bringen.

Detaillierte Informationen zu diesem Discovery Check erhalten Sie im Artikel über die Konfiguration von Services. Dort erfahren Sie auch, wie Sie nicht überwachte Services automatisch hinzufügen lassen können, was die Arbeit in großen Konfiguration erheblich erleichtert.

Weiter geht es mit mehreren Benutzern